On Sunday 17 April 2005 22:04, Andreas Hartmann wrote: > Willy Tarreau schrieb: > > Well, if the application does not touch most of the data, either it > > is playing as a relay, and the data will at least have to be copied, > > or it will play as a client or server which reads from/writes to disk, > > and in this case, I wonder how the NIC will send its writes directly > > to the disk controller without some help.
If both NIC and disk is clever enough, they can both use DMA: NIC ==dma==> RAM ==dma==> DISK without CPU needing to ever touch the bulk of data. > > What worries me with those NICs is that you have no control on the > > TCP stack. You often have to disable the acceleration when you > > want to insert even 1 firewall rule, use policy routing or even > > do a simple anti-spoofing check. It is exactly like the routers > > which do many things in hardware at wire speed, but jump to snail > > speed when you enable any advanced feature. Yes. This is why TCP offload is a buzzword mostly. Anybody with real experience on this? > Alacritech says, the hardware solution would make it very easy for the > application, because _every_ application would gain, without considering > the hardware it runs on itself. These are things which CEO's like to hear > - because they think, they could save time and money during development of > the application. Most probably marketspeak. > I don't think that it must be a problem, that on the hardware TCP stack > doesn't run any filter or other additional functions, because machines > (often clusters) with high workloads usually run on dedicated servers with > other dedicated firewall machines in front of. If you put firewall machine in front of your 10GigE server, you are killing its performance. > I think it would be good to support this hardware, because the user can > decide afterwards (after testing), which is the best choice for his > specific application and workload. Are specs available? -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
