[ovs-dev] [PATCH v3 1/4] netdev-afxdp: Enable loading XDP program.

William Tu u9012063 at gmail.com
Thu Jul 16 00:51:33 UTC 2020


On Mon, Jun 29, 2020 at 8:30 AM Toshiaki Makita
<toshiaki.makita1 at gmail.com> wrote:
>
> From: William Tu <u9012063 at gmail.com>
>
> Now netdev-afxdp always forwards all packets to userspace because
> it is using libbpf's default XDP program, see 'xsk_load_xdp_prog'.
> There are some cases when users want to keep packets in kernel instead
> of sending to userspace, for example, management traffic such as SSH
> should be processed in kernel.
>
> The patch enables loading the user-provided XDP program by
>   $ovs-vsctl -- set int afxdp-p0 options:xdp-obj=<path/to/xdp/obj>
>
> So users can implement their filtering logic or traffic steering idea
> in their XDP program, and rest of the traffic passes to AF_XDP socket
> handled by OVS.
>
> Note: kernel in AF_XDP CI test is updated to 5.5 because libbpf from 5.3
> does not have newly used APIs like "bpf_program__get_type".
>
> Signed-off-by: William Tu <u9012063 at gmail.com>
> Co-Authored-by: Toshiaki Makita <toshiaki.makita1 at gmail.com>
> Signed-off-by: Toshiaki Makita <toshiaki.makita1 at gmail.com>
> ---
>  .travis.yml                           |   2 +-
>  Documentation/intro/install/afxdp.rst |  59 ++++++++++
>  NEWS                                  |   2 +
>  lib/netdev-afxdp.c                    | 154 ++++++++++++++++++++++++--
>  lib/netdev-linux-private.h            |   3 +
>  5 files changed, 212 insertions(+), 8 deletions(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index 527240a67..26b55a3e6 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -40,7 +40,7 @@ env:
>    - TESTSUITE=1 LIBS=-ljemalloc
>    - KERNEL_LIST="5.5  4.20 4.19 4.18 4.17 4.16"
>    - KERNEL_LIST="4.15 4.14 4.9  4.4  3.19 3.16"
> -  - AFXDP=1 KERNEL=5.3
> +  - AFXDP=1 KERNEL=5.5
>    - M32=1 OPTS="--disable-ssl"
>    - DPDK=1 OPTS="--enable-shared"
>    - DPDK_SHARED=1
> diff --git a/Documentation/intro/install/afxdp.rst b/Documentation/intro/install/afxdp.rst
> index 3c8f78825..2cd02477f 100644
> --- a/Documentation/intro/install/afxdp.rst
> +++ b/Documentation/intro/install/afxdp.rst
> @@ -300,6 +300,65 @@ Or, use OVS pmd tool::
>    ovs-appctl dpif-netdev/pmd-stats-show
>
>
> +Loading Custom XDP Program
> +--------------------------
> +By defailt, netdev-afxdp always forwards all packets to userspace because
> +it is using libbpf's default XDP program. There are some cases when users
> +want to keep packets in kernel instead of sending to userspace, for example,
> +management traffic such as SSH should be processed in kernel. This can be
> +done by loading the user-provided XDP program::
> +
> +  ovs-vsctl -- set int afxdp-p0 options:xdp-obj=<path/to/xdp/obj>

I tested this patch with an invalid xdp obj file (a valid xdp program,
but in that program
there is no xsk_map) and it triggers OVS to keep re-adding the port
again and again.
The reason is described here

commit 37a24655234459e1e2082d2595bffaab0c837678
Author: Ilya Maximets <i.maximets at ovn.org>
Date:   Sat Dec 7 15:46:17 2019 +0100

    netdev-afxdp: Avoid removing of XDP program if not loaded.

    'bpf_set_link_xdp_fd' generates netlink event regardless of actual
    changes it does, so if-notifier will receive link update even if
    there was no XDP program previously loaded on the interface.

    OVS tries to remove XDP program if device configuration was not
    successful triggering if-notifier that triggers bridge reconfiguration
    and another attempt to add failed port.  And so on in the infinite
    loop.

    This patch avoids the issue by not removing XDP program if it wasn't
    loaded.  Since loading of the XDP program is one of the last steps
    of port configuration, this should help to avoid infinite re-addition
    for most types of misconfiguration.

And the patch above does not solve our problem because we already
loaded the invalid XDP program. So we have to unload it, which triggers
the if-notifier message to reconfigure the bridge.
So far I don't have any good solutions.

Regards,
William


More information about the dev mailing list