Discussion of the VIRTIO specification
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Heng Qi <hengqi@linux.alibaba.com>
Cc: Jason Wang <jasowang@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Yuri Benditovich <yuri.benditovich@daynix.com>,
	virtio-comment@lists.oasis-open.org,
	Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Subject: Re: [virtio-comment] Re: [virtio-dev] Re: [PATCH v8] virtio-net: correct conditions for devices to validate packet checksum
Date: Tue, 27 Feb 2024 10:16:04 +0100	[thread overview]
Message-ID: <871q8yclnv.fsf@redhat.com> (raw)
In-Reply-To: <601c156a-8647-43b8-8517-3df9df4c529a@linux.alibaba.com>

On Tue, Feb 27 2024, Heng Qi <hengqi@linux.alibaba.com> wrote:

> 在 2024/2/20 上午10:38, Heng Qi 写道:
>>
>>
>> 在 2024/1/16 下午1:52, Xuan Zhuo 写道:
>>> On Wed,  3 Jan 2024 14:35:02 +0800, Heng Qi 
>>> <hengqi@linux.alibaba.com> wrote:
>>>> There is a historical error in virtio spec:
>>>>    "If VIRTIO_NET_F_GUEST_CSUM is not negotiated, the device *MUST* 
>>>> set flags
>>>>     to zero and SHOULD supply a fully checksummed packet to the 
>>>> driver."
>>>>
>>>> Currently in Linux and virtio-related implementations, the device 
>>>> validates
>>>> the packet checksum and sets DATA_VALID regardless of whether
>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated.
>>>>
>>>> Please refer to the following summary and thread[1] for details and 
>>>> reasons:
>>>>
>>>> Summary
>>>> =============
>>>> 1. GUEST_CSUM at virtio spec 0.95 is intended to be compatible with 
>>>> partially
>>>> checksummed packets (NEEDS_CSUM <-> CHECKSUM_PARTIAL). So GUEST_CSUM 
>>>> is mapped
>>>> to NETIF_F_RXCSUM.
>>>> GUEST_CSUM only indicates whether the driver handles partially 
>>>> checksummed packets.
>>>> When XDP is loaded, the GUEST_CSUM's offload will be disabled, which 
>>>> means that
>>>> packets have NEEDS_CSUM set will be dropped, and packets have 
>>>> DATA_VALID set will
>>>> still be received.
>>>>
>>>> 2. When DATA_VALID was added to Linux in 2011[2] and virtio1.0, it 
>>>> was actually
>>>> expected that rx checksum offload (the driver can set 
>>>> CHECKSUM_UNNECESSARY) had
>>>> nothing to do with whether GUEST_CSUM was negotiated. But due to an 
>>>> error, below
>>>> desctiption was added incorrectly:
>>>>    "If VIRTIO_NET_F_GUEST_CSUM is not negotiated, the device *MUST* 
>>>> set flags
>>>>     to zero and SHOULD supply a fully checksummed packet to the 
>>>> driver."
>>>>
>>>> 3. We now hope to correct this error. Let the setting of DATA_VALID 
>>>> not be
>>>> controlled by whether GUEST_CSUM is negotiated, but only controlled 
>>>> by whether
>>>> rx checksum offload is enabled on the OS side. The state of this rx 
>>>> checksum
>>>> offload is not aware of the device.
>>>>
>>>> 4. [Optional] NETIF_F_RXCSUM corresponding to rx checksum offload 
>>>> should be
>>>> added to dev->hw_features. When the user turns off rx checksum 
>>>> offload through
>>>> ethtool -K, neither NEEDS_CSUM nor DATA_VALID should be taken care 
>>>> of, that is,
>>>> all packets will be marked as CHECKSUM_NONE.
>>>>
>>>> Related Link
>>>> =============
>>>> [1] 
>>>> https://lists.oasis-open.org/archives/virtio-comment/202312/msg00135.html
>>>> [2] 10a8d94a9574 ("virtio_net: introduce VIRTIO_NET_HDR_F_DATA_VALID")
>>>>
>>>> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/185
>>
>> Hi Cornelia,
>>
>> Can this proposal be opened for voting?
>>
>> Thank you very much!
>>
>>>>
>>>> Suggested-by: Jason Wang <jasowang@redhat.com>
>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
>>> Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
>
> Hi Cornelia.
>
> Did you miss this email? :)
>
> Both Jason and Xuan have replied to Reviewed-by tag.
> Can we initiate a vote?

We currently can't do any voting (OASIS infrastructure update), and we
probably have to sort out the fallout from the new platform once it's
up.


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


      reply	other threads:[~2024-02-27  9:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-03  6:35 [virtio-comment] [PATCH v8] virtio-net: correct conditions for devices to validate packet checksum Heng Qi
2024-01-04  4:47 ` [virtio-comment] Re: [virtio-dev] " Heng Qi
2024-01-08  3:48   ` Jason Wang
2024-01-11  3:27   ` Heng Qi
2024-01-11 16:27     ` Cornelia Huck
2024-01-12  3:09       ` Heng Qi
2024-01-16  5:52 ` [virtio-comment] " Xuan Zhuo
2024-02-20  2:38   ` [virtio-comment] Re: [virtio-dev] " Heng Qi
2024-02-27  6:30     ` Heng Qi
2024-02-27  9:16       ` Cornelia Huck [this message]

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=871q8yclnv.fsf@redhat.com \
    --to=cohuck@redhat.com \
    --cc=hengqi@linux.alibaba.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=xuanzhuo@linux.alibaba.com \
    --cc=yuri.benditovich@daynix.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