Re: [lwip-users] pbuf handling / possible bug?

[Michael Steinberg]

Hello Simon,


>> I could not find a mechanism where lwip notifies me that a lwip-pbuf
>> is available again
>
> LWIP_HOOK_MEMP_AVAILABLE(memp_t_type)
I'm using lwip version "1.41 stable" here, searched for this macro but
could not find anything. Is this included in an upcoming release? I
found a bugtracker discussion about this topic though while browsing the
web. Apparently others came to the conclusion to use custom pbufs for
this reason, too. But this notification would greatly simplify my code,
I don't think the perfomance hit by going through the pbuf api would be
notable, since this will be happening quite infrequently I guess.

>> Now during my custom pbuf usage I ran across situations, were lwip would
>> call mem_trim or other such functions, not checking for whether the
>> custom-pbuf-flag is set. A notable occasion would f.e. be in line
>> "pbuf.c":417.
>
> That would be a bug. For these, we have a bug-tracker to ensure things
> don't get lost.
I will try to come up with a bug for this. Maybe it is no bug after all
because I'm just misusing it, then I'm sorry.

>> In my eyes it might be a lot clearer if custom pbufs are
>> not indicated by a flag bit, but by their own type maybe?
>
> This is not what "custom" pbufs are meant for. They are meant to
> behave like their type indicates, only they are taken from different
> memory - managed by a custom allocator/deallocator.
How can a custom RAM-pbuf possibly reallocate (ie. behave like a normal
ram-pbuf), when its sourcing pool can only be "contacted" through the
deleter function? I think I will need to dig more into pbuf.c.

Thank you very much for your thoughts!

Kind Regards,
Michael