From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Gospodarek Subject: Re: Flows! Offload them. Date: Mon, 2 Mar 2015 17:43:35 -0500 Message-ID: <20150302224335.GA14057@gospo.home.greyhouse.net> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 , Florian Fainelli , Roopa Prabhu , John Linville , Benjamin LaHaise To: Scott Feldman Return-path: Received: from mail-qa0-f45.google.com ([209.85.216.45]:38477 "EHLO mail-qa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753846AbbCBWnx (ORCPT ); Mon, 2 Mar 2015 17:43:53 -0500 Received: by mail-qa0-f45.google.com with SMTP id j7so25419097qaq.4 for ; Mon, 02 Mar 2015 14:43:52 -0800 (PST) Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: 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'm fine with that for now since Dave's opinion on most of this is that we need to "keep it simple" for now (he said that once already today), but I think it is something we should consider for the future.