[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150302224335.GA14057@gospo.home.greyhouse.net>
Date: Mon, 2 Mar 2015 17:43:35 -0500
From: Andy Gospodarek <gospo@...ulusnetworks.com>
To: Scott Feldman <sfeldma@...il.com>
Cc: Shrijeet Mukherjee <shrijeet@...il.com>,
Tom Herbert <therbert@...gle.com>,
Neil Horman <nhorman@...driver.com>,
Simon Horman <simon.horman@...ronome.com>,
John Fastabend <john.r.fastabend@...el.com>,
Thomas Graf <tgraf@...g.ch>, Jiri Pirko <jiri@...nulli.us>,
Linux Netdev List <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Andy Gospodarek <andy@...yhouse.net>,
Daniel Borkmann <dborkman@...hat.com>,
Or Gerlitz <ogerlitz@...lanox.com>,
Jesse Gross <jesse@...ira.com>,
"jpettit@...ira.com" <jpettit@...ira.com>,
Joe Stringer <joestringer@...ira.com>,
Jamal Hadi Salim <jhs@...atatu.com>,
Florian Fainelli <f.fainelli@...il.com>,
Roopa Prabhu <roopa@...ulusnetworks.com>,
John Linville <linville@...driver.com>,
Benjamin LaHaise <bcrl@...ck.org>
Subject: Re: Flows! Offload them.
On Mon, Mar 02, 2015 at 02:13:35PM -0800, Scott Feldman wrote:
> On Mon, Mar 2, 2015 at 10:31 AM, Shrijeet Mukherjee <shrijeet@...il.com> 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.
--
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