[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140924133246.GB4966@casper.infradead.org>
Date: Wed, 24 Sep 2014 14:32:46 +0100
From: Thomas Graf <tgraf@...g.ch>
To: Or Gerlitz <ogerlitz@...lanox.com>
Cc: Andy Gospodarek <gospo@...ulusnetworks.com>,
Tom Herbert <therbert@...gle.com>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
Jiri Pirko <jiri@...nulli.us>,
John Fastabend <john.r.fastabend@...el.com>,
Jamal Hadi Salim <jhs@...atatu.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Neil Horman <nhorman@...driver.com>,
Andy Gospodarek <andy@...yhouse.net>,
Daniel Borkmann <dborkman@...hat.com>,
Jesse Gross <jesse@...ira.com>,
Pravin Shelar <pshelar@...ira.com>,
Andy Zhou <azhou@...ira.com>,
Ben Hutchings <ben@...adent.org.uk>,
Stephen Hemminger <stephen@...workplumber.org>,
Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
Vladislav Yasevich <vyasevic@...hat.com>,
Cong Wang <xiyou.wangcong@...il.com>,
Eric Dumazet <edumazet@...gle.com>,
Scott Feldman <sfeldma@...ulusnetworks.com>,
Florian Fainelli <f.fainelli@...il.com>,
Roopa Prabhu <roopa@...ulusnetworks.com>,
John Linville <linville@...driver.com>,
"dev@...nvswitch.org" <dev@...nvswitch.org>,
Jason Wang <jasowang@...hat.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Nicolas Dichtel <nicolas.dichtel@...nd.com>,
ryazanov.s.a@...il.com, Lennert Buytenhek <buytenh@...tstofly.org>,
aviadr@...lanox.com, Felix Fietkau <nbd@...nwrt.org>,
Neil Jerram <Neil.Jerram@...aswitch.com>, ronye@...lanox.com,
simon.horman@...ronome.com,
Alexander Duyck <alexander.h.duyck@...el.com>
Subject: Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
On 09/23/14 at 06:32pm, Or Gerlitz wrote:
> Indeed.
>
> The idea is to leverage OVS to manage eSwitch (embedded NIC switch) as well
> (NOT to offload OVS).
>
> We envision a seamless integration of user environment which is based on OVS
> with SRIOV eSwitch and the grounds for that were very well supported in
> Jiri’s V1.
Please consider comparing your model with what is described here [0].
I'm trying to write down an architecture document that we can finalize
in Düsseldorf.
[0] http://goo.gl/qkzW5y
> The eSwitch hardware does not need to have multiple tables and ‘enjoys’ the
> flat rule of OVS. The kernel datapath does not need to be aware of the
> existence of HW nor its capabilities, it just pushes the flow also to the
> switchdev which represents the eSwitch.
I think you are saying that the kernel should not be required to make
the offload decision which is fair. We definitely don't want to force
the decision to be outside though, there are several legit reasons to
support transparent offloads within the kernel as well outside of OVS.
> Yep. LPC is the time and place to go over the multiple use-cases (phyiscal
> switch, eSwitch, eBPF, etc) that could (should) be supported by the basic
> framework.
For reference:
http://www.linuxplumbersconf.org/2014/ocw/proposals/2463
--
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