On 27/08/15 19:13, Arad, Ronen wrote: > > >> -----Original Message----- >> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On >> Behalf Of sfel...@gmail.com >> Sent: Thursday, August 27, 2015 12:17 AM >> To: netdev@vger.kernel.org >> Cc: j...@resnulli.us; da...@davemloft.net; f.faine...@gmail.com; >> ro...@cumulusnetworks.com >> Subject: [RFC PATCH net-next 0/2] Add new switchdev device class >> >> From: Scott Feldman <sfel...@gmail.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html