netdev - Re: tbench wrt. loopback TSO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0810272113280.13973@wrl-59.cs.helsinki.fi>
Date:	Tue, 28 Oct 2008 00:17:00 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Evgeniy Polyakov <zbr@...emap.net>
cc:	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>, efault@....de, mingo@...e.hu,
	a.p.zijlstra@...llo.nl, Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: tbench wrt. loopback TSO

On Mon, 27 Oct 2008, Evgeniy Polyakov wrote:

> On Mon, Oct 27, 2008 at 05:19:17PM +0200, Ilpo Järvinen (ilpo.jarvinen@...sinki.fi) wrote:
> > On Mon, 27 Oct 2008, Evgeniy Polyakov wrote:
> > 
> > > On Mon, Oct 27, 2008 at 09:49:21AM +0200, Ilpo Järvinen (ilpo.jarvinen@...sinki.fi) wrote:
> > > > > > That's what I got with the current tree for 8 threads on a 4-way 32-bit
> > > > > > Xeons (2 physical CPUs) and 8gb of ram:
> > > > > > gso/tso off: 361.367
> > > > > > tso/gso on:  354.635
> > > > > 
> > > > > Yes, it might do this, in which case tcp_tso_should_defer() simply needs
> > > > > some tweaking.
> > > > 
> > > > Good point, could you Evgeniy verify first if simple goto send_now; in 
> > > > beginning there recovers it all...
> > > 
> > > With direct goto at the begining of the tcp_tso_should_defer()
> > > and 4403b406 commit git tree (was current yesterday night)
> > > I got following numbers: 
> > > 
> > > with goto:
> > > tso/gso  on: 358.976, 357.699
> > > tso/gso off: 368.016, 367.079
> > > 
> > > no goto
> > > tso/gso  on: 353.656, 354.791
> > > tso/gso off: 364.8, 365.85
> > > 
> > > So tcp_tso_should_defer() adds additional problems not counted in
> > > tso/gso changes.
> > 
> > Noticed that tcp_current_mss does modulo with tso and that it is 
> > being called from a non-trivial number of places, though ovbiously only 
> > part of them should be relevant here. ...I'm not sure if that can show 
> > up though.
> 
> That's why when I see modulo something screams inside me...
> I used following patch (without goto in the tcp_tso_should_defer():
> 
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index e4c5ac9..8ee7597 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -1075,7 +1075,6 @@ unsigned int tcp_current_mss(struct sock *sk, int large_allowed)
>  				  tp->tcp_header_len);
>  
>  		xmit_size_goal = tcp_bound_to_half_wnd(tp, xmit_size_goal);
> -		xmit_size_goal -= (xmit_size_goal % mss_now);
>  	}
>  	tp->xmit_size_goal = xmit_size_goal;
>  
> 
> tso/gso  on: 361.866 362.662
> tso/gso off: 370.038 368.768
> 
> So this is another improvement hidden and not accounted in the tso/gso stuff.
> Another modulo sits in tcp_mss_split_point().

I know it's there but it should occur not that often. If you have pcount 
== 1 (len <= mss implies that) that won't even execute and rest of the 
cases involve handling rwin limited & nagle. I suppose we could make nagle 
to work without splitting the skb to sub-mss (needs some auditting to find 
out if something else than snd_sml setting assumes skb->len < mss, nagle 
check probably as well but I don't remember w/o looking).


-- 
 i.