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
