lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Smallest possible PBUF_POOL_SIZE and MEM_SIZE (UDP only


From: Hamme, Janis
Subject: Re: [lwip-users] Smallest possible PBUF_POOL_SIZE and MEM_SIZE (UDP only), PBUF allocation
Date: Fri, 19 Oct 2018 15:43:57 +0000

Hello Simon,

Thanks for your response! I just checked nd6.c and it seems I misunderstood how 
the LWIP_ND6_QUEUEING option works. I thought disabling that option would 
disable queuing entirely and not just limit queueing to a single packet. Having 
an option to just broadcast packets on the link layer while the cache entry is 
still in INCOMPLETE state would be a neat option for future lwIP versions 
(although that isn't standard conform). I also thought the neighbor cache would 
be populated by looking at incoming packets, but indeed the RFC says it's not.

The network protocol I'm using is not limited to multicast. Nodes reply with 
unicast packets after a multicast request has been received. Queuing just a 
single packet might not be enough, so maybe I'll have to patch a "broadcast if 
unknown" feature in.

I'll guess I just use PBUF_REF for outgoing packets. Fixed sized headers should 
not cause too much heap fragmentation. Getting rid of the heap entirely will 
probably not work because it's still needed for sending all kinds of ICMPv6/ND 
packets.

Janis

-----Original Message-----
From: lwip-users <address@hidden> On Behalf Of goldsimon
Sent: Friday, October 19, 2018 2:14 PM
To: Mailing list for lwIP users <address@hidden>
Subject: Re: [lwip-users] Smallest possible PBUF_POOL_SIZE and MEM_SIZE (UDP 
only), PBUF allocation



Hamme, Janis" wrote:
> Since each packet would be processed
>immediately I can't think of any situation where I would need to store 
>more than one incoming and one outgoing packet at a time. Queueing 
>shouldn't occur anywhere - or am I missing something?

If your netif driver doesn't queue, tx packets can still be queued for a short 
time if the MAC address for the next hop needs to be resolved. For multicast, 
this should not be required, so your assumption might hold.


>My other question is what would be the most efficient way to allocate 
>PBUFs for outgoing packets. I'm using a statically allocated buffer to 
>generate outgoing packets and I could easily increase the buffer size 
>to hold all other headers in contiguous memory. But I must be sure that 
>the buffer can be reused once udp_sendto(...) returns. Is there any way 
>to achieve that or is the overhead of using PBUF_REF with chained 
>header PBUFs negligible?

That would involve some work, I think. Using a PBUF_RAM should be the most 
simple solution, I guess? In your simple setup you could also use a PBUF_POOL 
for tx pbufs to get rid of the heap...


Simon

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users



reply via email to

[Prev in Thread] Current Thread [Next in Thread]