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: <CAE4R7bCo2GqEtXvZw9s9tiTPNLd_=9L_fGAGSJiNTiTDBYvQzw@mail.gmail.com>
Date:	Thu, 27 Aug 2015 01:23:53 -0700
From:	Scott Feldman <sfeldma@...il.com>
To:	John Fastabend <john.fastabend@...il.com>
Cc:	Netdev <netdev@...r.kernel.org>,
	Jiří Pírko <jiri@...nulli.us>,
	"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:36 AM, John Fastabend
<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 was looking for something more generic.  Not quite as raw as ethtool
reg dump, but not too rigid I have to bend the def of fields to make
it work.  Maybe what I want is impossible.

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

Ya, you're talking about tables in hardware.  I just want to dump some
driver-internal driver-specific data in tabular form to user-space so
I can grep thru it and debug.
--
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