netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: sfeldma@gmail.com, netdev@vger.kernel.org
Cc: jiri@resnulli.us, davem@davemloft.net, f.fainelli@gmail.com,
	roopa@cumulusnetworks.com
Subject: Re: [RFC PATCH net-next 0/2] Add new switchdev device class
Date: Thu, 27 Aug 2015 00:36:20 -0700	[thread overview]
Message-ID: <55DEBDF4.8030301@gmail.com> (raw)
In-Reply-To: <1440659806-56582-1-git-send-email-sfeldma@gmail.com>

On 15-08-27 12:16 AM, sfeldma@gmail.com wrote:
> From: Scott Feldman <sfeldma@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
> 
> 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.

> Maybe iproute2 has pretty-printers for specific switches like ethtool has for
> reg dumps.
> 
> I don't know about how this overlaps with DSA platform_class.  Florian?
> 
> Comments?

A few other interesting (at least to me) structures you can find in the
if_flow.h header file give how the tables in the hardware are put
together. I found this really useful when trying to sort out where my
various ACLs/nexthop entries/etc were in the hardware order. This is
important to know for many cases. This is NFL_TABLE_GRAPH.

Also I found being able to "know' what headers the hardware supports
to be very useful. For example I want/need to know if QinQ will work.
Or VXLAN/NSH, Geneve, etc. This is NFL_HEADER_GRAPH.

Sure if_flow.h is a poor name and FlowAPI is probably not really great.
But both those names come from how I model the hardware as match action
tables. I can change those names to switchdev_resources or
switchdev_info if folks want.

My point is the interface is generic and provides a common interface for
most hardware I've seen to date. Certainly curious if there is hardware
it doesn't map to. Although tables and pipelines seems fairly universal
for a large set of devices to me. Further it can be extended as needed.

I'll drop the set_rule/del_rule parts to be merged with ebpf/tc/qdisc.

.John


> 
> 
> Scott Feldman (2):
>   switchdev: create new switchdev device class
>   rocker: register each switch as a switchdev
> 
>  drivers/net/ethernet/rocker/rocker.c |   23 ++++++++++
>  include/net/switchdev.h              |   16 +++++++
>  net/switchdev/switchdev.c            |   76 ++++++++++++++++++++++++++++++++++
>  3 files changed, 115 insertions(+)
> 

  parent reply	other threads:[~2015-08-27  7:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-27  7:16 [RFC PATCH net-next 0/2] Add new switchdev device class sfeldma
2015-08-27  7:16 ` [RFC PATCH net-next 1/2] switchdev: create " sfeldma
2015-08-27  7:16 ` [RFC PATCH net-next 2/2] rocker: register each switch as a switchdev sfeldma
2015-08-27  7:27 ` [RFC PATCH net-next 0/2] Add new switchdev device class Jiri Pirko
2015-08-27  7:43   ` John Fastabend
2015-08-27  7:51     ` Jiri Pirko
2015-08-27  8:14       ` John Fastabend
2015-08-27  8:17   ` Scott Feldman
2015-08-27  8:41     ` Jiri Pirko
2015-08-27  7:36 ` John Fastabend [this message]
2015-08-27  7:44   ` Jiri Pirko
2015-08-27  8:09     ` John Fastabend
2015-08-27  8:23   ` Scott Feldman
2015-08-27  7:45 ` Andrew Lunn
2015-08-27  8:42   ` Scott Feldman
2015-08-27  9:06     ` Andrew Lunn
2015-08-27 16:41       ` Scott Feldman
2015-08-28 11:52         ` Andrew Lunn
2015-08-27 13:54 ` John W. Linville
2015-08-27 23:25 ` David Miller
2015-08-28  2:13 ` Arad, Ronen
2015-08-28 16:55   ` Florian Fainelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55DEBDF4.8030301@gmail.com \
    --to=john.fastabend@gmail.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=roopa@cumulusnetworks.com \
    --cc=sfeldma@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).