Message-ID: <CALx6S37d=JYSSjCfWa_N=AK3HUMSR9TJEv46tLTK-LiMrzoWMg@mail.gmail.com>
Date:   Thu, 26 Dec 2019 11:23:24 -0800
From:   Tom Herbert <tom@...bertland.com>
To:     Prashant Bhole <prashantbhole.linux@...il.com>
Cc:     "David S . Miller" <davem@...emloft.net>,
        "Michael S . Tsirkin" <mst@...hat.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        Jason Wang <jasowang@...hat.com>,
        David Ahern <dsahern@...il.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        John Fastabend <john.fastabend@...il.com>,
        Toshiaki Makita <toshiaki.makita1@...il.com>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [RFC v2 net-next 00/12] XDP in tx path

Prashant,

Can you provide some more detail about the expected use cases. I am
particularly interested if the intent is to set an XDP-like eBPF hook
in the generic TX path (the examples provided seem limited to
tunnels). For instance, is there an intent to send packets on a device
without ever creating a skbuf as the analogue of how XDP can receive
packets without needing skb.

Tom

On Wed, Dec 25, 2019 at 6:33 PM Prashant Bhole
<prashantbhole.linux@...il.com> wrote:
>
> v2:
> - New XDP attachment type: Jesper, Toke and Alexei discussed whether
>   to introduce a new program type. Since this set adds a way to attach
>   regular XDP program to the tx path, as per Alexei's suggestion, a
>   new attachment type BPF_XDP_EGRESS is introduced.
>
> - libbpf API changes:
>   Alexei had suggested _opts() style of API extension. Considering it
>   two new libbpf APIs are introduced which are equivalent to existing
>   APIs. New ones can be extended easily. Please see individual patches
>   for details. xdp1 sample program is modified to use new APIs.
>
> - tun: Some patches from previous set are removed as they are
>   irrelevant in this series. They will in introduced later.
>
>
> This series introduces new XDP attachment type BPF_XDP_EGRESS to run
> an XDP program in tx path. The idea is to emulate RX path XDP of the
> peer interface. Such program will not have access to rxq info.
>
> RFC also includes its usage in tun driver.
> Later it can be posted separately. Another possible use of this
> feature can be in veth driver. It can improve container networking
> where veth pair links the host and the container. Host can set ACL by
> setting tx path XDP to the veth interface.
>
> It was originally a part of Jason Wang's work "XDP offload with
> virtio-net" [1]. In order to simplify this work we decided to split
> it and introduce tx path XDP separately in this set.
>
> The performance improvment can be seen when an XDP program is attached
> to tun tx path opposed to rx path in the guest.
>
> * Case 1: When packets are XDP_REDIRECT'ed towards tun.
>
>                      virtio-net rx XDP      tun tx XDP
>   xdp1(XDP_DROP)        2.57 Mpps           12.90 Mpps
>   xdp2(XDP_TX)          1.53 Mpps            7.15 Mpps
>
> * Case 2: When packets are pass through bridge towards tun
>
>                      virtio-net rx XDP      tun tx XDP
>   xdp1(XDP_DROP)        0.99 Mpps           1.00 Mpps
>   xdp2(XDP_TX)          1.19 Mpps           0.97 Mpps
>
> Since this set modifies tun and vhost_net, below are the netperf
> performance numbers.
>
>     Netperf_test       Before      After   Difference
>   UDP_STREAM 18byte     90.14       88.77    -1.51%
>   UDP_STREAM 1472byte   6955        6658     -4.27%
>   TCP STREAM            9409        9402     -0.07%
>   UDP_RR                12658       13030    +2.93%
>   TCP_RR                12711       12831    +0.94%
>
> XDP_REDIRECT will be handled later because we need to come up with
> proper way to handle it in tx path.
>
> Patches 1-5 are related to adding tx path XDP support.
> Patches 6-12 implement tx path XDP in tun driver.
>
> [1]: https://netdevconf.info/0x13/session.html?xdp-offload-with-virtio-net
>
>
>
> David Ahern (2):
>   net: introduce BPF_XDP_EGRESS attach type for XDP
>   tun: set tx path XDP program
>
> Jason Wang (2):
>   net: core: rename netif_receive_generic_xdp() to do_generic_xdp_core()
>   net: core: export do_xdp_generic_core()
>
> Prashant Bhole (8):
>   tools: sync kernel uapi/linux/if_link.h header
>   libbpf: api for getting/setting link xdp options
>   libbpf: set xdp program in tx path
>   samples/bpf: xdp1, add XDP tx support
>   tuntap: check tun_msg_ctl type at necessary places
>   vhost_net: user tap recvmsg api to access ptr ring
>   tuntap: remove usage of ptr ring in vhost_net
>   tun: run XDP program in tx path
>
>  drivers/net/tap.c                  |  42 +++---
>  drivers/net/tun.c                  | 220 ++++++++++++++++++++++++++---
>  drivers/vhost/net.c                |  77 +++++-----
>  include/linux/if_tap.h             |   5 -
>  include/linux/if_tun.h             |  23 ++-
>  include/linux/netdevice.h          |   6 +-
>  include/uapi/linux/bpf.h           |   1 +
>  include/uapi/linux/if_link.h       |   1 +
>  net/core/dev.c                     |  42 ++++--
>  net/core/filter.c                  |   8 ++
>  net/core/rtnetlink.c               | 112 ++++++++++++++-
>  samples/bpf/xdp1_user.c            |  42 ++++--
>  tools/include/uapi/linux/bpf.h     |   1 +
>  tools/include/uapi/linux/if_link.h |   2 +
>  tools/lib/bpf/libbpf.h             |  40 ++++++
>  tools/lib/bpf/libbpf.map           |   2 +
>  tools/lib/bpf/netlink.c            | 113 +++++++++++++--
>  17 files changed, 613 insertions(+), 124 deletions(-)
>
> --
> 2.21.0
>

Powered by blists - more mailing lists