Message-ID: <55E0929B.2060800@gmail.com>
Date:	Fri, 28 Aug 2015 09:55:55 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	"Arad, Ronen" <ronen.arad@...el.com>,
	"sfeldma@...il.com" <sfeldma@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:	"jiri@...nulli.us" <jiri@...nulli.us>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"roopa@...ulusnetworks.com" <roopa@...ulusnetworks.com>
Subject: Re: [RFC PATCH net-next 0/2] Add new switchdev device class

On 27/08/15 19:13, Arad, Ronen wrote:
> 
> 
>> -----Original Message-----
>> From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org] On
>> Behalf Of sfeldma@...il.com
>> Sent: Thursday, August 27, 2015 12:17 AM
>> To: netdev@...r.kernel.org
>> Cc: jiri@...nulli.us; davem@...emloft.net; f.fainelli@...il.com;
>> roopa@...ulusnetworks.com
>> Subject: [RFC PATCH net-next 0/2] Add new switchdev device class
>>
>> From: Scott Feldman <sfeldma@...il.com>
>>
>>
>> So what next?  I'd rather not build APIs around sysfs, so we need a netlink
>> API
>> we can build on top of this.  It's not really rtnl.  Maybe genl would work?
>> What ever it is, we'd need to teach iproute2 about a new 'switch' command.
>>
> [@Ronen] I developed PoC code based on genl which allows access for what I
> call device options. It generalizes libteam/team driver option handling.
> It allows for fields of all Netlink scalar or string types as well as arrays.
> It differentiates between port-specific and device options.

OpenWrt has had a similar scheme, called swconfig:

Kernel code:

https://dev.openwrt.org/browser/trunk/target/linux/generic/files/drivers/net/phy/swconfig.c

User-space tools:

https://dev.openwrt.org/browser/trunk/package/network/config/swconfig/src

This was initially proposed but was rejected in favor of what became
switchdev because it did not focus exclusively on the switch device (as
a whole piece of hardware), but rather allowed configuration of things
that were already available through bridge/vlan etc..

Having a netlink interface to interface with a global (as in, not
per-port) switch device sounds like a good idea, especially if there are
events that need to be sent back to user-space, my only major concern
with this approach is to make sure there is careful review of what goes
into this interface such that:

- it is strongly defined, not just allow sending custom
u8/u16/u32/u64/blobs attributes back and forth, but rather have a
properly defined set of commands and associated data-structures

- this always covers something that is not, by nature a switch
port/physical interface attribute, and for which there is not an
existing interface

Bottom line being that it is very easy for this interface to be a
catch-all, dumping ground of things that did not fit within existing
facilities...

> (It was not limited to read-only but this could be changed to address the
>  concerns raised on this thread)
> Extending to Tables from just a list of named options is welcomed.
> 
> The diagram below shows possible architecture.
> 
> +-----------------------------------------+
> |      tool (e.g. swdevnl, iproute2)      |
> +-----------------------------------------+
>                |
>             +-----------------+
>             |     libswdev    |
>             +-----------------+
>                |
>       +-----------------------------+
>       |          libnl3             |
>       +-----------------------------+
>                |
> User           |
> -------------------------------------------------
> Kernel         |
>                |
> +-------------------+ +-------------------+
> |     genetlink     | |     rtnetlink     |
> +-------------------+ +-------------------+
>                |
>         +-----------+
>         |   swdev   |
>         +-----------+
>                |
> +-----------------------------------------+
> |                                         |
> |              SOMEswitch                 |
> |                                         |
> +-----------------------------------------+
> 
> Libswdev in the diagram is a user space library which should abstract the
> netlink interaction and encoding details from user-space tools.
> 
> Swdev is a kernel module which provides similar abstraction to drivers. It 
> saves drivers from most of the low level code.
> 
> Drivers register their supported options (or Table/Fields) with this module
> and provide getters functions. The Swdev kernel module provides the genl API
> for exporting device specific information.
> 
> This architecture allows for a generic tool to discover the information
> available from each driver/port. The tool could extract sufficient
> information which allows it to present user-friendly interface to users for
> drilling down and retrieving specific details.  
> 
>> Netlink API would allow us to represent switch-wide objects such as registers,
>> tables, stats, firmware, and maybe even control.  I think with with netlink
>> TLVs, we can create a framework for these objects but still allow the switch
>> driver provide switch-specific info.  For example, a table object:
>>
>> [TABLES]
>> 	[TABLE]
>> 		[FIELDS]
>> 			[FIELD]
>> 				[ID, TYPE]
>> 		[DATA]
>> 			[ID, VALUE]
>>
> [@Ronen] Some additional information could be useful. TABLE name, FIELD name,
> (possible also short names for CLI commands or pretty printing of table
> header), FIELD value range (help with pp), TABLE/FIELD description.
> 
>> Maybe iproute2 has pretty-printers for specific switches like ethtool has for
>> reg dumps.
>>


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