Re: [lwip-users] Out Of Order Sequence (Segments?)

[address@hidden]

Bill Auerbach wrote:
> > That sounds like a port or driver problem (or a bug I haven't
> > encountered).
> >     
>
> Or a PowerPC problem.  There is some kind of problem using a DMA channel to
> copy memory from the TSEC BD pointer to data to my data buffer.  I know it's
> hard to believe, but I don't have problems with a limited number of pbufs if
> I use a software copy, or if I use DMA and have about 100 extra pbufs.  This
> is the reason for the processor freezing with limited pbufs, *not* the OOS
> list consuming pbufs.
>   
I don't mean to offend you, but unless you have a custom-designed board, 
I'd first check the code that handles the DMA copy mecahnism before 
checking the hardware ;-)

Depending of the cache-line size, you might have to take care your pbufs 
are aligned accordingly (if cache lines are 16 bytes, pbufs must start 
at a multiple of 16 bytes and the length also must be a multiple of 16 
bytes!). Without that, you risk data corruption when you invalidate too 
much (or too little) memory before copying or sending.

> > > Should there be a #define and a test and for the amount of ooseq's to be
> > > allowed to be buffered?  If not, what is a practical limit?
> > >       
> > Your receive window (TCP_WND in lwipopts.h).
> >     
>
> With 65535, that isn't easy to accommodate.  Is that number divided by the
> MTU a reasonable estimate?  If there are so many out of order sequences, I
> think I'll have bigger problems (like bandwidth).
>
>   
What Jonathan meant is: there is no limitation in lwIP to limit the 
number of segments on the ooseq queue. It is only limited by the remote 
host not sending more (unacknowledged) segments thatn the receive window 
can take (configured via TCP_WND and sent to the remote host when 
establishing the connection). If 65535 is too much for your target, you 
probably should send TCP_WND to a smaller value: Keep in mind that (if 
you use the socket or netconn API), you have to be prepared to store the 
complete receive window in memory before the application thread 
processes it!

Simon