From: Jamal Hadi Salim <jhs@mojatatu•com>
To: Daniel Borkmann <daniel@iogearbox•net>, davem@davemloft•net
Cc: netdev@vger•kernel.org, xiyou.wangcong@gmail•com,
alexei.starovoitov@gmail•com
Subject: Re: [net-next PATCH 0/5] net_sched: Add support for IFE action
Date: Thu, 25 Feb 2016 17:40:45 -0500 [thread overview]
Message-ID: <56CF82ED.3080307@mojatatu.com> (raw)
In-Reply-To: <56CF7370.7020100@iogearbox.net>
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
next prev parent reply other threads:[~2016-02-25 22:40 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-22 13:21 [net-next PATCH 0/5] net_sched: Add support for IFE action Jamal Hadi Salim
2016-02-22 13:21 ` [net-next PATCH 1/5] introduce " Jamal Hadi Salim
2016-02-22 13:21 ` [net-next PATCH 2/5] Support to encoding decoding skb mark on " Jamal Hadi Salim
2016-02-22 13:21 ` [net-next PATCH 3/5] Support to encoding decoding skb prio " Jamal Hadi Salim
2016-02-22 17:01 ` Daniel Borkmann
2016-02-22 13:21 ` [net-next PATCH 4/5] Support to encoding decoding skb hashid " Jamal Hadi Salim
2016-02-22 16:56 ` Daniel Borkmann
2016-02-22 13:21 ` [net-next PATCH 5/5] Support to encoding decoding skb queue map " Jamal Hadi Salim
2016-02-22 16:59 ` Daniel Borkmann
2016-02-22 21:03 ` John Fastabend
2016-02-23 12:17 ` Jamal Hadi Salim
2016-02-23 19:33 ` John Fastabend
2016-02-22 16:47 ` [net-next PATCH 0/5] net_sched: Add support for " Daniel Borkmann
2016-02-23 12:09 ` Jamal Hadi Salim
2016-02-23 13:20 ` Daniel Borkmann
2016-02-23 14:28 ` Jamal Hadi Salim
2016-02-23 15:34 ` Daniel Borkmann
2016-02-24 12:49 ` Jamal Hadi Salim
2016-02-24 17:48 ` Daniel Borkmann
2016-02-25 12:23 ` Jamal Hadi Salim
2016-02-25 21:34 ` Daniel Borkmann
2016-02-25 22:40 ` Jamal Hadi Salim [this message]
2016-02-26 0:03 ` Daniel Borkmann
2016-02-24 17:58 ` Daniel Borkmann
2016-02-25 12:35 ` Jamal Hadi Salim
2016-02-23 7:00 ` Cong Wang
2016-02-23 12:18 ` Jamal Hadi Salim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56CF82ED.3080307@mojatatu.com \
--to=jhs@mojatatu$(echo .)com \
--cc=alexei.starovoitov@gmail$(echo .)com \
--cc=daniel@iogearbox$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
--cc=xiyou.wangcong@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox