| 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 linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 27 Dec 2019 10:35:38 +0900
From: Prashant Bhole <prashantbhole.linux@...il.com>
To: Tom Herbert <tom@...bertland.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
On 12/27/19 4:23 AM, Tom Herbert wrote:
> 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.
This patchset is a result of trying to solve problems in virtual
devices. It just emulates RX path XDP of peer device. At least I have
not thought about the idea that you mentioned. May be this idea can be
helpful when a separate XDP_TX type of program which will introduced
later.
Toke had pointed out one more use case of TX path XDP here:
https://github.com/xdp-project/xdp-project/blob/master/xdp-project.org#xdp-hook-at-tx
Thanks
>
> 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