Date:	Wed, 26 Mar 2014 06:55:11 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	Florian Fainelli <f.fainelli@...il.com>,
	Jamal Hadi Salim <jhs@...atatu.com>,
	Jiri Pirko <jiri@...nulli.us>, netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Andy Gospodarek <andy@...yhouse.net>,
	dborkman <dborkman@...hat.com>, ogerlitz <ogerlitz@...lanox.com>,
	jesse <jesse@...ira.com>, pshelar <pshelar@...ira.com>,
	azhou <azhou@...ira.com>, Ben Hutchings <ben@...adent.org.uk>,
	Stephen Hemminger <stephen@...workplumber.org>,
	jeffrey.t.kirsher@...el.com, vyasevic <vyasevic@...hat.com>,
	Cong Wang <xiyou.wangcong@...il.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Scott Feldman <sfeldma@...ulusnetworks.com>,
	Lennert Buytenhek <buytenh@...tstofly.org>
Subject: Re: [patch net-next RFC 0/4] introduce infrastructure for support of
 switch chip datapath

On Tue, Mar 25, 2014 at 09:54:53PM +0000, Thomas Graf wrote:
> On 03/25/14 at 02:42pm, Florian Fainelli wrote:
> > 2014-03-25 14:26 GMT-07:00 Thomas Graf <tgraf@...g.ch>:
> > > On 03/25/14 at 01:11pm, Florian Fainelli wrote:
> > >> 2014-03-25 12:35 GMT-07:00 Neil Horman <nhorman@...driver.com>:
> > >> > On Tue, Mar 25, 2014 at 06:00:09PM +0000, Thomas Graf wrote:
> > >> >> On top of that, like for VFs, we provide extended nested attributes or
> > >> >> alternate control paths such as via OVS that provide the additional
> > >> >> flexibility and control required by the more advanced devices.
> > >> > I'm sorry, I don't understand the relevance here.  Are you suggesting that to
> > >> > make this modification, we would need to augment more than a single set of
> > >> > netlink control paths?
> > >>
> > >> Not sure if I got this right, but there might be additional control
> > >> knobs required for specific Ethernet switch features that do not map
> > >> nicely, if at all with existing interfaces provided by ip/tc,
> > >> ethtool... although I guess one would say, well, then go add these
> > >> APIs instead of creating "extended" ones?
> > >
> > > Exactly. Some of the logic and configuration structure will not
> > > fit the existing model and is too switch specific to justify
> > > extending the generic link model. It also seems likely that some
> > > knobs will be switch specific. Not an issue as long as they are
> > > tunneled through the standard API and any effort is undertaken
> > > to generalize where it makes sense.
> > 
> > The question is how you would imagine conveying these switch-specific
> > features that do not (yet) map into a general feature, shall we go for
> > a separate netlink family, just like what Felix did in OpenWrt with
> > swconfig, without much stability from one kernel release to another,
> > as we migrate what was once a switch specific feature into a general
> > Ethernet switch feature?
> 
> I believe it is essential to transport them as part of the standard
> Netlink API and have a single channel for all configuration. It also
> eases message synchronization.
> 
> We also want to enforce strict ABI compatibility rules just like
> for all other Netlink users. As we know, it's not difficult to design
> the message format in a way to allow for extendability and backwards
> compatibility.
> 

+1, I'm not sure what the extent of any additional feature set is, for any
particular piece of hardware, but whatever it is almost certainly needs to be
baked into the same netlink protocol(s), so as to implicitly enforce ordering of
configuration.

Neil

--
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