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