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

[Bill Auerbach]

> 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 ;-)

No worries there.  I'm no expert on most of this stuff.  The DMA function is
part of the PowerPC (8349) itself and I simply set up the start, end,
length, that it's memory to memory transfer, and say "go".  But there is a
warning the manual I admit was fuzzy about cache coherency.  I do have snoop
enabled on the TSEC DMA controller.  Maybe I'm just doing the unexpected
with dma-ing out of TSEC memory.

> 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!).

Receive Buffer Descriptors are 64 byte aligned (I allocate 128 more than my
MTU and adjust payload up to a 64 byte boundary).  I've run with an
LWIP_ASSERT on (payload % 64) == 0 to be sure it's not ever bad.  This
aligned payload address is stored in the BD.

> Without that, you risk data corruption when you invalidate too
> much (or too little) memory before copying or sending.

Yes.  I don't know where the cache fits in, but my hunch is the cache for
memory used by the TSEC what is grabbed by a dma_memcpy has a small window
for a hardware deadlock since the PPC goes unresponsive.  I could set a
watch dog I suppose but that won't resolve the lockup.

> What Jonathan meant is: there is no limitation in lwIP to limit the
> number of segments on the ooseq queue.

This is what made me think maybe I want to limit them if I would run out of
pbufs.  I can allocate many more pbufs - what got me into this is I had too
few pbufs than I thought I needed for the system and was running out.  I can
add plenty for OOSEQ now that I know I should.  Before yesterday I didn't
know about OOSEQs.

> 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!

I'm using raw TCP (well, a small socket-like NO_SYS layer on top of it).
The lockup was for a different reason.  I found I was out of pbufs from
OOSEQ and didn't know what they were and how many pbufs are reasonable to
reserve for it.  I think 40-50 will be plenty.

Thanks for your reply,

Bill