netdev - Re: [net-next PATCH 0/5] net_sched: Add support for IFE action

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: <56CF7370.7020100@iogearbox.net>
Date:	Thu, 25 Feb 2016 22:34:40 +0100
From:	Daniel Borkmann <daniel@...earbox.net>
To:	Jamal Hadi Salim <jhs@...atatu.com>, davem@...emloft.net
CC:	netdev@...r.kernel.org, xiyou.wangcong@...il.com,
	alexei.starovoitov@...il.com
Subject: Re: [net-next PATCH 0/5] net_sched: Add support for IFE action

On 02/25/2016 01:23 PM, Jamal Hadi Salim wrote:
> On 16-02-24 12:48 PM, Daniel Borkmann wrote:
>> On 02/24/2016 01:49 PM, Jamal Hadi Salim wrote:
[...]
>>> Drivers do set the hash. My use case is slightly different.
>>> I have a NIC which has an embedded cavium processor. This thing
>>> strips off the TLV and uses the hash to select the host MSI.
>>> Only thing we dont use at the moment is queue_mapping.
>>
>> Ok, but the example says ingress qdisc. ;) I presume the driver for the
>> NIC and the offloading parts are non-public? :/
>
> Well, it is not exactly mellanox or intel - but I am sure someone would
> be willing to sell that NIC.
>
>> So, without them, placing
>> this on ingress qdisc doesn't seem much useful wrt the skb hash example,
>> and most people only have the software part (for ingress I mean) available.
>
> Do you want me to take skbbhash out? I just want to get this set in then
> worry about adding and modifying.

Well, if the NIC driver and offloading parts for ife are not available
(or cannot be made available) in the upstream kernel tree, then you have
to assume that everyone else can _only_ use this with the existing tc
facilities in the kernel. And as such, the whole set needs to be evaluated,
I think this is nothing new. ;-)

That is why I asked for a "typical setup" and use-case earlier. And if
it doesn't have any obvious ones in upstream context without the missing
pieces, then the code might linger around unused by anyone. So taking out
these parts would be highly preferred (unless there's a _good_ reason not
to).

Thanks,
Daniel