lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Patch for bug 23119


From: Kieran Mansley
Subject: Re: [lwip-users] Patch for bug 23119
Date: Fri, 13 Mar 2009 09:31:04 +0000

On Thu, 2009-03-12 at 16:09 -0700, Ken Smith wrote:
> On Wed, Mar 11, 2009 at 6:34 AM, Kieran Mansley <address@hidden> wrote:
> >
> > The other interesting bit in the stats is that you're running out of MEM
> > ARP_QUEUE fields.  This suggests that packets are being buffered by ARP
> > while waiting for a reply.  If it didn't get a reply to its ARP queries
> > (or if the ARP queries never made it out of the device) that would
> > explain why no other traffic is sent.
> >
> > So it looks like lwIP is doing the right thing, but that something is
> > preventing the device from sending or receiving packets.  Are you sure
> > your driver is working correctly?
> 
> You have given me a lot of food for thought and I have been looking in
> to your suggestions.  I have several new questions regarding lwIP
> configuration.
> 
> - How can I artificially cause packets to be queued waiting for ARP replies?

If you periodically invalidated the ARP cache while traffic was being
sent, it would have to re-request ARP entries, and traffic would get
queued while it waited for a reply.  Alternatively, something like
dropping ARP packets in your driver, and using an application that sends
UDP would do it I think.  

> - What is a good way to determine the optimal size of
> MEMP_NUM_ARP_QUEUE?  (Eg. should it be based on PBUF_POOL_SIZE,
> ARP_TABLE_SIZE, network latency, etc.?)

I'm not sure.  I suppose shouldn't be so large that all the buffers
could be used up by packets waiting to go out and it should be large
enough to avoid dropping packets.  These values will depend on your
hardware and the network you're in.

> - What are the consequences of turning off ARP_QUEUEING?

Dropped packets while waiting for ARP replies, I think.


> Also, in looking at my ethernet driver the way it interfaces with
> lwIP, I noticed some meaningful differences between my implementation
> and the reference implementation in CVS HEAD. 

I'll leave the questions about the driver interface to others who are
more well versed than I am.  There is a similar set of questions in the
"lwip driver model" thread at the moment, with some replies from Simon.

Kieran





reply via email to

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