[Top][All Lists]

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

Re: [lwip-devel] ARP queueing

From: Russell Hind
Subject: Re: [lwip-devel] ARP queueing
Date: Mon, 09 Jun 2014 11:10:05 +0100

Please disregard this and see my message entitled "ARP queueing changes since 
1.3.2”.  I thought this e-mail would be rejected as it wasn’t the address I 
registered with so I re-sent it.



On 9 Jun 2014, at 08:20, Russell Hind <address@hidden> wrote:

> 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 as we’re happy to drop the first 
> packet that requires an ARP request as we’ll retry our packet a little later.
> In 1.3.2, we’ve disabled ARP_QUEUEING and that has the desired behaviour.  
> The ARP request is dynamically allocated but our packet is dropped rather 
> than copied.
> 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
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-devel

reply via email to

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