Re: More performance for the TCP stack by using additional hardware chip on NIC

[Denis Vlasenko]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/