mbox series

[bpf-next,0/3] AF_XDP clean up/perf improvements

Message ID 20210122105351.11751-1-bjorn.topel@gmail.com (mailing list archive)
Headers show
Series AF_XDP clean up/perf improvements | expand

Message

Björn Töpel Jan. 22, 2021, 10:53 a.m. UTC
This series has some clean up/performance improvements for XDP
sockets.

The first two patches are cleanups for the AF_XDP core, and the
restructure actually give a little performance boost.

The last patch adds support for selecting AF_XDP BPF program, based on
what the running kernel supports.

The patches were earlier part of the bigger "bpf_redirect_xsk()"
series [1]. I pulled out the non-controversial parts into this series.

Thanks to Maciej and Magnus for the internal review/comments!

Thanks to Toke, Alexei, and Andrii for the "auto-detection" help;
Instead of basing it on kernel version, a run-time test is
performed. Note that I did not add the probing support to libbpf.c,
where the other probes reside. Instead it's in xsk.c. The reason for
that is that AF_XDP will be moved out from libbpf post-1.0, to libxdp.


Thanks,
Björn

[1] https://lore.kernel.org/bpf/20210119155013.154808-1-bjorn.topel@gmail.com/

Björn Töpel (3):
  xsk: remove explicit_free parameter from __xsk_rcv()
  xsk: fold xp_assign_dev and __xp_assign_dev
  libbpf, xsk: select AF_XDP BPF program based on kernel version

 net/xdp/xsk.c           | 47 +++++++++++++++--------
 net/xdp/xsk_buff_pool.c | 12 ++----
 tools/lib/bpf/xsk.c     | 82 +++++++++++++++++++++++++++++++++++++++--
 3 files changed, 113 insertions(+), 28 deletions(-)


base-commit: 443edcefb8213155c0da22c4a999f4a49858fa39

Comments

Toke Høiland-Jørgensen Jan. 22, 2021, 1:19 p.m. UTC | #1
Björn Töpel <bjorn.topel@gmail.com> writes:

> This series has some clean up/performance improvements for XDP
> sockets.
>
> The first two patches are cleanups for the AF_XDP core, and the
> restructure actually give a little performance boost.
>
> The last patch adds support for selecting AF_XDP BPF program, based on
> what the running kernel supports.
>
> The patches were earlier part of the bigger "bpf_redirect_xsk()"
> series [1]. I pulled out the non-controversial parts into this series.

What about the first patch from that series, refactoring the existing
bpf_redirect_map() handling? I think that would be eligible for sending
on its own as well :)

-Toke
Björn Töpel Jan. 22, 2021, 1:37 p.m. UTC | #2
On 2021-01-22 14:19, Toke Høiland-Jørgensen wrote:
> Björn Töpel <bjorn.topel@gmail.com> writes:
> 
>> This series has some clean up/performance improvements for XDP
>> sockets.
>>
>> The first two patches are cleanups for the AF_XDP core, and the
>> restructure actually give a little performance boost.
>>
>> The last patch adds support for selecting AF_XDP BPF program, based on
>> what the running kernel supports.
>>
>> The patches were earlier part of the bigger "bpf_redirect_xsk()"
>> series [1]. I pulled out the non-controversial parts into this series.
> 
> What about the first patch from that series, refactoring the existing
> bpf_redirect_map() handling? I think that would be eligible for sending
> on its own as well :)
>

Yeah, I'm planning on doing that, but I figured I'd wait for Hangbin's
work to go first.


Björn


> -Toke
>
Toke Høiland-Jørgensen Jan. 22, 2021, 1:40 p.m. UTC | #3
Björn Töpel <bjorn.topel@intel.com> writes:

> On 2021-01-22 14:19, Toke Høiland-Jørgensen wrote:
>> Björn Töpel <bjorn.topel@gmail.com> writes:
>> 
>>> This series has some clean up/performance improvements for XDP
>>> sockets.
>>>
>>> The first two patches are cleanups for the AF_XDP core, and the
>>> restructure actually give a little performance boost.
>>>
>>> The last patch adds support for selecting AF_XDP BPF program, based on
>>> what the running kernel supports.
>>>
>>> The patches were earlier part of the bigger "bpf_redirect_xsk()"
>>> series [1]. I pulled out the non-controversial parts into this series.
>> 
>> What about the first patch from that series, refactoring the existing
>> bpf_redirect_map() handling? I think that would be eligible for sending
>> on its own as well :)
>>
>
> Yeah, I'm planning on doing that, but I figured I'd wait for Hangbin's
> work to go first.

Ah, right, good point; cool! :)

-Toke