netdev - Re: [patch net-next 09/14] rocker: add rtnl ops for port mode [gs]etting

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: <5612AE52.9040809@gmail.com>
Date:	Mon, 05 Oct 2015 10:07:30 -0700
From:	John Fastabend <john.fastabend@...il.com>
To:	Jiri Pirko <jiri@...nulli.us>
CC:	Scott Feldman <sfeldma@...il.com>, Netdev <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Ido Schimmel <idosch@...lanox.com>, eladr@...lanox.com,
	Thomas Graf <tgraf@...g.ch>,
	Alexei Starovoitov <ast@...mgrid.com>
Subject: Re: [patch net-next 09/14] rocker: add rtnl ops for port mode [gs]etting

[...]

>>> Does this mean there is going to be a "ip link set dev DEV type rocker
>>> mode MODE" command option?
>>>
>>> It doesn't seem right to be adding driver-specific IFLA_'s here.  I
>>> think this sets bad precedence for other drivers to add their own
>>> knobs without thinking about a generic shared mechanism.
>>>
>>> Actually, I don't see the point of letting the user dynamically change
>>> the port mode.  I would prefer this knob be moved to qemu/rocker.  Let
>>> the port mode be specified on device creation.
>>>
>>
>> I agree until we have the infrastructure to "understand" what these
>> knobs are fundamentally doing I would prefer it to stay in qemu/rocker.
> 
> Why? If it is possible to set it from driver, why not to expose this to
> user? I don't see a point.


> 
> Let's find an interface and do it. Note that this is far from the first
> thing that could be set from userspace and is not possible, just because
> there is no suitable interface. Vendors then come up with some arbitrary
> blob-based solution to do it. Far from nice :/


I think I've been one of the folks pushing for exposing the hardware :)

My issue with this is its very close to pushing the blob itself. Its
basically an opaque reference to the binary blob itself with no way
to understand what the blob is doing. And no way to standardize the
blobs across hardware.

> 
> 
>>
>> I would rather see commands like "add a table", "remove a table", "add
>> header x to parser" where the operations are well defined. This lends
>> itself well to flexible devices that can be configured at runtime. At
>> least this fits more into my mental model of how we have been managing
>> these devices today. This would allow users to push the "worlds" into
>> the device to match their use cases e.g. add more l3 ipv4 rules vs l3
>> ipv6 rules etc.
> 
> Again, to make this clear, worlds are not just a rehash of tables.
> 

what are they then? Lets model those bits and let users configure them
at runtime.

So far I've had really good results modelling hardware as a 'parser',
a set of tables, and a set of modify blocks. Now this breaks when you
start to add black boxes in there for other functions such as encryption
but I don't think your getting at that. Do you see something that
couldn't be configured/modelled with those blocks?

.John

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