Date:	Thu, 27 Aug 2015 01:17:54 -0700
From:	Scott Feldman <sfeldma@...il.com>
To:	Jiri Pirko <jiri@...nulli.us>
Cc:	Netdev <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Florian Fainelli <f.fainelli@...il.com>,
	Roopa Prabhu <roopa@...ulusnetworks.com>
Subject: Re: [RFC PATCH net-next 0/2] Add new switchdev device class

On Thu, Aug 27, 2015 at 12:27 AM, Jiri Pirko <jiri@...nulli.us> wrote:
> Thu, Aug 27, 2015 at 09:16:44AM CEST, sfeldma@...il.com wrote:
>>From: Scott Feldman <sfeldma@...il.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.

I see no harm in using the device model to define and new device class
which just so happens to show up in sysfs.  What sysfs attrs get
exposed is where we can have some discussion/rules.

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

Read-only is fine.  Look, I'm just trying to dump rocker internal
tables in some format I can grep outside the kernel.  The tables are
get big and complicated fast and printk doesn't cut it.   I can use
degugfs privately, but I need to be able to dump same for field
troubleshooting.   I can't use debugfs, so I want some kind of
XML-like dump facility.  It's going to have device-specific data, so
I'm looking for an XML-like way to represent this data in netlink.

>>
>>Maybe iproute2 has pretty-printers for specific switches like ethtool has for
>>reg dumps.
>
> I feel like a lot of what you described overlaps with existing
> interfaces and tools. Why don't we just reuse that? For firmware for
> example, just take one of the ports. Same for stats (I plan to expose my
> mlxsw switch-wide stats in ethtool so they are accessible through every
> port netdevice).

Port-centric stats are fine for port netdevs, but I'd like switch-wide
stats to show up elsewhere.

Thinking ahead: I'd like to put port into namespaces and I don't want
to dump stats on a port and see stats on ports in other namespaces.

> I still do not see the need for new device class. I have strong feeling
> that it should be avoided.

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