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: <20081031.024739.30392024.davem@davemloft.net>
Date:	Fri, 31 Oct 2008 02:47:39 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	ilpo.jarvinen@...sinki.fi
Cc:	zbr@...emap.net, netdev@...r.kernel.org, efault@....de,
	mingo@...e.hu, a.p.zijlstra@...llo.nl, herbert@...dor.apana.org.au
Subject: Re: tbench wrt. loopback TSO

From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
Date: Fri, 31 Oct 2008 11:16:21 +0200 (EET)

> On Fri, 31 Oct 2008, David Miller wrote:
> 
> > From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
> > Date: Tue, 28 Oct 2008 00:17:00 +0200 (EET)
> > 
> > > > Another modulo sits in tcp_mss_split_point().
> > > 
> > > I know it's there but it should occur not that often.
> > 
> > It happens every sendmsg() call, and all tbench does is small send,
> > small recv, repeat.
> 
> This is not true for the mss_split_point case which I was speaking of, I 
> even explained this in the part following that first sentence which you 
> choose to snip away:
> 
> 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).
> 
> To reiterate, with small send you have pcount == 1 and that won't execute 
> any of the mss_split_point code!
> 
> The tcp_current_mss code is a different beast (if you meant that, I 
> didn't :-)), yes it executes every so often but I was under impression 
> that we agreed on it already. :-)

My bad, tcp_current_mss() is what I thought your first sentence was about.

> > So with TSO on, a small increase in performance is no surprise, as
> > we will save some cycles often enough.
> 
> Also tcp_send_fin seems to do tcp_current_mss(sk, 1) so it's at least two 
> modulos per transaction...

True, but not for tbench. :-)

For tbench that one is benign as this will only execute once for each
thread during the entire benchmark.  Each thread starts up immediately,
opens up the connection, and then goes back and forth send/recv over
and over again for each SAMBA transaction being simulated.  Then at
the end each per-thread socket is closed.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html