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]

Date:	Thu, 25 Feb 2016 17:40:45 -0500
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Daniel Borkmann <daniel@...earbox.net>, 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 16-02-25 04:34 PM, Daniel Borkmann wrote:
> 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)

If you are willing to pay for one i can have one sold to you.
Note: There is no dependency on such a NIC. You asked for an example
of how one would use skbhash and i pointed it out to you.
Infact nothing in the commit notes pointed to any NIC.

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

Seriously this is getting to a ridiculous level now.
I gave a talk - which you attended. I wrote a paper which you may have
at minimal glanced at.
I have had discussions with you on this very subject.
And as soon as i posted the patches your statements led from you
needing a good use case to why not use a netdev and why i have
all these things that are not very useful. None of which came up before.
For someone who works on ebpf - where there is plenty of code that
noone gets to see you are making rather bold statements.

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

So is there anything that is useful in your view?

cheers,
jamal