From: Heng Qi <hengqi@linux.alibaba.com>
To: "Michael S. Tsirkin" <mst@redhat.com>, Jason Wang <jasowang@redhat.com>
Cc: "virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
Yuri Benditovich <yuri.benditovich@daynix.com>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>
Subject: [virtio-dev] Re: [virtio-comment] Re: [virtio-dev] Re: [virtio-comment] Re: [PATCH v5] virtio-net: device does not deliver partially checksummed packet and may validate the checksum
Date: Wed, 20 Dec 2023 17:31:32 +0800 [thread overview]
Message-ID: <587686d2-79c7-41a3-aad0-cadec070694c@linux.alibaba.com> (raw)
In-Reply-To: <20231220020428-mutt-send-email-mst@kernel.org>
在 2023/12/20 下午3:35, Michael S. Tsirkin 写道:
> On Wed, Dec 20, 2023 at 02:30:01PM +0800, Heng Qi wrote:
>> But why are we discussing this?
> I think basically at this point everyone is confused about what
> the feature does. right now we have packets
> with
> #define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 -> partial
> #define VIRTIO_NET_HDR_F_DATA_VALID 2 -> unnecessary
> and packets without either -> none
>
> if both 1 and 2 are set then linux uses VIRTIO_NET_HDR_F_NEEDS_CSUM but
> I am not sure it's not a mistake. Maybe it does not matter.
>
> What does this new thing do? So far all we have is "XDP will turn it on"
> which is not really sufficient. I assumed it somehow replaces
> partial with complete. That would make sense for many reasons,
> for example the checksum fields in the header can be reused
> for other purposes. But maybe not?
Hello Jaosn and Michael. I've summarized our discussion so far, so check
it out below. Thank you very much!
From the nic perspective, I think Jason's statement is correct, the
nic's checksum capability and setting DATA_VALID in flags
should not be determined by GUEST_CSUM feature. As long as the rx
checksum offload is turned on, DATA_VALID
should be set. (Though we now bind GUEST_CSUM negotiation with rx
checksum offload.)
Therefore, we need to pay attention to the information of rx checksum
offload. Please check it out:
Devices that comply with the below description are said to be existing
devices:
"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."
As suggested by Jason, devices that comply with the below description
are said to be new devices:
"If VIRTIO_NET_F_GUEST_CSUM is not negotiated, the device *MAY* set
flags to zero and SHOULD supply a fully checksummed packet to the driver."
1. Rx checksum offload is turned on
GUEST_CSUM feature is not negotiated. (now it is only used to indicate
whether the driver can handle partially checksummed packets)
a. Existing devices continue to set flags to 0;
b. New devices may validate the packets and have flags set to
DATA_VALID;
c. Migration.
Migration of existing devices continues to check GUEST_CSUM
feature and rx checksum offload;
Migration of new devices only check rx checksum offload;
Without updating the existing migration management and control
system, existing devices cannot be migrated to new devices, and new
devices cannot be migrated to existing devices.
d. How offload should be controlled now needs attention. Should
CTRL_GUEST_OFFLOADS still issue GUEST_CSUM feature bit to control the rx
checksum offload?
2. The new FULLY_CSUM feature must disable NEEDS_CSUM.
The device may set DATA_VALID regardless of whether FULLY_CSUM or
GUEST_CSUM is negotiated.
a. Rx fully checksum offload is still controlled by
CTRL_GUEST_OFFLOADS carrying GUEST_FULLY_CSUM.
b. When the rx device receives a partially checksummed packet, it
should calculate the checksum and delivering a fully checksummed packet
to the driver.
So now, if we modify the existing spec as Jason suggested, I think it's OK.
But we need to find out how to control rx checksum offload. WDYT?
Thanks!
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2023-12-20 9:31 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <959e1a7ccdfffaaadd865a627924cf492ce22bfa.1702277523.git.hengqi@linux.alibaba.com>
[not found] ` <20231211110350-mutt-send-email-mst@kernel.org>
[not found] ` <a8ba676e-de43-45ae-a6a8-a67d0dd41c1f@linux.alibaba.com>
[not found] ` <20231212032713-mutt-send-email-mst@kernel.org>
[not found] ` <bfd25f86-4292-45d2-a7a2-fe61bde0edb4@linux.alibaba.com>
[not found] ` <b739d275-3664-4509-8a91-f19690719475@linux.alibaba.com>
2023-12-15 9:51 ` [virtio-dev] Re: [virtio-comment] Re: [PATCH v5] virtio-net: device does not deliver partially checksummed packet and may validate the checksum Heng Qi
2023-12-18 3:10 ` Jason Wang
2023-12-18 4:54 ` Heng Qi
2023-12-19 7:53 ` Jason Wang
2023-12-19 16:06 ` Heng Qi
2023-12-20 5:48 ` Jason Wang
2023-12-20 6:30 ` Heng Qi
2023-12-20 6:59 ` Jason Wang
2023-12-20 7:42 ` [virtio-dev] Re: [virtio-comment] " Heng Qi
2023-12-21 1:34 ` Jason Wang
2023-12-21 3:43 ` Heng Qi
2023-12-21 4:04 ` Jason Wang
2023-12-20 9:54 ` Heng Qi
2023-12-20 7:35 ` Michael S. Tsirkin
2023-12-20 9:31 ` Heng Qi [this message]
2023-12-21 1:41 ` [virtio-dev] Re: [virtio-comment] " Jason Wang
2023-12-21 1:50 ` Jason Wang
2023-12-21 3:51 ` Heng Qi
2023-12-21 4:04 ` Jason Wang
2023-12-21 1:34 ` Jason Wang
2023-12-21 3:45 ` [virtio-dev] Re: [virtio-comment] " Heng Qi
2023-12-21 3:51 ` Jason Wang
2023-12-19 18:41 ` Michael S. Tsirkin
2023-12-20 5:52 ` Jason Wang
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=587686d2-79c7-41a3-aad0-cadec070694c@linux.alibaba.com \
--to=hengqi@linux.alibaba.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@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