From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Fainelli Subject: Re: [patch net-next RFC 0/4] introduce infrastructure for support of switch chip datapath Date: Tue, 25 Mar 2014 14:42:08 -0700 Message-ID: References: <532AD5B3.6020205@mojatatu.com> <20140320124021.GA2946@minipsycho.orion> <532C2AC4.7080303@mojatatu.com> <20140322094852.GB2844@minipsycho.orion> <5330BAB7.3040501@mojatatu.com> <20140325173927.GE8102@hmsreliant.think-freely.org> <20140325180009.GB15723@casper.infradead.org> <20140325193533.GF8102@hmsreliant.think-freely.org> <20140325212632.GD15723@casper.infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Neil Horman , Jamal Hadi Salim , Jiri Pirko , netdev , David Miller , Andy Gospodarek , dborkman , ogerlitz , jesse , pshelar , azhou , Ben Hutchings , Stephen Hemminger , jeffrey.t.kirsher@intel.com, vyasevic , Cong Wang , John Fastabend , Eric Dumazet , Scott Feldman , Lennert Buytenhek To: Thomas Graf Return-path: Received: from mail-lb0-f176.google.com ([209.85.217.176]:64888 "EHLO mail-lb0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751431AbaCYVmu (ORCPT ); Tue, 25 Mar 2014 17:42:50 -0400 Received: by mail-lb0-f176.google.com with SMTP id 10so856038lbg.35 for ; Tue, 25 Mar 2014 14:42:49 -0700 (PDT) In-Reply-To: <20140325212632.GD15723@casper.infradead.org> Sender: netdev-owner@vger.kernel.org List-ID: 2014-03-25 14:26 GMT-07:00 Thomas Graf : > On 03/25/14 at 01:11pm, Florian Fainelli wrote: >> 2014-03-25 12:35 GMT-07:00 Neil Horman : >> > 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? -- Florian