From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Ricardo Leitner Subject: Re: [PATCH v3 net-next 3/6] net: Add SW fallback infrastructure for offloaded sockets Date: Tue, 19 Dec 2017 13:05:46 -0200 Message-ID: <20171219150546.GC6122@localhost.localdomain> References: <20171218111033.13256-1-ilyal@mellanox.com> <20171218111033.13256-4-ilyal@mellanox.com> <20171218191826.GA6122@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netdev@vger.kernel.org" , "davem@davemloft.net" , "davejwatson@fb.com" , "tom@herbertland.com" , "hannes@stressinduktion.org" , Boris Pismenny , Aviad Yehezkel , Liran Liss , Steffen Klassert To: Ilya Lesokhin Return-path: Received: from mx1.redhat.com ([209.132.183.28]:36116 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752719AbdLSPFu (ORCPT ); Tue, 19 Dec 2017 10:05:50 -0500 Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Tue, Dec 19, 2017 at 07:51:02AM +0000, Ilya Lesokhin wrote: > On Monday, December 18, 2017 9:18 PM, Marcelo Ricardo Leitner wrote: > > > > + > > > + if (sk && sk_fullsock(sk) && sk->sk_offload_check) > > > > Isn't this going to hurt the fast path, checking for sk fields here? > > > > We do add code to the fast path but it seems unavoidable if you want to have SW fallback. > The XFRM device offload also does that > http://elixir.free-electrons.com/linux/v4.14.7/source/net/core/dev.c#L3058 Right, although a bit different. It's accessing skb->sp and not the socket and depending on how compiler is doing things, the check http://elixir.free-electrons.com/linux/v4.14.7/source/net/xfrm/xfrm_device.c#L32 will help in some cases. But more importantly, all the above only exists if CONFIG_XFRM_OFFLOAD is enabled. > > The check can be optimized but I didn't want to do that before I saw that it's an issue. > I'm also not sure what the correct solution is. > I don't like that fact that each "stateful protocol" we offload requires its own check. > We need to think if we can find a generic way of doing it. > > Perhaps we can hold the expected netdev somewhere in the SKB and only if we don't > Go out of the expected netdev go to a slow path that does a check for each protocol. This could be a good switch, yes. Thanks, Marcelo