netdev - Re: [RFC PATCH bpf-next] bpf, xdp: per-map bpf_redirect

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:   Mon, 1 Feb 2021 07:27:57 +0100
From:   Björn Töpel <bjorn.topel@...el.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>,
        Björn Töpel <bjorn.topel@...il.com>,
        ast@...nel.org, daniel@...earbox.net, netdev@...r.kernel.org,
        bpf@...r.kernel.org
Cc:     magnus.karlsson@...el.com, maciej.fijalkowski@...el.com,
        kuba@...nel.org, jonathan.lemon@...il.com, maximmi@...dia.com,
        davem@...emloft.net, hawk@...nel.org, john.fastabend@...il.com
Subject: Re: [RFC PATCH bpf-next] bpf, xdp: per-map bpf_redirect_map functions
 for XDP

On 2021-01-29 17:45, Toke Høiland-Jørgensen wrote:
> Björn Töpel <bjorn.topel@...il.com> writes:
> 
>> From: Björn Töpel <bjorn.topel@...el.com>
>>
>> Currently the bpf_redirect_map() implementation dispatches to the
>> correct map-lookup function via a switch-statement. To avoid the
>> dispatching, this change adds one bpf_redirect_map() implementation per
>> map. Correct function is automatically selected by the BPF verifier.
>>
>> Signed-off-by: Björn Töpel <bjorn.topel@...el.com>
>> ---
>> Hi XDP-folks!
>>
>> This is another take on my bpf_redirect_xsk() patch [1]. I figured I
>> send it as an RFC for some early input. My plan is to include it as
>> part of the xdp_do_redirect() optimization of [1].
> 
> Assuming the maintainers are OK with the special-casing in the verifier,
> this looks like a neat way to avoid the runtime overhead to me. The
> macro hackery is not the prettiest; I wonder if the same effect could be
> achieved by using inline functions? If not, at least a comment
> explaining the reasoning (and that the verifier will substitute the
> right function) might be nice? Mostly in relation to this bit:
>

Yeah, I agree with the macro part. I'll replace it with a
__always_inline function, instead.


>>   static const struct bpf_func_proto bpf_xdp_redirect_map_proto = {
>> -	.func           = bpf_xdp_redirect_map,
>> +	.func           = bpf_xdp_redirect_devmap,
>

I'll try to clean this up as well.

Thanks for taking a look!
Björn


> Ah, if only we were writing the kernel in a language with proper macro
> support... One can dream! :)
> 
>>> For AF_XDP rxdrop this yields +600Mpps. I'll do CPU/DEVMAP
>>> measurements for the patch proper.
>>>
>>
>> Kpps, not Mpps. :-P
> 
> Aww, too bad ;)
> Still, nice!
> 
> -Toke
>