All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
To: Heng Qi <hengqi@linux.alibaba.com>
Cc: virtio-dev@lists.oasis-open.org, Jason Wang <jasowang@redhat.com>,
	kangjie.xu@linux.alibaba.com,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: [virtio-dev] Re: [PATCH v7] virtio_net: support split header
Date: Mon, 5 Sep 2022 17:43:27 +0800	[thread overview]
Message-ID: <1662371007.8074908-1-xuanzhuo@linux.alibaba.com> (raw)
In-Reply-To: <3b7a4b68-b889-8432-d421-b591178bb7cf@linux.alibaba.com>

On Mon, 5 Sep 2022 16:37:57 +0800, Heng Qi <hengqi@linux.alibaba.com> wrote:
>
> 在 2022/9/5 下午3:52, Xuan Zhuo 写道:
> > On Sun, 4 Sep 2022 16:31:59 -0400, "Michael S. Tsirkin"<mst@redhat.com>  wrote:
> >> On Fri, Sep 02, 2022 at 04:58:16PM +0800, Heng Qi wrote:
> >>> When VIRTIO_NET_F_SPLIT_TRANSPORT_HEADER is negotiated,
> >>> the driver requires that the buffers submitted to receiveq
> >>> MUST be composed of at least two descriptors,
> >>> which means that each buffer the device gets is a descriptor chain,
> >>> even if the device does not split the header for some packets.
> >>>
> >>> To store packet in the descriptor chain without header splitting
> >>> by the device, the device MUST start with the first descriptor of
> >>> the descriptor chain to store the packet, and MUST NOT set the
> >>> VIRTIO_NET_HDR_F_SPLIT_TRANSPORT_HEADER bit in \field{flags}.
> >>>
> >>> Thanks.
> >> Descriptor chains will hurt performance badly.
> > I understand the reasons for the performance impact here are:
> > 1. Two buffers are used
> > 2. One buffer occupies two descs
> >
> > This is the same as my understanding in the case of mergeable. We also need to
> > pack the packets into two buffers, and a packet will eventually occupy two
> > descs.
> >
> >
> >> How about simply making this feature depend on mergeable buffers?
> >> Then we have a separate buffer for the header and
> >> this works cleanly.
> >
> > Under mergeable, each buffer is independent, and the split header requires two
> > unequal descs.
> >
> > If we implement it based on mergeable, then consider the scenario of tcp
> > zerocopy, when we fill receive vq, each buffer is an separate page, and if we use an
> > separate buffer to save the header, then this is a waste, we may
> > have to copy at the driver layer.
> >
> > @Qi Do you think there will be other problems with this approach?
> >
> > Thanks.
> >
> When we think about specs, we shouldn't be too distracted by the implementation.
>
> But when we did think about this, suppose the driver fills by page based on
> mergeable mode. in order to use the xdp program, the driver usually takes
> the beginning of a single page as the headroom, and fills the rest of the page
> into the virtqueue. Therefore, the empty buffer obtained by the
> device is always smaller than a page when we implement split header
> based on this mode, that is, the data load finally obtained by the driver
> is offset from the beginning of the page. This does not enjoy the benefits of zero copy.
>
> At the same time, since the header is always only more than 100 bytes,
> the page occupied by the header is a waste of the buffer.


Yeah that reminds me that merge doesn't feel like it handles this very well.

The essence is that the two buffers used by the split header are different.

Desc Chain is used to bind a small buffer desc and a page desc. I didn't think
of a better way to deal with this problem.

Thanks.


>
> Thanks.
>
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2022-09-05  9:47 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-16  9:34 [virtio-dev] [PATCH v7] virtio_net: support split header Heng Qi
2022-08-25 14:22 ` Cornelia Huck
2022-08-30 11:23   ` Heng Qi
2022-08-30 11:26 ` Heng Qi
2022-09-02  4:12 ` Heng Qi
2022-09-08 21:18   ` Michael S. Tsirkin
2022-09-02  6:21 ` [virtio-dev] " Jason Wang
2022-09-02  6:41   ` Michael S. Tsirkin
2022-09-02  8:58     ` Heng Qi
2022-09-04 20:31       ` Michael S. Tsirkin
2022-09-05  7:52         ` Xuan Zhuo
2022-09-05  8:37           ` Heng Qi
2022-09-05  9:43             ` Xuan Zhuo [this message]
2022-09-06  5:47               ` Jason Wang
2022-09-08 21:18               ` Michael S. Tsirkin
2022-09-02  7:36   ` Heng Qi
2022-09-04 20:27     ` Michael S. Tsirkin
2022-09-06  5:56       ` Jason Wang
2022-09-09  7:41       ` [virtio-dev] " Heng Qi
2022-09-09 11:15         ` Michael S. Tsirkin
2022-09-09 12:38           ` Xuan Zhuo
2022-09-14  3:34             ` Jason Wang
2022-09-27 21:35               ` Michael S. Tsirkin
2022-09-28  2:15                 ` Heng Qi
2022-09-28  8:01                 ` Xuan Zhuo
2022-09-09 12:47           ` Xuan Zhuo
2022-09-13  7:20             ` Heng Qi
2022-09-09 10:22       ` Heng Qi
2022-09-02  8:26   ` Heng Qi
2022-09-06  5:53     ` Jason Wang
2022-09-02  6:48 ` Michael S. Tsirkin
2022-09-07 11:16 ` [virtio-dev] " Heng Qi

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=1662371007.8074908-1-xuanzhuo@linux.alibaba.com \
    --to=xuanzhuo@linux.alibaba.com \
    --cc=hengqi@linux.alibaba.com \
    --cc=jasowang@redhat.com \
    --cc=kangjie.xu@linux.alibaba.com \
    --cc=mst@redhat.com \
    --cc=virtio-dev@lists.oasis-open.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.