From: Alexander Lobakin <alobakin@pm.me>
To: Yunsheng Lin <linyunsheng@huawei.com>
Cc: Alexander Lobakin <alobakin@pm.me>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jason Wang <jasowang@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
bjorn.topel@intel.com,
Magnus Karlsson <magnus.karlsson@intel.com>,
Jonathan Lemon <jonathan.lemon@gmail.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <hawk@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>, KP Singh <kpsingh@kernel.org>,
Willem de Bruijn <willemb@google.com>,
Steffen Klassert <steffen.klassert@secunet.com>,
Miaohe Lin <linmiaohe@huawei.com>,
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
Antoine Tenart <atenart@kernel.org>,
Michal Kubecek <mkubecek@suse.cz>, Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Meir Lichtinger <meirl@mellanox.com>,
virtualization@lists.linux-foundation.org, bpf@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next] xsk: build skb by page
Date: Mon, 18 Jan 2021 13:00:17 +0000 [thread overview]
Message-ID: <20210118125937.4088-1-alobakin@pm.me> (raw)
In-Reply-To: <4a4b475b-0e79-6cf6-44f5-44d45b5d85b5@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
Date: Mon, 18 Jan 2021 20:40:52 +0800
> On 2021/1/16 10:44, Xuan Zhuo wrote:
>> This patch is used to construct skb based on page to save memory copy
>> overhead.
>>
>> This has one problem:
>>
>> We construct the skb by fill the data page as a frag into the skb. In
>> this way, the linear space is empty, and the header information is also
>> in the frag, not in the linear space, which is not allowed for some
>> network cards. For example, Mellanox Technologies MT27710 Family
>> [ConnectX-4 Lx] will get the following error message:
>>
>> mlx5_core 0000:3b:00.1 eth1: Error cqe on cqn 0x817, ci 0x8, qn 0x1dbb, opcode 0xd, syndrome 0x1, vendor syndrome 0x68
>> 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 00000030: 00 00 00 00 60 10 68 01 0a 00 1d bb 00 0f 9f d2
>> WQE DUMP: WQ size 1024 WQ cur size 0, WQE index 0xf, len: 64
>> 00000000: 00 00 0f 0a 00 1d bb 03 00 00 00 08 00 00 00 00
>> 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 00000020: 00 00 00 2b 00 08 00 00 00 00 00 05 9e e3 08 00
>> 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> mlx5_core 0000:3b:00.1 eth1: ERR CQE on SQ: 0x1dbb
>>
>> I also tried to use build_skb to construct skb, but because of the
>> existence of skb_shinfo, it must be behind the linear space, so this
>> method is not working. We can't put skb_shinfo on desc->addr, it will be
>> exposed to users, this is not safe.
>>
>> Finally, I added a feature NETIF_F_SKB_NO_LINEAR to identify whether the
>
> Does it make sense to use ETHTOOL_TX_COPYBREAK tunable in ethtool to
> configure if the data is copied or not?
As far as I can grep, only mlx4 supports this, and it has a different
meaning in that driver.
So I guess a new netdev_feature would be a better solution.
>> network card supports the header information of the packet in the frag
>> and not in the linear space.
>>
>> ---------------- Performance Testing ------------
>>
>> The test environment is Aliyun ECS server.
>> Test cmd:
>> ```
>> xdpsock -i eth0 -t -S -s <msg size>
>> ```
>>
>> Test result data:
>>
>> size 64 512 1024 1500
>> copy 1916747 1775988 1600203 1440054
>> page 1974058 1953655 1945463 1904478
>> percent 3.0% 10.0% 21.58% 32.3%
>>
>> Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
>> Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
>> ---
>> drivers/net/virtio_net.c | 2 +-
>> include/linux/netdev_features.h | 5 +-
>> net/ethtool/common.c | 1 +
>> net/xdp/xsk.c | 108 +++++++++++++++++++++++++++++++++-------
>> 4 files changed, 97 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index 4ecccb8..841a331 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -2985,7 +2985,7 @@ static int virtnet_probe(struct virtio_device *vdev)
>> /* Set up network device as normal. */
>> dev->priv_flags |= IFF_UNICAST_FLT | IFF_LIVE_ADDR_CHANGE;
>> dev->netdev_ops = &virtnet_netdev;
>> - dev->features = NETIF_F_HIGHDMA;
>> + dev->features = NETIF_F_HIGHDMA | NETIF_F_SKB_NO_LINEAR;
>>
>> dev->ethtool_ops = &virtnet_ethtool_ops;
>> SET_NETDEV_DEV(dev, &vdev->dev);
>> diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
>> index 934de56..8dd28e2 100644
>> --- a/include/linux/netdev_features.h
>> +++ b/include/linux/netdev_features.h
>> @@ -85,9 +85,11 @@ enum {
>>
>> NETIF_F_HW_MACSEC_BIT, /* Offload MACsec operations */
>>
>> + NETIF_F_SKB_NO_LINEAR_BIT, /* Allow skb linear is empty */
>> +
>> /*
>> * Add your fresh new feature above and remember to update
>> - * netdev_features_strings[] in net/core/ethtool.c and maybe
>> + * netdev_features_strings[] in net/ethtool/common.c and maybe
>> * some feature mask #defines below. Please also describe it
>> * in Documentation/networking/netdev-features.rst.
>> */
>> @@ -157,6 +159,7 @@ enum {
>> #define NETIF_F_GRO_FRAGLIST __NETIF_F(GRO_FRAGLIST)
>> #define NETIF_F_GSO_FRAGLIST __NETIF_F(GSO_FRAGLIST)
>> #define NETIF_F_HW_MACSEC __NETIF_F(HW_MACSEC)
>> +#define NETIF_F_SKB_NO_LINEAR __NETIF_F(SKB_NO_LINEAR)
>>
>> /* Finds the next feature with the highest number of the range of start till 0.
>> */
>> diff --git a/net/ethtool/common.c b/net/ethtool/common.c
>> index 24036e3..2f3d309 100644
>> --- a/net/ethtool/common.c
>> +++ b/net/ethtool/common.c
>> @@ -68,6 +68,7 @@
>> [NETIF_F_HW_TLS_RX_BIT] = "tls-hw-rx-offload",
>> [NETIF_F_GRO_FRAGLIST_BIT] = "rx-gro-list",
>> [NETIF_F_HW_MACSEC_BIT] = "macsec-hw-offload",
>> + [NETIF_F_SKB_NO_LINEAR_BIT] = "skb-no-linear",
I completely forgot to add that you'd better to mention in both
enumeration/feature and its Ethtool string that the feature applies
to Tx path.
Smth like:
NETIF_F_SKB_TX_NO_LINEAR{,_BIT}, "skb-tx-no-linear"
or
NETIF_F_TX_SKB_NO_LINEAR{,_BIT}, "tx-skb-no-linear"
Otherwise, it may be confusing for users and developers.
>> };
>>
>> const char
>> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
>> index 8037b04..94d17dc 100644
>> --- a/net/xdp/xsk.c
>> +++ b/net/xdp/xsk.c
>> @@ -430,6 +430,95 @@ static void xsk_destruct_skb(struct sk_buff *skb)
>> sock_wfree(skb);
>> }
>>
>> +static struct sk_buff *xsk_build_skb_zerocopy(struct xdp_sock *xs,
>> + struct xdp_desc *desc)
>> +{
>> + u32 len, offset, copy, copied;
>> + struct sk_buff *skb;
>> + struct page *page;
>> + char *buffer;
>> + int err, i;
>> + u64 addr;
>> +
>> + skb = sock_alloc_send_skb(&xs->sk, 0, 1, &err);
>> + if (unlikely(!skb))
>> + return NULL;
>> +
>> + addr = desc->addr;
>> + len = desc->len;
>> +
>> + buffer = xsk_buff_raw_get_data(xs->pool, addr);
>> + offset = offset_in_page(buffer);
>> + addr = buffer - (char *)xs->pool->addrs;
>> +
>> + for (copied = 0, i = 0; copied < len; ++i) {
>> + page = xs->pool->umem->pgs[addr >> PAGE_SHIFT];
>> +
>> + get_page(page);
>> +
>> + copy = min((u32)(PAGE_SIZE - offset), len - copied);
>> +
>> + skb_fill_page_desc(skb, i, page, offset, copy);
>> +
>> + copied += copy;
>> + addr += copy;
>> + offset = 0;
>> + }
>> +
>> + skb->len += len;
>> + skb->data_len += len;
>> + skb->truesize += len;
>> +
>> + refcount_add(len, &xs->sk.sk_wmem_alloc);
>> +
>> + return skb;
>> +}
>> +
>> +static struct sk_buff *xsk_build_skb(struct xdp_sock *xs,
>> + struct xdp_desc *desc, int *err)
>> +{
>> + struct sk_buff *skb;
>> +
>> + if (xs->dev->features & NETIF_F_SKB_NO_LINEAR) {
>> + skb = xsk_build_skb_zerocopy(xs, desc);
>> + if (unlikely(!skb)) {
>> + *err = -ENOMEM;
>> + return NULL;
>> + }
>> + } else {
>> + char *buffer;
>> + u64 addr;
>> + u32 len;
>> + int err;
>> +
>> + len = desc->len;
>> + skb = sock_alloc_send_skb(&xs->sk, len, 1, &err);
>> + if (unlikely(!skb)) {
>> + *err = -ENOMEM;
>> + return NULL;
>> + }
>> +
>> + skb_put(skb, len);
>> + addr = desc->addr;
>> + buffer = xsk_buff_raw_get_data(xs->pool, desc->addr);
>> + err = skb_store_bits(skb, 0, buffer, len);
>> +
>> + if (unlikely(err)) {
>> + kfree_skb(skb);
>> + *err = -EINVAL;
>> + return NULL;
>> + }
>> + }
>> +
>> + skb->dev = xs->dev;
>> + skb->priority = xs->sk.sk_priority;
>> + skb->mark = xs->sk.sk_mark;
>> + skb_shinfo(skb)->destructor_arg = (void *)(long)desc->addr;
>> + skb->destructor = xsk_destruct_skb;
>> +
>> + return skb;
>> +}
>> +
>> static int xsk_generic_xmit(struct sock *sk)
>> {
>> struct xdp_sock *xs = xdp_sk(sk);
>> @@ -446,43 +535,28 @@ static int xsk_generic_xmit(struct sock *sk)
>> goto out;
>>
>> while (xskq_cons_peek_desc(xs->tx, &desc, xs->pool)) {
>> - char *buffer;
>> - u64 addr;
>> - u32 len;
>> -
>> if (max_batch-- == 0) {
>> err = -EAGAIN;
>> goto out;
>> }
>>
>> - len = desc.len;
>> - skb = sock_alloc_send_skb(sk, len, 1, &err);
>> + skb = xsk_build_skb(xs, &desc, &err);
>> if (unlikely(!skb))
>> goto out;
>>
>> - skb_put(skb, len);
>> - addr = desc.addr;
>> - buffer = xsk_buff_raw_get_data(xs->pool, addr);
>> - err = skb_store_bits(skb, 0, buffer, len);
>> /* This is the backpressure mechanism for the Tx path.
>> * Reserve space in the completion queue and only proceed
>> * if there is space in it. This avoids having to implement
>> * any buffering in the Tx path.
>> */
>> spin_lock_irqsave(&xs->pool->cq_lock, flags);
>> - if (unlikely(err) || xskq_prod_reserve(xs->pool->cq)) {
>> + if (xskq_prod_reserve(xs->pool->cq)) {
>> spin_unlock_irqrestore(&xs->pool->cq_lock, flags);
>> kfree_skb(skb);
>> goto out;
>> }
>> spin_unlock_irqrestore(&xs->pool->cq_lock, flags);
>>
>> - skb->dev = xs->dev;
>> - skb->priority = sk->sk_priority;
>> - skb->mark = sk->sk_mark;
>> - skb_shinfo(skb)->destructor_arg = (void *)(long)desc.addr;
>> - skb->destructor = xsk_destruct_skb;
>> -
>> err = __dev_direct_xmit(skb, xs->queue_id);
>> if (err == NETDEV_TX_BUSY) {
>> /* Tell user-space to retry the send */
>>
Al
next prev parent reply other threads:[~2021-01-18 13:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <579fa463bba42ac71591540a1811dca41d725350.1610764948.git.xuanzhuo@linux.alibaba.com>
2021-01-18 12:37 ` [PATCH bpf-next] xsk: build skb by page Alexander Lobakin
[not found] ` <4a4b475b-0e79-6cf6-44f5-44d45b5d85b5@huawei.com>
2021-01-18 13:00 ` Alexander Lobakin [this message]
2021-01-18 14:40 ` Alexander Lobakin
2021-01-18 15:03 ` Magnus Karlsson
2021-01-18 15:10 ` Magnus Karlsson
2021-01-18 16:38 ` Alexander Lobakin
2021-01-19 7:01 ` Magnus Karlsson
2021-01-19 12:44 ` Alexander Lobakin
2020-12-23 8:56 Xuan Zhuo
2020-12-23 10:04 ` Magnus Karlsson
2020-12-29 8:32 ` Xuan Zhuo
2020-12-31 16:29 ` John Fastabend
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210118125937.4088-1-alobakin@pm.me \
--to=alobakin@pm.me \
--cc=andrew@lunn.ch \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=atenart@kernel.org \
--cc=bjorn.topel@intel.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=hawk@kernel.org \
--cc=jasowang@redhat.com \
--cc=john.fastabend@gmail.com \
--cc=jonathan.lemon@gmail.com \
--cc=kafai@fb.com \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linyunsheng@huawei.com \
--cc=magnus.karlsson@intel.com \
--cc=mchehab+huawei@kernel.org \
--cc=meirl@mellanox.com \
--cc=mkubecek@suse.cz \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=songliubraving@fb.com \
--cc=steffen.klassert@secunet.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=willemb@google.com \
--cc=xuanzhuo@linux.alibaba.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).