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

[Bill Auerbach]

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

OK.  This is making more sense to me now.

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

The reason for TCP is that although this is a direction connection (WinXP to
PowerPC), it can be a noisy environment where we can't guarantee an
occasional dropped packet.

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

:-)  I meant realtime in the sense that we can't lose control of the
processor to an OS and not be able keep up with reading the image,
processing it and sending it on.  Currently we do this process with
firewire, but the short cable length prevents us from moving the PC farther
than we need to. So we're using GBE for the speed and longer distance.  With
10GBE on the horizon, that only helps.  A 600MHz PPC dedicated to reading
the image and processing it (with little else going on), we think (hope :) )
the bandwidth will be there.  Or it will be limited by the PC, which we will
have to resolve.  If I'm going down the wrong path I'm trying to find out as
soon as possible.

> Other than that, I think there is no limitation in raw API mode (aside
> from the heap size: MEM_SIZE).

I can allocate 32MB or more for lwIP.

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

This is what I hoped.  It's the reverse, I want to point the pbuf into the
ETH rx memory when a packet arrives.  The challenge will be when the pbuf
has been used, to release the ETH memory.

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

Hmmm, OK.  Because of the point above, when can we release the pbuf?

Thank you very much!

Bill