Message ID | b3060caf-df19-f1df-6d27-4e58f894c417@sberdevices.ru |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp2088401wrn; Sun, 5 Feb 2023 22:59:42 -0800 (PST) X-Google-Smtp-Source: AK7set/RBpEk+2qRxmE3YGf59zO7nTfXaV3hdUNw/fVpsVsFz7ARACdTn+rlPXo0nFsVhwZYPlvC X-Received: by 2002:a17:90a:f292:b0:230:6bcc:3809 with SMTP id fs18-20020a17090af29200b002306bcc3809mr14231572pjb.0.1675666782128; Sun, 05 Feb 2023 22:59:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675666782; cv=none; d=google.com; s=arc-20160816; b=zcNEWIvpGAJ8lbUt2N0e3Evuomn2aby5LZyitsFH7a/nKKjmPG4rkv4d+wodb11UFp j8wMgTvVjOCqzkNBARFTv1QkfYuPRskOcoSdEjSu3hQjbI2bRDRo4uRhfoAIkjq9+uLC /nR8Jj8CcnjdnsaZNzab6lfDfB7M4FQdUrx99fVroBOe2IeBHyhDHtEgtsKKiFEBGtB6 8rfSIfVbFsVwKo1YdClgkOSa094TacSa+zKy7Dd2v+0+xmAxWFYk3pT5uwFN04wb8ukc sxfHj/5gy5hr5/W2pnWZ0A4xUwpZyMEM90DKoGyO6NM3gFwzhoqrctjAdMPcJSTxAS3h oMUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :content-id:content-language:accept-language:in-reply-to:message-id :date:thread-index:thread-topic:subject:cc:to:from:dkim-signature; bh=gM89Sds61a/Ke4wkFmjf14TzPo7acoM8k0Ezfh/OfTE=; b=j9oDlAjiPB13o58Y+JUQgj5YsvYSdOO5A9oG4pz5Gi8rBB69ijGL3Ac8XE1xPAD470 jsDeD48XCD6rYlb4TlwmAlfjjp9fvKcvvLiDDTKATfIW9OgJRs3MWQh6w0xHiPT7bwT0 Zn8AhELc4pSwyI9LvRTGiv0pNEpVpHjOUpIZ8WyQZWgvTCmZ7pFufNa6Rcayd840K4MA 930noxxbnAkMsQtYguGt73euqvb/A8VILQQsQKvefeFueO6fHF5XQ/T9Zg1yoN/Q0yCa oELU+kvQDMOXeM7o4+Jg5jYUUFjbrA//yf0+/UIDlQlU4mnmSj4XqR8DfxkAAY67o2XU j8ag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b="c6de/MpS"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=sberdevices.ru Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bt8-20020a17090af00800b0022c3263deedsi16397226pjb.75.2023.02.05.22.59.30; Sun, 05 Feb 2023 22:59:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b="c6de/MpS"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=sberdevices.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229490AbjBFG6y (ORCPT <rfc822;kmanaouilinux@gmail.com> + 99 others); Mon, 6 Feb 2023 01:58:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54330 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229733AbjBFG6w (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 6 Feb 2023 01:58:52 -0500 Received: from mx.sberdevices.ru (mx.sberdevices.ru [45.89.227.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 412CF193F7; Sun, 5 Feb 2023 22:58:26 -0800 (PST) Received: from s-lin-edge02.sberdevices.ru (localhost [127.0.0.1]) by mx.sberdevices.ru (Postfix) with ESMTP id 9C6BE5FD03; Mon, 6 Feb 2023 09:58:24 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sberdevices.ru; s=mail; t=1675666704; bh=gM89Sds61a/Ke4wkFmjf14TzPo7acoM8k0Ezfh/OfTE=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=c6de/MpSk/4xBtTgl+FzdDqL4UQ8O5WOgcgBI394fValuTI9p58AwowKSqDOZ/lXn QD9TyM4RcoP9LztoDZWlf7cdBMILvlcrQla9VlTO4SLx3WmmUGBPZBNTDJy6rT+kVB 3gvXKIeKzZYiyr3Dwr7FXUVthyCyugQnK8PP8VHd3IzPkaI4oaVdv/BtJ/nZusHnob NyyIO67bd2t0wrPJagdL8EuwKxYscc3iwc2Ag2i1zN5U56brTP7DoI4I9NmGpPSZdP Uryemcx0D+wdJq3E9LQH6QGAwheuKy+lLP08eXqQ8tucs4vQoxZ0StrIytrXrUOEpZ 9cQ86pcyNzbGg== Received: from S-MS-EXCH01.sberdevices.ru (S-MS-EXCH01.sberdevices.ru [172.16.1.4]) by mx.sberdevices.ru (Postfix) with ESMTP; Mon, 6 Feb 2023 09:58:24 +0300 (MSK) From: Arseniy Krasnov <AVKrasnov@sberdevices.ru> To: Stefan Hajnoczi <stefanha@redhat.com>, Stefano Garzarella <sgarzare@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, Jason Wang <jasowang@redhat.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Arseniy Krasnov <AVKrasnov@sberdevices.ru>, "Krasnov Arseniy" <oxffffaa@gmail.com> CC: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "virtualization@lists.linux-foundation.org" <virtualization@lists.linux-foundation.org>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, kernel <kernel@sberdevices.ru> Subject: [RFC PATCH v1 05/12] vsock/virtio: non-linear skb support Thread-Topic: [RFC PATCH v1 05/12] vsock/virtio: non-linear skb support Thread-Index: AQHZOfhn3a4rtLPBJ0ikS/zrL9u2kw== Date: Mon, 6 Feb 2023 06:58:24 +0000 Message-ID: <b3060caf-df19-f1df-6d27-4e58f894c417@sberdevices.ru> In-Reply-To: <0e7c6fc4-b4a6-a27b-36e9-359597bba2b5@sberdevices.ru> Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.1.12] Content-Type: text/plain; charset="utf-8" Content-ID: <4C7B0332DEEF004C81506DE1E7C21622@sberdevices.ru> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-KSMG-Rule-ID: 4 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiPhishing: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 1.1.2.30, bases: 2023/02/06 01:18:00 #20834045 X-KSMG-AntiVirus-Status: Clean, skipped X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757063971742216708?= X-GMAIL-MSGID: =?utf-8?q?1757063971742216708?= |
Series |
vsock: MSG_ZEROCOPY flag support
|
|
Commit Message
Arseniy Krasnov
Feb. 6, 2023, 6:58 a.m. UTC
Use pages of non-linear skb as buffers in virtio tx queue.
Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
---
net/vmw_vsock/virtio_transport.c | 31 +++++++++++++++++++++++++------
1 file changed, 25 insertions(+), 6 deletions(-)
--
2.25.1
Comments
On Mon, Feb 06, 2023 at 06:58:24AM +0000, Arseniy Krasnov wrote: >Use pages of non-linear skb as buffers in virtio tx queue. > >Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> >--- > net/vmw_vsock/virtio_transport.c | 31 +++++++++++++++++++++++++------ > 1 file changed, 25 insertions(+), 6 deletions(-) > >diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c >index 28b5a8e8e094..b8a7d6dc9f46 100644 >--- a/net/vmw_vsock/virtio_transport.c >+++ b/net/vmw_vsock/virtio_transport.c >@@ -100,7 +100,8 @@ virtio_transport_send_pkt_work(struct work_struct *work) > vq = vsock->vqs[VSOCK_VQ_TX]; > > for (;;) { >- struct scatterlist hdr, buf, *sgs[2]; >+ struct scatterlist *sgs[MAX_SKB_FRAGS + 1]; >+ struct scatterlist bufs[MAX_SKB_FRAGS + 1]; + 1 is for the header, right? I'd add a comment just to be clear ;-) > int ret, in_sg = 0, out_sg = 0; > struct sk_buff *skb; > bool reply; >@@ -111,12 +112,30 @@ virtio_transport_send_pkt_work(struct work_struct *work) > > virtio_transport_deliver_tap_pkt(skb); > reply = virtio_vsock_skb_reply(skb); >+ sg_init_one(&bufs[0], virtio_vsock_hdr(skb), sizeof(*virtio_vsock_hdr(skb))); >+ sgs[out_sg++] = &bufs[0]; >+ >+ if (skb_is_nonlinear(skb)) { >+ int i; >+ >+ for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) { >+ struct page *data_page = skb_shinfo(skb)->frags[i].bv_page; >+ >+ /* We will use 'page_to_virt()' for userspace page here, >+ * because virtio layer will call 'virt_to_phys()' later >+ * to fill buffer descriptor. We don't touch memory at >+ * "virtual" address of this page. >+ */ IIUC data_page is a user page, so since we are exposing it to the host, I think we should pin it. Is data_page always a user page, or can it be a kernel page when skb is nonlinear? Thanks, Stefano >+ sg_init_one(&bufs[i + 1], >+ page_to_virt(data_page), PAGE_SIZE); >+ sgs[out_sg++] = &bufs[i + 1]; >+ } >+ } else { >+ if (skb->len > 0) { >+ sg_init_one(&bufs[1], skb->data, skb->len); >+ sgs[out_sg++] = &bufs[1]; >+ } > >- sg_init_one(&hdr, virtio_vsock_hdr(skb), sizeof(*virtio_vsock_hdr(skb))); >- sgs[out_sg++] = &hdr; >- if (skb->len > 0) { >- sg_init_one(&buf, skb->data, skb->len); >- sgs[out_sg++] = &buf; > } > > ret = virtqueue_add_sgs(vq, sgs, out_sg, in_sg, skb, GFP_KERNEL); >-- >2.25.1
On 16.02.2023 17:18, Stefano Garzarella wrote: > On Mon, Feb 06, 2023 at 06:58:24AM +0000, Arseniy Krasnov wrote: >> Use pages of non-linear skb as buffers in virtio tx queue. >> >> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> >> --- >> net/vmw_vsock/virtio_transport.c | 31 +++++++++++++++++++++++++------ >> 1 file changed, 25 insertions(+), 6 deletions(-) >> >> diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c >> index 28b5a8e8e094..b8a7d6dc9f46 100644 >> --- a/net/vmw_vsock/virtio_transport.c >> +++ b/net/vmw_vsock/virtio_transport.c >> @@ -100,7 +100,8 @@ virtio_transport_send_pkt_work(struct work_struct *work) >> vq = vsock->vqs[VSOCK_VQ_TX]; >> >> for (;;) { >> - struct scatterlist hdr, buf, *sgs[2]; >> + struct scatterlist *sgs[MAX_SKB_FRAGS + 1]; >> + struct scatterlist bufs[MAX_SKB_FRAGS + 1]; > > + 1 is for the header, right? > I'd add a comment just to be clear ;-) > >> int ret, in_sg = 0, out_sg = 0; >> struct sk_buff *skb; >> bool reply; >> @@ -111,12 +112,30 @@ virtio_transport_send_pkt_work(struct work_struct *work) >> >> virtio_transport_deliver_tap_pkt(skb); >> reply = virtio_vsock_skb_reply(skb); >> + sg_init_one(&bufs[0], virtio_vsock_hdr(skb), sizeof(*virtio_vsock_hdr(skb))); >> + sgs[out_sg++] = &bufs[0]; >> + >> + if (skb_is_nonlinear(skb)) { >> + int i; >> + >> + for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) { >> + struct page *data_page = skb_shinfo(skb)->frags[i].bv_page; >> + >> + /* We will use 'page_to_virt()' for userspace page here, >> + * because virtio layer will call 'virt_to_phys()' later >> + * to fill buffer descriptor. We don't touch memory at >> + * "virtual" address of this page. >> + */ > > IIUC data_page is a user page, so since we are exposing it to the host, > I think we should pin it. > > Is data_page always a user page, or can it be a kernel page when skb is nonlinear? By default it is user page, but...may be it is possible to send page of mapped file with MAP_SHARED flags(i think it this case it will be page from page cache) > > Thanks, > Stefano > >> + sg_init_one(&bufs[i + 1], >> + page_to_virt(data_page), PAGE_SIZE); >> + sgs[out_sg++] = &bufs[i + 1]; >> + } >> + } else { >> + if (skb->len > 0) { >> + sg_init_one(&bufs[1], skb->data, skb->len); >> + sgs[out_sg++] = &bufs[1]; >> + } >> >> - sg_init_one(&hdr, virtio_vsock_hdr(skb), sizeof(*virtio_vsock_hdr(skb))); >> - sgs[out_sg++] = &hdr; >> - if (skb->len > 0) { >> - sg_init_one(&buf, skb->data, skb->len); >> - sgs[out_sg++] = &buf; >> } >> >> ret = virtqueue_add_sgs(vq, sgs, out_sg, in_sg, skb, GFP_KERNEL); >> -- >> 2.25.1 >
diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c index 28b5a8e8e094..b8a7d6dc9f46 100644 --- a/net/vmw_vsock/virtio_transport.c +++ b/net/vmw_vsock/virtio_transport.c @@ -100,7 +100,8 @@ virtio_transport_send_pkt_work(struct work_struct *work) vq = vsock->vqs[VSOCK_VQ_TX]; for (;;) { - struct scatterlist hdr, buf, *sgs[2]; + struct scatterlist *sgs[MAX_SKB_FRAGS + 1]; + struct scatterlist bufs[MAX_SKB_FRAGS + 1]; int ret, in_sg = 0, out_sg = 0; struct sk_buff *skb; bool reply; @@ -111,12 +112,30 @@ virtio_transport_send_pkt_work(struct work_struct *work) virtio_transport_deliver_tap_pkt(skb); reply = virtio_vsock_skb_reply(skb); + sg_init_one(&bufs[0], virtio_vsock_hdr(skb), sizeof(*virtio_vsock_hdr(skb))); + sgs[out_sg++] = &bufs[0]; + + if (skb_is_nonlinear(skb)) { + int i; + + for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) { + struct page *data_page = skb_shinfo(skb)->frags[i].bv_page; + + /* We will use 'page_to_virt()' for userspace page here, + * because virtio layer will call 'virt_to_phys()' later + * to fill buffer descriptor. We don't touch memory at + * "virtual" address of this page. + */ + sg_init_one(&bufs[i + 1], + page_to_virt(data_page), PAGE_SIZE); + sgs[out_sg++] = &bufs[i + 1]; + } + } else { + if (skb->len > 0) { + sg_init_one(&bufs[1], skb->data, skb->len); + sgs[out_sg++] = &bufs[1]; + } - sg_init_one(&hdr, virtio_vsock_hdr(skb), sizeof(*virtio_vsock_hdr(skb))); - sgs[out_sg++] = &hdr; - if (skb->len > 0) { - sg_init_one(&buf, skb->data, skb->len); - sgs[out_sg++] = &buf; } ret = virtqueue_add_sgs(vq, sgs, out_sg, in_sg, skb, GFP_KERNEL);