Hi again: I found it awkward to answer, because I did not get any e-mails from the mailing list on this subject. I had to manually check the mailing list archive to see your messages. > UDP datagrams are carried by Ethernet frames. It is not > lwIP but your driver who allocates memory to hold those frames > before handling them to lwIP, which in turn will deliver > to your application. The only way to stop allocation is there.
> [...]> But you are right here that throwing packets away in the driver> as > early as possible is the best way to achieve this> on a resource constrained > target.> [...] > You're also right that lwIP can't really help here :-) My TCP/IP and lwIP expertise are limited. Please help me understand the situation by correcting my assumptions: - The Ethernet driver has a fixed, limited number of DMA slots, so it already limits the amount of data at that level. - An Ethernet frame is normally limited to 1500 bytes (or a little more). However, an UDP packet can be up to roughly 64 KiB long. - In the case of large UDP (or even TCP) packets, lwIP is merging several Ethernet frames (IP fragmentation) into a large buffer (or a pbuffer chain). Therefore, it is "allocating" a bigger logical chunk. In the process of doing so, it could check whether some maximum reassembly packet size has been reached, and then discard the whole packet. Depending on the allocation strategy, that would significantly drop the temporary memory requirements. - If I turn off IP_REASSEMBLY, would it help here? I guess the maximum size of UDP (or even TCP) packets would then be limited by the largest possible Ethernet frame. Would turning off IP_REASSEMBLY break other things, or severely impact performance, at least on IPv4? - Is there some constant to limit the size in bytes of reassembled packets? I found IP_REASS_MAX_PBUFS, but that is not a byte limit. If I set it too low, it may break, because the sender may choose to send many small packets. If I set it too high, the sender could send few but large frames and trigger big memory allocations. Thanks in advance, rdiez
_______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
