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: <2cfac051-e2fc-e751-72e3-237aa20e7278@mellanox.com>
Date:   Wed, 15 Jul 2020 09:30:23 -0400
From:   Ariel Levkovich <lariel@...lanox.com>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Jiri Pirko <jiri@...nulli.us>,
        Jakub Kicinski <kuba@...nel.org>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Jiri Pirko <jiri@...lanox.com>
Subject: Re: [PATCH net-next v3 2/4] net/sched: Introduce action hash

On 7/15/20 2:12 AM, Cong Wang wrote:
> On Mon, Jul 13, 2020 at 8:17 PM Ariel Levkovich <lariel@...lanox.com> wrote:
>> On 7/13/20 6:04 PM, Cong Wang wrote:
>>> On Sat, Jul 11, 2020 at 2:28 PM Ariel Levkovich <lariel@...lanox.com> wrote:
>>>> Allow user to set a packet's hash value using a bpf program.
>>>>
>>>> The user provided BPF program is required to compute and return
>>>> a hash value for the packet which is then stored in skb->hash.
>>> Can be done by act_bpf, right?
>> Right. We already agreed on that.
>>
>> Nevertheless, as I mentioned, act_bpf is not offloadable.
>>
>> Device driver has no clue what the program does.
> What about offloading act_skbedit? You care about offloading
> the skb->hash computation, not about bpf.
>
> Thanks.


That's true but act_skedit provides (according to the current design) hash

computation using a kernel implemented algorithm.

HW not necessarily can offload this kernel based jhash function and 
therefore

we introduce the bpf option. With bpf the user can provide an implemenation

of a hash function that the HW can actually offload and that way user

maintains consistency between SW hash calculation and HW.

For example, in cases where offload is added dynamically as traffic 
flows, like

in the OVS case, first packets will go to SW and hash will be calculated 
on them

using bpf that emulates the HW hash so that this packet will get the 
same hash

result that it will later get in HW when the flow is offloaded.


If there's a strong objection to adding a new action,

IMO, we can include the bpf option in act_skbedit - action skbedit hash 
bpf <bpf.o>

What do u think?

Thanks,

Ariel


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ