[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.
Sorry
Russell
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