netdev - Re: [RFC] about "net: orphan frags on receive" insanity

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: <20130626185614.GA10713@redhat.com>
Date:	Wed, 26 Jun 2013 21:56:14 +0300
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: [RFC] about "net: orphan frags on receive" insanity

On Wed, Jun 26, 2013 at 03:12:23AM -0700, Eric Dumazet wrote:
> On Wed, 2013-06-26 at 12:56 +0300, Michael S. Tsirkin wrote:
> 
> > Please don't just revert it.
> 
> I said "revert and fix the callers"
> 
> > 
> > Packets can cross e.g. the bridge and end up on the external
> > interface, in which case that NIC guarantees that
> > they will get transmitted eventually, so it's safe
> > to transmit from guest memory, or they can end up
> > in the host stack where they can stay indefinitely,
> > in this case we need to orphan frags so guest networking
> > can keep going.
> > 
> > What do you suggest exactly?
> > 
> > Also, I'll have to look at the generated binary - when I
> > coded this up, compiler seemed to only put a
> > conditional branch on the fast path, this shouldn't
> > be all that expensive.
> 
> Then look again. Its 400 bytes right now.
> 
> I suggested to call this only from the impacted callers.

Well we don't want to duplicate the whole RX path
to special-case that, right?

> VM are fine, but if we slow down bare metal to close the gap, or make
> appealing kernel bypass, that's not very fair.
> 
> Why normal frames received from real NIC should pay this price, I don't
> know.
> 
> The conditional branch might sound not expensive, but the cache line
> miss on skb_shinfo(skb)->tx_flags is expensive.
> 

Okay, for the RX path, I think we can set a
separate flag in the skb itself, and branch
based on that.

Would this address the comment?

-- 
MST
--
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