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.0811051355550.23792@wrl-59.cs.helsinki.fi>
Date:	Wed, 5 Nov 2008 14:04:14 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	David Miller <davem@...emloft.net>
cc:	zbr@...emap.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, David Miller wrote:

> From: Evgeniy Polyakov <zbr@...emap.net>
> Date: Wed, 5 Nov 2008 14:49:00 +0300
> 
> > But what if we just remove that trimming at all? This may result in
> > a not fully filled tso frame, but who cares if we copy data from
> > userspace anyway, will add another potentially small copy at sending
> > time?
> 
> Ok, the only part I care about is whether taking away this modulus
> will result in a sub-MSS sized packet on the wire, which is
> undesirable.
>
> The send logic will prevent this, right?

I don't see what currently would do that. We'd need to resegment skbs 
there then...

> If so, yes I agree, we can delete this.

Would we have something similar to those blobs we discussed when talking 
about sack data structures it might be provided by machinery we need 
anyway but currently it gets quite non-trivial since in order to fill a 
segment we need to input from two skb's which probably requires making 
another skb or the stack downstream cannot cope afaik.

-- 
 i.
--
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