netdev - RE: [RFC PATCH net-next 0/2] Add new switchdev device class

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <E4CD12F19ABA0C4D8729E087A761DC350F577112@ORSMSX101.amr.corp.intel.com>
Date:	Fri, 28 Aug 2015 02:13:02 +0000
From:	"Arad, Ronen" <ronen.arad@...el.com>
To:	"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>,
	"f.fainelli@...il.com" <f.fainelli@...il.com>,
	"roopa@...ulusnetworks.com" <roopa@...ulusnetworks.com>
Subject: RE: [RFC PATCH net-next 0/2] Add new switchdev device class



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