[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] ARP queueing changes since 1.3.2
From: |
rh_maillist |
Subject: |
[lwip-devel] ARP queueing changes since 1.3.2 |
Date: |
Mon, 09 Jun 2014 08:24:28 +0100 |
I’ve been investigating an issue with ARP queueing. We’re not using LWIPs memp
or malloc, just using the standard malloc that comes with our compiler.
We allocate all our pbufs upfront and don’t want them copied. We only send UDP
packets. We’ve disabled ARP_QUEUEING in 1.3.2 as we’re happy to drop the first
packet that requires an ARP request as we’ll retry our packet a little later.
I see that in the latest version, even with ARP_QUEUEING disabled, the outgoing
packet will be copied and stored on the ARP entry (etharp.c line 1186). Also,
#34681 limits ARP queue lengths to a defined maximum.
It would seem more logical that if you want one outgoing packet queued then
defining ARP_QUEUEING and setting ARP_QUEUE_LENGTH=1 would be the better way to
do it. That way if ARP_QUEUEING is disabled, then no outgoing packets will be
copied.
This would allow for both behaviours, but the current change prevents us from
stopping our packets being copied.
Is there a reason this couldn’t be changed before the next release? We’d like
to move to it but I think this behaviour is wrong and will adversely affect our
system so we’ll either have to have a custom patch for LWIP in our source or
stick with 1.3.2.
Thanks
Russell
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lwip-devel] ARP queueing changes since 1.3.2,
rh_maillist <=