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 PHC | |
Open Source and information security mailing list archives
| ||
|
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