On 03/25/14 at 02:42pm, Florian Fainelli wrote:

2014-03-25 14:26 GMT-07:00 Thomas Graf [off-list ref]:

quoted

On 03/25/14 at 01:11pm, Florian Fainelli wrote:

quoted

2014-03-25 12:35 GMT-07:00 Neil Horman [off-list ref]:

quoted

On Tue, Mar 25, 2014 at 06:00:09PM +0000, Thomas Graf wrote:

quoted

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.