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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Wed, 16 Jul 2014 15:15:53 +0300
From:	Or Gerlitz <or.gerlitz@...il.com>
To:	Jerry Chu <hkchu@...gle.com>
Cc:	Tom Herbert <therbert@...gle.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	Wolfgang Walter <linux@...m.de>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] net-gre-gro: Fix a bug that breaks the
 forwarding path

On Tue, Jul 15, 2014 at 11:22 PM, Jerry Chu <hkchu@...gle.com> wrote:
> On Tue, Jul 15, 2014 at 11:21 AM, Or Gerlitz <or.gerlitz@...il.com> wrote:

>> I am not near the code now, but AFAIK, the "stack" sets it in the TX path
>> and the driver sets it in the RX path, any deviation you see there for this
>> convension except for the change introduced by this patch.

> Where does the forwarding path (e.g., the case at hand) belong then?

yep, so forwarding flow is something like

HW --> driver RX --> stack RX --> some stack processing --> stack TX
--> driver TX --> HW

and this is different from a path of

application --> stack TX --> driver TX --> HW

It seems as of even before we throw in the tunneling thing, the GRO stack
which is part of that "stack RX" code I mentioned above sets the
gso_type of SKBs
for the sake of forwarding  so these things already happen.

> AFAICT the current dev_hard_start_xmit() code pretty much requires
> skb->encapsulation to be set on all tunneled pkts in order for the proper
> TX offload to be possible.
--
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

Powered by blists - more mailing lists