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
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
