netdev - Re: [net-next PATCH v3 00/12] Flow API

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: <20150123102421.GB2065@nanopsycho.orion>
Date:	Fri, 23 Jan 2015 11:24:21 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	Jamal Hadi Salim <jhs@...atatu.com>,
	Pablo Neira Ayuso <pablo@...filter.org>,
	John Fastabend <john.fastabend@...il.com>,
	simon.horman@...ronome.com, sfeldma@...il.com,
	netdev@...r.kernel.org, davem@...emloft.net, gerlitz.or@...il.com,
	andy@...yhouse.net, ast@...mgrid.com
Subject: Re: [net-next PATCH v3 00/12] Flow API

Fri, Jan 23, 2015 at 11:10:19AM CET, tgraf@...g.ch wrote:
>On 01/22/15 at 10:44am, Jamal Hadi Salim wrote:
>> On 01/22/15 10:37, Thomas Graf wrote:
>> >On 01/22/15 at 10:28am, Jamal Hadi Salim wrote:
>> 
>> >>So if i am a vendor with my own driver, I can expose whatever i want.
>> >
>> >No. We will reject any driver change attempting to do so on this
>> >list.
>> >
>> 
>> Vendor provides a driver that exposes a discoverable interface
>> (capabilities exposure that is facilitated).
>> They dont need it to be part of the mainstream kernel.
>> And they dont need any of your definitions.
>
>An out of tree driver always had the possibility to register its own
>Generic Netlink protocol and do exactly what you describe. The same
>driver could also register as { xt, cls, act } module and export direct
>hardware access to userspace through tc and iptables. The driver could
>even register its own netfilter hook. You can abuse pretty much any
>interface that has some form of registration mechansim from an out of
>tree driver. We can't really control that.
>
>I think we agree that the value of this model is that tools like nft,
>OVS, SnabbSwitch, tc, [you name it] can use it to program the hardware
>in a very generic manner from user space without requiring to move all
>of that complexity to the kernel. In the very same way as the team
>device exports most of the complexity to user space. Or for the same
>reason routing protocol implementations were kept out of the kernel.


I think that comparing this to team or routing userspace is not
correct. The reason is that team and routing has single api to kernel.
However in this case userspace has to use multiple APIs.

For example OVS. It would have to use existing OVS gennetlink iface + this
new flow netlink iface for flow offloads. For all others, this is the same.
Multiple apis for the same thing (does not matter if it is implemented
in hw or sw) does not seem right to me.


>
>If a vendor exposes capabilities in a form that is not understood by
>the well known tools it has zero value because the capabilities can't
>be used. Any tool that would depend on such vendor specific bits that
>are exported by out of tree drivers might as well use the existing
>vendor SDKs which will always provide some additional functionality
>because it doesn't have to compromise.
>
--
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