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

2005-04-18 Thread 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,

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

2005-04-17 Thread Avi Kivity
David S. Miller wrote: On Sun, 17 Apr 2005 13:29:14 +0300 Avi Kivity <[EMAIL PROTECTED]> wrote: TOEs can remove the data copy on receive. In some applications (notably storage), where the application does not touch most of the data, this is a significant advantage that cannot be achieved in a so

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

2005-04-17 Thread Willy Tarreau
On Mon, Apr 18, 2005 at 12:08:41AM -0400, Kyle Moffett wrote: (...) > What I think would be _much_ more useful is a generic low-power > multi-proc MIPS/PPC system on a PCI card with a certain amount of > RAM, etc that could be programmed at runtime by the master CPU. > Then you lose none of the f

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

2005-04-17 Thread Kyle Moffett
On Apr 17, 2005, at 19:37, Horst von Brand wrote: Andreas Hartmann <[EMAIL PROTECTED]> said: Alacritech developed a new chip for NIC's (http://www.alacritech.com/html/tech_review.html), which makes it possible to take away the TCP stack from the host CPU. Therefore, the host CPU has more performa

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

2005-04-17 Thread Horst von Brand
Andreas Hartmann <[EMAIL PROTECTED]> said: > Alacritech developed a new chip for NIC's > (http://www.alacritech.com/html/tech_review.html), which makes it possible > to take away the TCP stack from the host CPU. Therefore, the host CPU has > more performance for the applications according Alacritec

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

2005-04-17 Thread David S. Miller
On Sun, 17 Apr 2005 13:29:14 +0300 Avi Kivity <[EMAIL PROTECTED]> wrote: > TOEs can remove the data copy on receive. In some applications (notably > storage), where the application does not touch most of the data, this is > a significant advantage that cannot be achieved in a software-only > solut

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

2005-04-17 Thread Bernd Eckenfels
In article <[EMAIL PROTECTED]> you wrote: > maybe one day you would be able to offload your firewall and policy > router too :) There are quite a few filtering NICs out there. Greetings Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EM

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

2005-04-17 Thread Andreas Hartmann
Willy Tarreau schrieb: > Hello ! > > On Sun, Apr 17, 2005 at 01:29:14PM +0300, Avi Kivity wrote: >> On Sun, 2005-04-17 at 12:07, Arjan van de Ven wrote: >> > On Sun, 2005-04-17 at 10:17 +0200, Andreas Hartmann wrote: >> > > Hello! >> > > >> > > Alacritech developed a new chip for NIC's >> > > (ht

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

2005-04-17 Thread Avi Kivity
On Sun, 2005-04-17 at 13:57, Arjan van de Ven wrote: > > > > TOEs can remove the data copy on receive. In some applications (notably > > storage), where the application does not touch most of the data, this is > > a significant advantage that cannot be achieved in a software-only > > solution. >

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

2005-04-17 Thread Avi Kivity
On Sun, 2005-04-17 at 14:30, Willy Tarreau wrote: > > TOEs can remove the data copy on receive. In some applications (notably > > storage), where the application does not touch most of the data, this is > > a significant advantage that cannot be achieved in a software-only > > solution. > > Well,

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

2005-04-17 Thread Willy Tarreau
Hello ! On Sun, Apr 17, 2005 at 01:29:14PM +0300, Avi Kivity wrote: > On Sun, 2005-04-17 at 12:07, Arjan van de Ven wrote: > > On Sun, 2005-04-17 at 10:17 +0200, Andreas Hartmann wrote: > > > Hello! > > > > > > Alacritech developed a new chip for NIC's > > > (http://www.alacritech.com/html/tech_r

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

2005-04-17 Thread Arjan van de Ven
> > TOEs can remove the data copy on receive. In some applications (notably > storage), where the application does not touch most of the data, this is > a significant advantage that cannot be achieved in a software-only > solution. other solutions can too. Search the archives for posts from Dave

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

2005-04-17 Thread Avi Kivity
On Sun, 2005-04-17 at 12:07, Arjan van de Ven wrote: > On Sun, 2005-04-17 at 10:17 +0200, Andreas Hartmann wrote: > > Hello! > > > > Alacritech developed a new chip for NIC's > > (http://www.alacritech.com/html/tech_review.html), which makes it possible > > to take away the TCP stack from the host

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

2005-04-17 Thread Arjan van de Ven
On Sun, 2005-04-17 at 10:17 +0200, Andreas Hartmann wrote: > Hello! > > Alacritech developed a new chip for NIC's > (http://www.alacritech.com/html/tech_review.html), which makes it possible > to take away the TCP stack from the host CPU. Therefore, the host CPU has > more performance for the appl

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

2005-04-17 Thread Andreas Hartmann
Hello! Alacritech developed a new chip for NIC's (http://www.alacritech.com/html/tech_review.html), which makes it possible to take away the TCP stack from the host CPU. Therefore, the host CPU has more performance for the applications according Alacritech. This sounds interesting. Unfortunately