Re: [lwip-users] Transferring large data fast and pointing pbufs directly to Ethernet receive buffers

[address@hidden]

Hi,
> I’m implementing GBE (gigabit Ethernet) on a PowerPC platform and 
> because of realtime constraints chose lwIP with no OS. I need to 
> receive 1MB-4MB images as fast as possible for some processing and 
> then will be passing them on to other hardware. Is MEMP_NUM_TCPIP_MSG 
> the significant parameter to change to be able to buffer the entire 
> image while it’s being processed serially and passed on?
Without an OS, MEMP_NUM_TCPIP_MSG is irrelevant, because those are only 
used to put stuff into the tcpip mbox (which you don't have without an OS)!

When using UDP, you'll need to set MEMP_NUM_PBUF (when using PBUF_REF 
pbufs) or PBUF_POOL_SIZE (when using PBUF_POOL pbufs) high enough. When 
using PBUF_POOL pbufs, make sure PBUF_POOL_BUFSIZE is set big enough 
(splitting packets slows it down).

When using TCP: good luck with your realtime constraints :-)

Other than that, I think there is no limitation in raw API mode (aside 
from the heap size: MEM_SIZE).
> Secondly, the PowerPC loads packets directly into buffer descriptor 
> memory. Is looks possible (best) at low_level_input to point pbufs 
> right into the received packet without copying. If I’m correct that 
> this can be done, the question I have is, where can I know the data 
> was read by the upper layer to be able free the pbuf and at the same 
> time to be able to free memory for the Ethernet controller?
Normally, you would allocate a pbuf including data buffer: type 
PBUF_POOL and make sure the data buffer is in one piece (p->next == 
NULL; for that, PBUF_POOL_BUFSIZE has to be set to 1516 for ethernet). 
Then you set the ETH DMA to receive to p->payload. When a packet is 
received, substract the offset from p->payload so you get the pbuf 
pointer, which you can pass into the stack. Of course, this only works 
if your ETH DMA can receive to the memory where the memp pools are 
allocated.

Unfortunately, using a PBUF_REF for receiving input packets doesn't work 
so good I think...

Simon