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  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 01:23:53 -0700
From:	Scott Feldman <>
To:	John Fastabend <>
Cc:	Netdev <>,
	Jiří Pírko <>,
	"David S. Miller" <>,
	Florian Fainelli <>,
	Roopa Prabhu <>
Subject: Re: [RFC PATCH net-next 0/2] Add new switchdev device class

On Thu, Aug 27, 2015 at 12:36 AM, John Fastabend
<> wrote:
> On 15-08-27 12:16 AM, wrote:
>> From: Scott Feldman <>
>> 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.
>>       [TABLE]
>>               [FIELDS]
>>                       [FIELD]
>>                               [ID, TYPE]
>>               [DATA]
>>                       [ID, VALUE]
> The structure I used previously which looks like your prototype I think,
>  (
>  *     [NFL_TABLE]
>  *       [NFL_TABLE_ATTR_NAME]
>  *       [NFL_TABLE_ATTR_UID]
>  *       [NFL_TABLE_ATTR_SIZE]
>  *         [NFL_FIELD_REF]
>  *           [NFL_FIELD_REF_INSTANCE]
>  *           [NFL_FIELD_REF_HEADER]
>  *           [NFL_FIELD_REF_FIELD]
>  *           [NFL_FIELD_REF_MASK]
>  *           [NFL_FIELD_REF_TYPE]
>  *         [...]
>  *           [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
More majordomo info at

Powered by blists - more mailing lists