[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8d10f338-fd11-4033-f0e0-b6fca42a5495@mellanox.com>
Date: Thu, 9 Jul 2020 09:52:07 -0400
From: Ariel Levkovich <lariel@...lanox.com>
To: Cong Wang <xiyou.wangcong@...il.com>,
Jamal Hadi Salim <jhs@...atatu.com>
Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>,
Jiri Pirko <jiri@...nulli.us>, Jiri Pirko <jiri@...lanox.com>,
Jakub Kicinski <kuba@...nel.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>
Subject: Re: [PATCH net-next v2 0/3] ] TC datapath hash api
Not sure it was sent so trying again...
On 7/5/20 8:28 PM, Cong Wang wrote:
> On Sun, Jul 5, 2020 at 2:50 PM Jamal Hadi Salim <jhs@...atatu.com> wrote:
>> BTW, nothing in skbedit is against computing what the new metadata
>> should be.
> Yup.
>
>> IMO: A good arguement to not make it part of skbedit is if it adds
>> unnecessary complexity to skbedit or policy definitions.
>>
> TCA_HASH_ALG_L4 literally has 4 lines of code, has no way
> to add any unnecessary complexity to skbedit. (The BPF algorithm
> does not belong to skbedit, obviously.)
>
> Thanks.
Moving TCA_HASH_ALG_L4 to skbedit is very simple, I agree.
However, supporting the bpf option via act_bpf is still problematic as
it is not offloadable.
We need some kind of indication that this is a hash computation program
and therefore
it requires specific identifier in the form of a new action.
Ariel
Powered by blists - more mailing lists