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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]