AW: [lwip-users] Transferring large data fast and pointing pbufsdirectly to Ethernet receive buffers

[Goldschmidt Simon]

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

So you *are* using TCP... There are some more options you'll have to
tune to be fast. (I don't have the time currently to dig them out,
sorry.)

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

If your ethernet controller is fast and your memory bandwidth is big
enough, this should be no problem for lwIP and the PPC.

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

That's good: you have enough memory for big pools and large send/receive
windows.

[...]
> 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?

The way you want it (pointing the pbuf to ETH rx memory) does not work
currently (you'd have to used PBUF_REF for that, and that doesn't work)!
There has been discussion around that (add support for a free-callback
and so on), but at present, it definitively doesn't work. You have to
let your MAC receive to PBUF_POOLS (including the struct *and* the
buffer in one piece). If your MAC (or system setup) can't do this, I'm
afraid you can only use memcpy (or another DMA engine) instead.

Simon