# Re: \[RFC PATCH bpf-next\] bpf, xdp: per-map bpf\_redirect\_map functions for XDP

- From: Björn Töpel \<hidden\>
- Date: 2021-02-01 06:36:22 
- List: netdev
- Page: https://ratatoskr.run/netdev/2021/02/7759313
- Thread: https://ratatoskr.run/netdev/2021/01/7759278/t.md

```text
On 2021-01-29 17:45, Toke Høiland-Jørgensen wrote:
> Björn Töpel [ref] writes:
>
>> From: Björn Töpel <redacted>
>>
>> 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 <redacted>
>> ---
>> 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
>
```