All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
To: Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	Stefano Garzarella <sgarzare@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	"edumazet@google.com" <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	"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: Re: [RFC PATCH v3 01/11] virtio/vsock: rework packet allocation logic
Date: Mon, 7 Nov 2022 21:31:20 +0000	[thread overview]
Message-ID: <76b4ee49-e3b0-34be-6b81-f58bc2bc3dcc@sberdevices.ru> (raw)
In-Reply-To: <6a0adc0d-da54-9c9b-3596-3422353e285d@wanadoo.fr>

On 08.11.2022 00:24, Christophe JAILLET wrote:
> Le 07/11/2022 à 06:23, Arseniy Krasnov a écrit :
>> On 06.11.2022 22:50, Christophe JAILLET wrote:
>>> Le 06/11/2022 à 20:36, Arseniy Krasnov a écrit :
>>>> To support zerocopy receive, packet's buffer allocation is changed: for
>>>> buffers which could be mapped to user's vma we can't use 'kmalloc()'(as
>>>> kernel restricts to map slab pages to user's vma) and raw buddy
>>>> allocator now called. But, for tx packets(such packets won't be mapped
>>>> to user), previous 'kmalloc()' way is used, but with special flag in
>>>> packet's structure which allows to distinguish between 'kmalloc()' and
>>>> raw pages buffers.
>>>>
>>>> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
>>>> ---
>>>>    drivers/vhost/vsock.c                   |  1 +
>>>>    include/linux/virtio_vsock.h            |  1 +
>>>>    net/vmw_vsock/virtio_transport.c        |  8 ++++++--
>>>>    net/vmw_vsock/virtio_transport_common.c | 10 +++++++++-
>>>>    4 files changed, 17 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
>>>> index 5703775af129..65475d128a1d 100644
>>>> --- a/drivers/vhost/vsock.c
>>>> +++ b/drivers/vhost/vsock.c
>>>> @@ -399,6 +399,7 @@ vhost_vsock_alloc_pkt(struct vhost_virtqueue *vq,
>>>>            return NULL;
>>>>        }
>>>>    +    pkt->slab_buf = true;
>>>>        pkt->buf_len = pkt->len;
>>>>          nbytes = copy_from_iter(pkt->buf, pkt->len, &iov_iter);
>>>> diff --git a/include/linux/virtio_vsock.h b/include/linux/virtio_vsock.h
>>>> index 35d7eedb5e8e..d02cb7aa922f 100644
>>>> --- a/include/linux/virtio_vsock.h
>>>> +++ b/include/linux/virtio_vsock.h
>>>> @@ -50,6 +50,7 @@ struct virtio_vsock_pkt {
>>>>        u32 off;
>>>>        bool reply;
>>>>        bool tap_delivered;
>>>> +    bool slab_buf;
>>>>    };
>>>>      struct virtio_vsock_pkt_info {
>>>> diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
>>>> index ad64f403536a..19909c1e9ba3 100644
>>>> --- a/net/vmw_vsock/virtio_transport.c
>>>> +++ b/net/vmw_vsock/virtio_transport.c
>>>> @@ -255,16 +255,20 @@ static void virtio_vsock_rx_fill(struct virtio_vsock *vsock)
>>>>        vq = vsock->vqs[VSOCK_VQ_RX];
>>>>          do {
>>>> +        struct page *buf_page;
>>>> +
>>>>            pkt = kzalloc(sizeof(*pkt), GFP_KERNEL);
>>>>            if (!pkt)
>>>>                break;
>>>>    -        pkt->buf = kmalloc(buf_len, GFP_KERNEL);
>>>> -        if (!pkt->buf) {
>>>> +        buf_page = alloc_page(GFP_KERNEL);
>>>> +
>>>> +        if (!buf_page) {
>>>>                virtio_transport_free_pkt(pkt);
>>>>                break;
>>>>            }
>>>>    +        pkt->buf = page_to_virt(buf_page);
>>>>            pkt->buf_len = buf_len;
>>>>            pkt->len = buf_len;
>>>>    diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
>>>> index a9980e9b9304..37e8dbfe2f5d 100644
>>>> --- a/net/vmw_vsock/virtio_transport_common.c
>>>> +++ b/net/vmw_vsock/virtio_transport_common.c
>>>> @@ -69,6 +69,7 @@ virtio_transport_alloc_pkt(struct virtio_vsock_pkt_info *info,
>>>>            if (!pkt->buf)
>>>>                goto out_pkt;
>>>>    +        pkt->slab_buf = true;
>>>>            pkt->buf_len = len;
>>>>              err = memcpy_from_msg(pkt->buf, info->msg, len);
>>>> @@ -1339,7 +1340,14 @@ EXPORT_SYMBOL_GPL(virtio_transport_recv_pkt);
>>>>      void virtio_transport_free_pkt(struct virtio_vsock_pkt *pkt)
>>>>    {
>>>> -    kvfree(pkt->buf);
>>>> +    if (pkt->buf_len) {
>>>> +        if (pkt->slab_buf)
>>>> +            kvfree(pkt->buf);
>>>
>>> Hi,
>>>
>>> kfree()? (according to virtio_transport_alloc_pkt() in -next) or something else need to be changed.
>>>
>> Hello Cristophe,
>>
>> I think, 'kvfree()' is still needed here, because buffer for packet could be allocated by 'kvmalloc()'
>> in drivers/vhost/vsock.c. Correct me if i'm wrong.
> 
> Agreed.
> 
>>
>>>> +        else
>>>> +            free_pages((unsigned long)pkt->buf,
>>>> +                   get_order(pkt->buf_len));
>>>
>>> In virtio_vsock_rx_fill(), only alloc_page() is used.
>>>
>>> Should this be alloc_pages(.., get_order(buf_len)) or free_page() (without an 's') here?
>> This function frees packets which were allocated in vhost path also. In vhost, for zerocopy
>> packets alloc_pageS() is used.
> 
> Ok. Seen in patch 5/11.
> 
> But wouldn't it be cleaner and future-proof to also have alloc_pageS() in virtio_vsock_rx_fill(), even if get_order(buf->len) is kwown to be 0?
> 
> What, if for some reason a PAGE_SIZE was < 4kb for a given arch, or VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE increased?
Yes, i see. You're right. It will be correct to use alloc_pages(get_order(buf->len)), because in current version, real length of
packet buffer(e.g. single page) is totally unrelated with VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE. I'll fix it in next version.

Thank You
> 
> CJ
> 
>>
>> Thank You, Arseniy
>>>
>>> Just my 2c,
>>>
>>> CJ
>>>
>>>> +    }
>>>> +
>>>>        kfree(pkt);
>>>>    }
>>>>    EXPORT_SYMBOL_GPL(virtio_transport_free_pkt);
>>>
>>
> 


  reply	other threads:[~2022-11-07 21:32 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-06 19:33 [RFC PATCH v3 00/11] virtio/vsock: experimental zerocopy receive Arseniy Krasnov
2022-11-06 19:36 ` [RFC PATCH v3 01/11] virtio/vsock: rework packet allocation logic Arseniy Krasnov
2022-11-06 19:50   ` Christophe JAILLET
2022-11-07  5:23     ` Arseniy Krasnov
2022-11-07 21:24       ` Christophe JAILLET
2022-11-07 21:31         ` Arseniy Krasnov [this message]
2022-11-11 20:35   ` Bobby Eshleman
2022-11-06 19:38 ` [RFC PATCH v3 02/11] virtio/vsock: update, 'virtio_transport_recv_pkt()' Arseniy Krasnov
2022-11-06 19:40 ` [RFC PATCH v3 03/11] af_vsock: add zerocopy receive logic Arseniy Krasnov
2022-11-11 13:55   ` Stefano Garzarella
2022-11-11 13:55     ` Stefano Garzarella
2022-11-06 19:41 ` [RFC PATCH v3 04/11] virtio/vsock: add transport zerocopy callback Arseniy Krasnov
2022-11-10 11:15   ` Arseniy Krasnov
2022-11-06 19:43 ` [RFC PATCH v3 05/11] vhost/vsock: switch packet's buffer allocation Arseniy Krasnov
2022-11-06 19:45 ` [RFC PATCH v3 06/11] vhost/vsock: enable zerocopy callback Arseniy Krasnov
2022-11-06 19:47 ` [RFC PATCH v3 07/11] virtio/vsock: " Arseniy Krasnov
2022-11-06 19:48 ` [RFC PATCH v3 08/11] test/vsock: rework message bound test Arseniy Krasnov
2022-11-11 14:00   ` Stefano Garzarella
2022-11-11 14:00     ` Stefano Garzarella
2022-11-06 19:50 ` [RFC PATCH v3 09/11] test/vsock: add big message test Arseniy Krasnov
2022-11-06 19:51 ` [RFC PATCH v3 10/11] test/vsock: add receive zerocopy tests Arseniy Krasnov
2022-11-06 19:54 ` [RFC PATCH v3 11/11] test/vsock: vsock_rx_perf utility Arseniy Krasnov
2022-11-11 13:47 ` [RFC PATCH v3 00/11] virtio/vsock: experimental zerocopy receive Stefano Garzarella
2022-11-11 13:47   ` Stefano Garzarella
2022-11-11 14:06   ` Stefano Garzarella
2022-11-11 14:06     ` Stefano Garzarella
2022-11-11 18:35     ` Arseniy Krasnov
2022-11-11 20:45   ` Bobby Eshleman
2022-11-12 11:40     ` Arseniy Krasnov
2022-11-13 10:04       ` Arseniy Krasnov

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=76b4ee49-e3b0-34be-6b81-f58bc2bc3dcc@sberdevices.ru \
    --to=avkrasnov@sberdevices.ru \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jasowang@redhat.com \
    --cc=kernel@sberdevices.ru \
    --cc=kuba@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=oxffffaa@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=sgarzare@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.