Re: [lwip-users] Queueing up UDP packets in RAW api

[Jan Menzel]

Hi Michael!
        I like this type of discussions so let me put my five cents in too:
- due to the zero-copy approach, the pbufs you see in receive callbacks
are the ones you queued up in the input driver. So, if you're in charge
for the input driver, you could only provide reasonable large pbufs
there and never see any chained pbuf in your udp receiver.
- len/totlen are fields, that allow the input driver to transfer its
received length into the application. They are for application use only
and not needed to free pbufs(-chains).
- each network layer may strip its header before forwarding the content
to the next layer. Hence if you have a chain of pbufs, the first might
be not available in higher layers. Therefore I would suggest not to rely
on rewinding eg. in udp layer back to ip to extract the source ip address.
- if the pbufs you queue in the receive layer are large, there is no
small part, that can be freed by any layer before the udp receive
callback. Hence you have free space between the packet start and the
payload pointer.
- The cleanest approach I see is to create a custom pool which contains
elements you use to operate your queue of pbuf. This elements can easily
contain the source ip/port and everything else you need. In addition the
memory overhead is quite small and you can track the usage using lwips
internal statistics.

        Jan

On 16.02.2018 5:05, Michael Steinberg wrote:
> Oh, and of course I also felt like I need to store away the source
> address information somewhere. I am aware that it's likely the source
> address is somewhere stored inside one of the first pbufs, accessible by
> lowering the layer and looking into the ip header, but I'm not aware of
> any API help to recover it at a later time. I could even use that header
> space for myself, but this would be a complete hack and I don't know if
> I can take granted that the passed buffers contain a header section at all.
> 
> Michael
> 
> 
> Am 15.02.2018 um 21:52 schrieb address@hidden:
>> Why don't you use pbuf_cat()? This uses the next pointer of the last
>> pbuf in a chain.
>>
>> Simon
>>
>> On 15.02.2018 18:55, Michael Steinberg wrote:
>>> Hey,
>>>
>>> right, it was silly to even ask really ;)
>>> Would I cause considerable harm to the RAM-pool if I allocated the
>>> necessary storage for queueing (basically a linked list node) from it
>>> with a RAW allocation? The packet and node pbufs would be deallocated
>>> together again later-on. The alternative would be to define a limit of
>>> packets to queue up, since space is at premium and I can't add another
>>> heap allocator... Maybe I'm just not seeing the easy solution today ;)
>>>
>>> Kind regards
>>> Michael
>>>
>>>
>>> Am 15.02.2018 um 13:04 schrieb Simon Goldschmidt:
>>>> Steinberg Michael wrote:
>>>>> I need to queue up received UDP packets inside the UDP receive
>>>>> callback (RAW API) for
>>>>> an event driven->polling transfer. I take that the passed in pbuf
>>>>> pointers may very
>>>>> well point to pbuf chains, right?
>>>> Yes.
>>>>
>>>>> Abusing the pbuf next pointers for my own custom packet queue
>>>>> seemed like a quick answer,
>>>>> but I fear that it might backfire quickly...
>>>> Not a good idea.
>>>>
>>>> Simon
>>>>
>>>> _______________________________________________
>>>> lwip-users mailing list
>>>> address@hidden
>>>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>>
>>> _______________________________________________
>>> lwip-users mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>>
>>
>>
>> _______________________________________________
>> lwip-users mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>