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]

Date:	Wed, 5 Nov 2008 15:33:37 +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 Wed, 5 Nov 2008, Evgeniy Polyakov wrote:

> On Wed, Nov 05, 2008 at 02:25:57PM +0200, Ilpo Järvinen (ilpo.jarvinen@...sinki.fi) wrote:
> > The problem is that we'd need to _resegment with the next skb_ since the 
> > mss boundary and skb boundary would basically constantly be running 
> > out-of-sync. That won't get done currently by anything.
> 
> Btw, what's that wrong if there will be sub-mss frame per tso frame?

I personally don't consider that to be a big deal... I suppose some see
it as bad thing because of the slightly larger header vs data ratio...
Which is significant only if you can saturate the link (or have unbounded 
bandwidth such as with lo), so slower links are more affected than high 
speed ones...

-- 
 i.