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]

Date:	Thu, 27 Aug 2015 09:44:18 +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:36:20AM CEST, john.fastabend@...il.com wrote:
>On 15-08-27 12:16 AM, 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
>> 
>> 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:
>> 
>
>Hi Scott,
>
>I was going to take the flow-api presented in Feb and submitted
>to netdev and get it up to date. I started doing this today should be
>ready end of week.
>
>> [TABLES]
>> 	[TABLE]
>> 		[FIELDS]
>> 			[FIELD]
>> 				[ID, TYPE]
>> 		[DATA]
>> 			[ID, VALUE]
>> 
>
>The structure I used previously which looks like your prototype I think,
>
> (https://github.com/jrfastab/rocker-net-next/blob/master/include/uapi/linux/if_flow.h)
>
> * [NFL_TABLE_IDENTIFIER_TYPE]
> * [NFL_TABLE_IDENTIFIER]
> * [NFL_TABLE_TABLES]
> *     [NFL_TABLE]
> *	 [NFL_TABLE_ATTR_NAME]
> *	 [NFL_TABLE_ATTR_UID]
> *	 [NFL_TABLE_ATTR_SOURCE]
> *	 [NFL_TABLE_ATTR_APPLY]
> *	 [NFL_TABLE_ATTR_SIZE]
> *	 [NFL_TABLE_ATTR_MATCHES]
> *	   [NFL_FIELD_REF]
> *	     [NFL_FIELD_REF_INSTANCE]
> *	     [NFL_FIELD_REF_HEADER]
> *	     [NFL_FIELD_REF_FIELD]
> *	     [NFL_FIELD_REF_MASK]
> *	     [NFL_FIELD_REF_TYPE]
> *	   [...]
> *	 [NFL_TABLE_ATTR_ACTIONS]
> *	     [NFL_ACTION_ATTR_UID]
> *	     [...]
> *     [NFL_TABLE]
> *       [...]
> *
>
>This is well-typed per Dave's comment. And because its Netlink based it
>can be easily extended as needed. The above gives basic information on
>the table. Sure it could stand to have some other entries in it but I
>never needed them for my capabilities/resource discovery. We could argue
>about removing some if they are too specific to my use cases.

I guess you are talking about read-only interface right?

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