From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Fainelli Subject: Re: Flows! Offload them. Date: Mon, 02 Mar 2015 14:49:58 -0800 Message-ID: <54F4E916.4050805@gmail.com> References: <20150226133326.GC23050@casper.infradead.org> <54EF3A78.9020507@intel.com> <20150226201635.GA366@hmsreliant.think-freely.org> <20150226215255.GA15033@penelope.isobedori.kobe.vergenet.net> <20150227012239.GB8847@neilslaptop.think-freely.org> <20150302134946.GB7971@gospo.home.greyhouse.net> <20150302224335.GA14057@gospo.home.greyhouse.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Shrijeet Mukherjee , Tom Herbert , Neil Horman , Simon Horman , John Fastabend , Thomas Graf , Jiri Pirko , Linux Netdev List , David Miller , Andy Gospodarek , Daniel Borkmann , Or Gerlitz , Jesse Gross , "jpettit@nicira.com" , Joe Stringer , Jamal Hadi Salim , Roopa Prabhu , John Linville , Benjamin LaHaise To: Andy Gospodarek , Scott Feldman Return-path: Received: from mail-pd0-f177.google.com ([209.85.192.177]:41400 "EHLO mail-pd0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753924AbbCBWu1 (ORCPT ); Mon, 2 Mar 2015 17:50:27 -0500 Received: by pdno5 with SMTP id o5so43102128pdn.8 for ; Mon, 02 Mar 2015 14:50:27 -0800 (PST) In-Reply-To: <20150302224335.GA14057@gospo.home.greyhouse.net> Sender: netdev-owner@vger.kernel.org List-ID: On 02/03/15 14:43, Andy Gospodarek wrote: > On Mon, Mar 02, 2015 at 02:13:35PM -0800, Scott Feldman wrote: >> On Mon, Mar 2, 2015 at 10:31 AM, Shrijeet Mukherjee wrote: >>>> >>>> Can you elaborate on "allow for async write of data to hardware >>>> tables"? Is this the trampoline model where user's request goes to >>>> the kernel, and then back to user-space, and finally to the hardware >>>> via an user-space SDK? I think we should exclude that model from >>>> discussions about resource management. With the recent L2/L3 offload >>>> work, I'm advocating a synchronous call path from user to kernel to >>>> hardware so we can return a actionable result code, and put the burden >>>> of resource management in user-space, not in the kernel. >>>> >>> Scott you mean synchronous to the switchdev driver right ? >> >> Correct. > > So while I agree with you that it would be ideal to be synchronous all > the way to the hardware (and that is what I continue to tell vendors > they should do) you would like to see each driver individually manage > whether or not they chose to make these calls async and handle the > fallout in their own? I am not sure I follow you here, the way I would see it is something like this: SWITCHDEV DRIVER ndo_foo -> foo_op -> bus_op() -> # wait for interrupt complete() ndo_foo <- return at which point, the only things that matters is that the switch driver ensures calls serialization at its own level (concurrent HW registers access), eventually working under the assumption that ndo_foo() is also called with appropriate locking (rtnl) to prevent concurrent operations from occurring. If the model is more like the switch driver is responsible for locally queuing multiple commands, then I agree, we might not want that at all. -- Florian