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: <20150827075110.GM2228@nanopsycho.orion>
Date:	Thu, 27 Aug 2015 09:51:10 +0200
From:	Jiri Pirko <jiri@...nulli.us>
To:	John Fastabend <john.fastabend@...il.com>
Cc:	sfeldma@...il.com, netdev@...r.kernel.org, davem@...emloft.net,
	f.fainelli@...il.com, roopa@...ulusnetworks.com
Subject: Re: [RFC PATCH net-next 0/2] Add new switchdev device class

Thu, Aug 27, 2015 at 09:43:54AM CEST, john.fastabend@...il.com wrote:
>On 15-08-27 12:27 AM, Jiri Pirko 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.
>> 
>> 
>>>
>>> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html