From: Dmitry Yusupov <[EMAIL PROTECTED]>
Date: Fri, 19 Aug 2005 16:55:47 -0700
> Signed-off-by: Dmitry Yusupov <[EMAIL PROTECTED]>
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -925,10 +925,6 @@ static int tcp_tso_s
For jumbo traffic, if cong. window is big, than TSO defer will not
happen that often. Hence, most of the traffic will be non-TSO and that
is why we saw performance degradation on our setup. This was the case
for 10G network where we tend to set tcp window very big, i.e. 1M+
This patch forces to def
From: "Leonid Grossman" <[EMAIL PROTECTED]>
Date: Fri, 12 Aug 2005 14:04:47 -0400
> Why the total length has to be in the header, there may be other
> ways to pass the total TSO length to the driver?
Because the packet has to look like a legal IPV4 frame
for the rest of the networking stack, for
> -Original Message-
> From: David S. Miller [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 11, 2005 4:35 PM
> To: [EMAIL PROTECTED]
> Cc: Leonid Grossman; netdev@vger.kernel.org
> Subject: Re: Super TSO performance drop
>
> From: Dmitry Yusupov <[EMAIL
From: Dmitry Yusupov <[EMAIL PROTECTED]>
Date: Thu, 11 Aug 2005 16:30:49 -0700
> But even with new TSO schema, this logic can not send more than
> MAX_SKB_FRAGS which at best case ~60K. With old TSO schema.
> I thought with SuperTSO we could send >> than 60K. And than it could be
> very beneficial
On Thu, 2005-08-11 at 16:15 -0700, David S. Miller wrote:
> From: "Leonid Grossman" <[EMAIL PROTECTED]>
> Date: Thu, 11 Aug 2005 19:05:22 -0400
>
> > Basically, it looks like with SuperTSO most of the traffic in our tests
> > comes down to the driver with mss 0 (TSO is mostly "off").
> > With the
From: "Leonid Grossman" <[EMAIL PROTECTED]>
Date: Thu, 11 Aug 2005 19:05:22 -0400
> Basically, it looks like with SuperTSO most of the traffic in our tests
> comes down to the driver with mss 0 (TSO is mostly "off").
> With the original TSO, is was always "on" (see below).
> Could you describe how
> -Original Message-
> From: David S. Miller [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 05, 2005 1:19 AM
> To: Leonid Grossman
> Cc: netdev@vger.kernel.org
> Subject: Re: Super TSO performance drop
> I'm not talking about the application, I'm
From: "Leonid Grossman" <[EMAIL PROTECTED]>
Date: Thu, 4 Aug 2005 16:10:30 -0400
> I'm not sure there is anything specific about ntttcp packet patterns,
> it's a generic tcp benchmark...
> We did not try iperf or netperf, but typically these programs perform
> extremely close to ntttcp numbers.
I
> -Original Message-
> From: David S. Miller [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 04, 2005 6:52 AM
> To: Leonid Grossman
> Cc: netdev@vger.kernel.org
> Subject: Re: Super TSO performance drop
>
> From: "Leonid Grossman" <[EMAIL PROT
From: "Leonid Grossman" <[EMAIL PROTECTED]>
Date: Wed, 3 Aug 2005 21:07:56 -0400
> We can either provide a remote to the setup, or test incremental patches
> if #16 can be broken in smaller pieces.
I think it would be more productive for you to work on trying
to figure out what about the packet p
11 matches
Mail list logo
