Re: [lwip-users] lwIP hangs on transfers with many short packets

[Tyrel Newton]

> Unfortunately, IIRC, emaclite does not support backtoback packets. Since we
> are sitting right behind a packet processor, we do expect this to happen -
> and we have to process non-TCP as well so cannot afford to drop packets at
> high rates. Has this restriction changed?

If you configure the emaclite with both the ping/pong buffers, its possible to 
receive/transmit packets back-to-back. The real limitation with the emaclite is 
that there is no DMA. This means the MicroBlace/PPC needs to manually move data 
in/out of the mac's frame buffers, which they are especially not good at 
because of the data alignment requirements. The main problem is that if the 
MicroBlaze/PPC is copying data, then it is not processing the contents of the 
packets (i.e. TCP/IP processing). There is really no way that an emaclite-based 
system could keep a continuous stream of packets flowing in either direction.

> Would you provide your driver,
> should we ask?


All I really did with the emaclite driver was strip out all of the 
configurability and cruff so that it is simply a data copier into and out of 
the emaclite's frame buffers. Boiled down to its simplest, I have only been 
able to get about 10 Mbps out of the emaclite using the following setup (this 
is the basic setup provided with the Spartan-3A DSP 1800 development board):
- 62.5 MHz MicroBlaze
- 125 MHz DDR2 w/ 8k BRAM caches
The primary bottleneck is definitely the 62.5 MHz MicroBlaze copying data. With 
the default emacite lwIP driver provided by Xilinx, I think the peak rate I saw 
was in the 1~2 Mbps range.

I would provide the driver, but if you are using the temac, I would definitely 
recommend staying with that. I would just verify that there is nothing silly 
going on. For example, with Xilinx's default lwIP/emaclite driver, the outgoing 
pbufs are copied to an intermediary buffer. This extra copy is completely 
unnecessary and severely limits the throughput.

Tyrel