Thu, Aug 27, 2015 at 09:43:54AM CEST, john.fastab...@gmail.com wrote: >On 15-08-27 12:27 AM, Jiri Pirko wrote: >> Thu, Aug 27, 2015 at 09:16:44AM CEST, sfel...@gmail.com wrote: >>> From: Scott Feldman <sfel...@gmail.com> >>> >>> In the switchdev model, we use netdevs to represent switchdev ports, but we >>> have no representation for the switch itself. So, introduce a new switchdev >>> device class so we can define semantics and programming interfaces for the >>> switch itself. Switchdev device class isn't tied to any particular bus. >>> >>> This patch set is just the skeleton to get us started. It adds the sysfs >>> object registration for the new class and defines a class-level attr "foo". >>> With the new class, we could hook PM functions, for example, to handle power >>> transitions at the switch level. I registered rocker and get: >>> >>> $ ls /sys/class/switchdev/5254001235010000/ >>> foo power subsystem uevent >> >> No, please avoid adding anything to sysfs. If we need to add anything, >> lets make is accesible using Netlink only. >> >> >>> >>> 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. >>> >>> 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] >> >> Alert! I feel that someone would like to abuse this iface for writing >> configuration through. This should be read-only by design. I also think >> that this should not be something switch-specific. I believe that NIC >> drivers would benefit from this iface as well when they want to expose >> something. I think we should use genl for this. >> > >One place where read-only may not make sense is when the tables can >be provisioned/configured. Many switches have the ability to be >configured with "profiles". For a simple example some hardware use a >single table that can be divided into an IPv4 and an IPv6 section.
Okay. That should be configured via separate configuration Netlink interface - ConfNetlink. I already spoke with Dave about need for that one: Netlink based, use PCI-addr (other addr) as a handle, well-defined config objects. The need to this interface is bigger and bigger. I can cook-up some RFC patch so you see what I'm talking about. -- 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
