[virtio-comment] [PATCH v4 0/2] virtio-net: support distinguishing between partial and full checksum

[virtio-comment] [PATCH v4 0/2] virtio-net: support distinguishing between partial and full checksum

[Heng Qi]

If VIRTIO_NET_F_GUEST_CSUM is negotiated, the driver does not support the
loading of XDP because it can receive packets with partial checksum.

This prevents users using XDP from enjoying the benefits of device
calculation and validation of checksum.

This patch set is designed to resolve this issue.

Changelog:
=========
v3->v4:
- Patch[1/2]: Update the description for VIRTIO_NET_F_GUEST_CSUM.
- Patch[2/2]:
  - Streamline some repetitive descriptions.
  - Add how features should work, when to be enabled, and overhead.

v2->v3:
- Add a section named "Driver Handles Fully Checksummed Packets"
  and more descriptions. @Michael

v1->v2:
- Modify full checksum functionality as a configurable offload
  that is initially turned off. @Jason

Heng Qi (2):
  virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.
  virtio-net: support distinguishing between partial and full checksum

 device-types/net/description.tex        | 68 ++++++++++++++++++++++---
 device-types/net/device-conformance.tex |  1 +
 device-types/net/driver-conformance.tex |  1 +
 introduction.tex                        |  3 ++
 4 files changed, 66 insertions(+), 7 deletions(-)

-- 
2.19.1.6.gb485710b


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/

[virtio-comment] [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Heng Qi]

To prevent readers from misunderstanding that the driver can
only handles packets with partial checksum when
VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.

Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
---
 device-types/net/description.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/device-types/net/description.tex b/device-types/net/description.tex
index aff5e08..529f470 100644
--- a/device-types/net/description.tex
+++ b/device-types/net/description.tex
@@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types / Network Device / Feature bits
 \begin{description}
 \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with partial checksum offload.
 
-\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial checksum.
+\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial checksum or full checksum.
 
 \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
         reconfiguration support.
-- 
2.19.1.6.gb485710b


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/

[virtio-comment] [PATCH v4 2/2] virtio-net: support distinguishing between partial and full checksum

[Heng Qi]

virtio-net works in a virtualized system and is somewhat different from
physical nics. One of the differences is that to save virtio device
resources, rx may receive packets with partial checksum. However, XDP may
cause partially checksummed packets to be dropped. So XDP loading conflicts
with the feature VIRTIO_NET_F_GUEST_CSUM.

This patch lets the device to supply fully checksummed packets to the driver.
Then XDP can coexist with VIRTIO_NET_F_GUEST_CSUM to enjoy the benefits of
device verification checksum.

In addition, implementation of some performant devices do not generate
partially checksummed packets, but the standard driver still need to clear
VIRTIO_NET_F_GUEST_CSUM when loading XDP. If these devices enable the
full checksum offloading, then the driver can load XDP without clearing
VIRTIO_NET_F_GUEST_CSUM.

A new feature bit VIRTIO_NET_F_GUEST_FULL_CSUM is added to solve the above
situation, which provides the driver with configurable receive full checksum
offload. If the offload is enabled, then the device must supply fully
checksummed packets to the driver.

Use case example:
If VIRTIO_NET_F_GUEST_FULL_CSUM is negotiated and receive full checksum
offload is enabled, after XDP processes a packet with full checksum, the
VIRTIO_NET_HDR_F_DATA_VALID bit is still retained, resulting in the stack
not needing to validate the checksum again. This is useful for guests:
  1. Bring the driver advantages such as cpu savings.
  2. For devices that do not generate partially checksummed packets themselves,
     XDP can be loaded in the driver without modifying the hardware behavior.

Several solutions have been discussed in the previous proposal[1].
After historical discussion, we have tried the method proposed by Jason[2],
but some complex scenarios and challenges are difficult to deal with.
We now return to the method suggested in [1].

[1] https://lists.oasis-open.org/archives/virtio-dev/202305/msg00291.html
[2] https://lore.kernel.org/all/20230628030506.2213-1-hengqi@linux.alibaba.com/

Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
---
v3->v4:
- Streamline some repetitive descriptions. @Jason
- Add how features should work, when to be enabled, and overhead. @Jason @Michael

v2->v3:
- Add a section named "Driver Handles Fully Checksummed Packets"
  and more descriptions. @Michael

v1->v2:
- Modify full checksum functionality as a configurable offload
  that is initially turned off. @Jason


 device-types/net/description.tex        | 66 ++++++++++++++++++++++---
 device-types/net/device-conformance.tex |  1 +
 device-types/net/driver-conformance.tex |  1 +
 introduction.tex                        |  3 ++
 4 files changed, 65 insertions(+), 6 deletions(-)

diff --git a/device-types/net/description.tex b/device-types/net/description.tex
index 529f470..d08c31e 100644
--- a/device-types/net/description.tex
+++ b/device-types/net/description.tex
@@ -122,6 +122,8 @@ \subsection{Feature bits}\label{sec:Device Types / Network Device / Feature bits
     device with the same MAC address.
 
 \item[VIRTIO_NET_F_SPEED_DUPLEX(63)] Device reports speed and duplex.
+
+\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with full checksum.
 \end{description}
 
 \subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device / Feature bits / Feature bit requirements}
@@ -136,6 +138,7 @@ \subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device
 \item[VIRTIO_NET_F_GUEST_UFO] Requires VIRTIO_NET_F_GUEST_CSUM.
 \item[VIRTIO_NET_F_GUEST_USO4] Requires VIRTIO_NET_F_GUEST_CSUM.
 \item[VIRTIO_NET_F_GUEST_USO6] Requires VIRTIO_NET_F_GUEST_CSUM.
+\item[VIRTIO_NET_F_GUEST_FULL_CSUM] Requires VIRTIO_NET_F_GUEST_CSUM and VIRTIO_NET_F_CTRL_GUEST_OFFLOADS.
 
 \item[VIRTIO_NET_F_HOST_TSO4] Requires VIRTIO_NET_F_CSUM.
 \item[VIRTIO_NET_F_HOST_TSO6] Requires VIRTIO_NET_F_CSUM.
@@ -398,6 +401,51 @@ \subsection{Device Initialization}\label{sec:Device Types / Network Device / Dev
 A truly minimal driver would only accept VIRTIO_NET_F_MAC and ignore
 everything else.
 
+\subsubsection{Driver Handles Fully Checksummed Packets}\label{sec:Device Types / Network Device / Device Initialization / Driver Handles Fully Checksummed Packets}
+
+The VIRTIO_NET_F_GUEST_CSUM feature indicates that the driver can handle
+partially or fully checksummed packets from the device.
+
+When the driver only expects fully checksummed packets, the
+VIRTIO_NET_F_GUEST_FULL_CSUM feature can be negotiated if the device offers it.
+Then the driver only handles packets with full checksum.
+
+If the VIRTIO_NET_F_GUEST_FULL_CSUM feature is negotiated, the driver can
+benefit from the device's ability to calculate and validate the checksum.
+
+Delivering fully checksummed packets rather than partially
+checksummed packets incurs additional overhead for the device.
+The overhead varies from device to device, for example the overhead of
+calculating and validating the packet checksum is a few microseconds
+for a hardware device.
+
+The VIRTIO_NET_F_GUEST_FULL_CSUM feature has a corresponding offload \ref{sec:Device Types /
+Network Device / Device Operation / Control Virtqueue / Offloads State Configuration},
+which when enabled means that the driver only processes packets with full checksum.
+The offload is disabled by default.
+
+The driver can enable the offload by sending the
+VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET command with the
+VIRTIO_NET_F_GUEST_FULL_CSUM bit set when, for example,
+eXpress Data Path (XDP) \hyperref[intro:xdp]{[XDP]} is functioning.
+
+\drivernormative{\subsubsection}{Driver Handles Fully Checksummed Packets}{sec:Device Types / Network Device / Device Initialization / Driver Handles Fully Checksummed Packets}
+
+The driver MUST NOT enable the offload for which VIRTIO_NET_F_GUEST_FULL_CSUM has not been negotiated.
+
+\devicenormative{\subsubsection}{Driver Handles Fully Checksummed Packets}{sec:Device Types / Network Device / Device Initialization / Driver Handles Fully Checksummed Packets}
+
+Upon the device reset, the device MUST disable the offload.
+
+If the offload was enabled, the device behaves as follows:
+\begin{itemize}
+\item The device MUST supply a fully checksummed packet to the driver.
+\item The device MUST NOT set the VIRTIO_NET_HDR_F_NEEDS_CSUM bit in \field{flags}.
+\item The device MAY set the VIRTIO_NET_HDR_F_DATA_VALID bit in \field{flags}, if so,
+the device MUST validate the packet checksum (in case of multiple encapsulated protocols,
+one level of checksums is validated).
+\end{itemize}
+
 \subsection{Device Operation}\label{sec:Device Types / Network Device / Device Operation}
 
 Packets are transmitted by placing them in the
@@ -723,7 +771,8 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
   \field{num_buffers} is one, then the entire packet will be
   contained within this buffer, immediately following the struct
   virtio_net_hdr.
-\item If the VIRTIO_NET_F_GUEST_CSUM feature was negotiated, the
+\item If the VIRTIO_NET_F_GUEST_CSUM feature (regardless of whether
+  VIRTIO_NET_F_GUEST_FULL_CSUM was negotiated) was negotiated, the
   VIRTIO_NET_HDR_F_DATA_VALID bit in \field{flags} can be
   set: if so, device has validated the packet checksum.
   In case of multiple encapsulated protocols, one level of checksums
@@ -747,7 +796,8 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
   number of coalesced TCP segments in \field{csum_start} field and
   number of duplicated ACK segments in \field{csum_offset} field
   and sets bit VIRTIO_NET_HDR_F_RSC_INFO in \field{flags}.
-\item If the VIRTIO_NET_F_GUEST_CSUM feature was negotiated, the
+\item If the VIRTIO_NET_F_GUEST_CSUM feature was negotiated but the
+  VIRTIO_NET_F_GUEST_FULL_CSUM feature was not negotiated, the
   VIRTIO_NET_HDR_F_NEEDS_CSUM bit in \field{flags} can be
   set: if so, the packet checksum at offset \field{csum_offset}
   from \field{csum_start} and any preceding checksums
@@ -805,8 +855,9 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
 device MUST set the VIRTIO_NET_HDR_GSO_ECN bit in
 \field{gso_type}.
 
-If the VIRTIO_NET_F_GUEST_CSUM feature has been negotiated, the
-device MAY set the VIRTIO_NET_HDR_F_NEEDS_CSUM bit in
+If the VIRTIO_NET_F_GUEST_CSUM feature has been negotiated but
+the VIRTIO_NET_F_GUEST_FULL_CSUM feature has not been negotiated,
+the device MAY set the VIRTIO_NET_HDR_F_NEEDS_CSUM bit in
 \field{flags}, if so:
 \begin{enumerate}
 \item the device MUST validate the packet checksum at
@@ -826,7 +877,8 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
 been negotiated, the device MUST set \field{gso_type} to
 VIRTIO_NET_HDR_GSO_NONE.
 
-If \field{gso_type} differs from VIRTIO_NET_HDR_GSO_NONE, then
+If the VIRTIO_NET_F_GUEST_FULL_CSUM feature has not been negotiated and
+\field{gso_type} differs from VIRTIO_NET_HDR_GSO_NONE, then
 the device MUST also set the VIRTIO_NET_HDR_F_NEEDS_CSUM bit in
 \field{flags} MUST set \field{gso_size} to indicate the desired MSS.
 If VIRTIO_NET_F_RSC_EXT was negotiated, the device MUST also
@@ -842,7 +894,8 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
 not less than the length of the headers, including the transport
 header.
 
-If the VIRTIO_NET_F_GUEST_CSUM feature has been negotiated, the
+If the VIRTIO_NET_F_GUEST_CSUM feature (regardless of whether
+VIRTIO_NET_F_GUEST_FULL_CSUM has been negotiated) has been negotiated, the
 device MAY set the VIRTIO_NET_HDR_F_DATA_VALID bit in
 \field{flags}, if so, the device MUST validate the packet
 checksum (in case of multiple encapsulated protocols, one level
@@ -1633,6 +1686,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
 #define VIRTIO_NET_F_GUEST_UFO        10
 #define VIRTIO_NET_F_GUEST_USO4       54
 #define VIRTIO_NET_F_GUEST_USO6       55
+#define VIRTIO_NET_F_GUEST_FULL_CSUM  64
 
 #define VIRTIO_NET_CTRL_GUEST_OFFLOADS       5
  #define VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET   0
diff --git a/device-types/net/device-conformance.tex b/device-types/net/device-conformance.tex
index 52526e4..e72cb5b 100644
--- a/device-types/net/device-conformance.tex
+++ b/device-types/net/device-conformance.tex
@@ -16,4 +16,5 @@
 \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Notifications Coalescing}
 \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Inner Header Hash}
 \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Device Statistics}
+\item \ref{devicenormative:Device Types / Network Device / Device Initialization / Driver Handles Fully Checksummed Packets}
 \end{itemize}
diff --git a/device-types/net/driver-conformance.tex b/device-types/net/driver-conformance.tex
index c693c4f..6a1d7a7 100644
--- a/device-types/net/driver-conformance.tex
+++ b/device-types/net/driver-conformance.tex
@@ -16,4 +16,5 @@
 \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Notifications Coalescing}
 \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Inner Header Hash}
 \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Device Statistics}
+\item \ref{drivernormative:Device Types / Network Device / Device Initialization / Driver Handles Fully Checksummed Packets}
 \end{itemize}
diff --git a/introduction.tex b/introduction.tex
index cfa6633..fc99597 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -145,6 +145,9 @@ \section{Normative References}\label{sec:Normative References}
     Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP
     14, RFC 8174, DOI 10.17487/RFC8174, May 2017
         \newline\url{http://www.ietf.org/rfc/rfc8174.txt}\\
+	\phantomsection\label{intro:xdp}\textbf{[XDP]} &
+    eXpress Data Path(XDP) provides a high performance, programmable network data path in the Linux kernel.
+	\newline\url{https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/}\\
 \end{longtable}
 
 \section{Non-Normative References}
-- 
2.19.1.6.gb485710b


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/

[virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Jason Wang]

On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>
> To prevent readers from misunderstanding that the driver can
> only handles packets with partial checksum when
> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
>
> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> ---
>  device-types/net/description.tex | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/device-types/net/description.tex b/device-types/net/description.tex
> index aff5e08..529f470 100644
> --- a/device-types/net/description.tex
> +++ b/device-types/net/description.tex
> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types / Network Device / Feature bits
>  \begin{description}
>  \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with partial checksum offload.
>
> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial checksum.
> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial checksum or full checksum.

So patch 2 said

"
+\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
full checksum.
 \end{description}
"

Is there any difference between the two "full checksum" here?

Thanks

>
>  \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
>          reconfiguration support.
> --
> 2.19.1.6.gb485710b
>


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Heng Qi]

在 2023/11/29 下午4:00, Jason Wang 写道:
> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>> To prevent readers from misunderstanding that the driver can
>> only handles packets with partial checksum when
>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
>>
>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
>> ---
>>   device-types/net/description.tex | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/device-types/net/description.tex b/device-types/net/description.tex
>> index aff5e08..529f470 100644
>> --- a/device-types/net/description.tex
>> +++ b/device-types/net/description.tex
>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types / Network Device / Feature bits
>>   \begin{description}
>>   \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with partial checksum offload.
>>
>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial checksum.
>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial checksum or full checksum.
> So patch 2 said
>
> "
> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
> full checksum.
>   \end{description}
> "
>
> Is there any difference between the two "full checksum" here?

There's no difference.

The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver "can 
only" handle packets with full checksum.

Thanks!

>
> Thanks
>
>>   \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
>>           reconfiguration support.
>> --
>> 2.19.1.6.gb485710b
>>


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Jason Wang]

On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>
>
>
> 在 2023/11/29 下午4:00, Jason Wang 写道:
> > On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >> To prevent readers from misunderstanding that the driver can
> >> only handles packets with partial checksum when
> >> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
> >>
> >> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> >> ---
> >>   device-types/net/description.tex | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/device-types/net/description.tex b/device-types/net/description.tex
> >> index aff5e08..529f470 100644
> >> --- a/device-types/net/description.tex
> >> +++ b/device-types/net/description.tex
> >> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types / Network Device / Feature bits
> >>   \begin{description}
> >>   \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with partial checksum offload.
> >>
> >> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial checksum.
> >> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial checksum or full checksum.
> > So patch 2 said
> >
> > "
> > +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
> > full checksum.
> >   \end{description}
> > "
> >
> > Is there any difference between the two "full checksum" here?
>
> There's no difference.
>
> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver "can
> only" handle packets with full checksum.

This seems to be odd.

Driver can always handle packet with full checksum, no? I meant it
will be then to be functional equivalent to !
VIRTIO_NET_F_GUEST_FULL_CSUM?

Thanks

>
> Thanks!
>
> >
> > Thanks
> >
> >>   \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
> >>           reconfiguration support.
> >> --
> >> 2.19.1.6.gb485710b
> >>
>


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Heng Qi]

在 2023/12/1 下午1:18, Jason Wang 写道:
> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>
>>
>> 在 2023/11/29 下午4:00, Jason Wang 写道:
>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>> To prevent readers from misunderstanding that the driver can
>>>> only handles packets with partial checksum when
>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
>>>>
>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
>>>> ---
>>>>    device-types/net/description.tex | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/device-types/net/description.tex b/device-types/net/description.tex
>>>> index aff5e08..529f470 100644
>>>> --- a/device-types/net/description.tex
>>>> +++ b/device-types/net/description.tex
>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types / Network Device / Feature bits
>>>>    \begin{description}
>>>>    \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with partial checksum offload.
>>>>
>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial checksum.
>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial checksum or full checksum.
>>> So patch 2 said
>>>
>>> "
>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
>>> full checksum.
>>>    \end{description}
>>> "
>>>
>>> Is there any difference between the two "full checksum" here?
>> There's no difference.
>>
>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver "can
>> only" handle packets with full checksum.
> This seems to be odd.
>
> Driver can always handle packet with full checksum, no?

Yes.

> I meant it
> will be then to be functional equivalent to !
> VIRTIO_NET_F_GUEST_FULL_CSUM?

Are you referring to
"functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
If so, I think it's no.

Maybe a description similar to the following would be more clearer:

+\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle packets with partial checksum.

Thanks!

>
> Thanks
>
>> Thanks!
>>
>>> Thanks
>>>
>>>>    \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
>>>>            reconfiguration support.
>>>> --
>>>> 2.19.1.6.gb485710b
>>>>


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Heng Qi]

在 2023/12/1 下午2:24, Heng Qi 写道:
>
>
> 在 2023/12/1 下午1:18, Jason Wang 写道:
>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com> 
>> wrote:
>>>
>>>
>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com> 
>>>> wrote:
>>>>> To prevent readers from misunderstanding that the driver can
>>>>> only handles packets with partial checksum when
>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
>>>>>
>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
>>>>> ---
>>>>>    device-types/net/description.tex | 2 +-
>>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/device-types/net/description.tex 
>>>>> b/device-types/net/description.tex
>>>>> index aff5e08..529f470 100644
>>>>> --- a/device-types/net/description.tex
>>>>> +++ b/device-types/net/description.tex
>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types 
>>>>> / Network Device / Feature bits
>>>>>    \begin{description}
>>>>>    \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with 
>>>>> partial checksum offload.
>>>>>
>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with 
>>>>> partial checksum.
>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with 
>>>>> partial checksum or full checksum.
>>>> So patch 2 said
>>>>
>>>> "
>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
>>>> full checksum.
>>>>    \end{description}
>>>> "
>>>>
>>>> Is there any difference between the two "full checksum" here?
>>> There's no difference.
>>>
>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver 
>>> "can
>>> only" handle packets with full checksum.
>> This seems to be odd.
>>
>> Driver can always handle packet with full checksum, no?
>
> Yes.
>
>> I meant it
>> will be then to be functional equivalent to !
>> VIRTIO_NET_F_GUEST_FULL_CSUM?
>
> Are you referring to
> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?

Sorry, this is a typo. I meant

Are you referring to
"functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?

> If so, I think it's no.
>
> Maybe a description similar to the following would be more clearer:
>
> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle 
> packets with partial checksum.
>
> Thanks!
>
>>
>> Thanks
>>
>>> Thanks!
>>>
>>>> Thanks
>>>>
>>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
>>>>>            reconfiguration support.
>>>>> -- 
>>>>> 2.19.1.6.gb485710b
>>>>>
>
>
> 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/


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Jason Wang]

On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>
>
>
> 在 2023/12/1 下午2:24, Heng Qi 写道:
> >
> >
> > 在 2023/12/1 下午1:18, Jason Wang 写道:
> >> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
> >> wrote:
> >>>
> >>>
> >>> 在 2023/11/29 下午4:00, Jason Wang 写道:
> >>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
> >>>> wrote:
> >>>>> To prevent readers from misunderstanding that the driver can
> >>>>> only handles packets with partial checksum when
> >>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
> >>>>>
> >>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> >>>>> ---
> >>>>>    device-types/net/description.tex | 2 +-
> >>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/device-types/net/description.tex
> >>>>> b/device-types/net/description.tex
> >>>>> index aff5e08..529f470 100644
> >>>>> --- a/device-types/net/description.tex
> >>>>> +++ b/device-types/net/description.tex
> >>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
> >>>>> / Network Device / Feature bits
> >>>>>    \begin{description}
> >>>>>    \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
> >>>>> partial checksum offload.
> >>>>>
> >>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> >>>>> partial checksum.
> >>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> >>>>> partial checksum or full checksum.
> >>>> So patch 2 said
> >>>>
> >>>> "
> >>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
> >>>> full checksum.
> >>>>    \end{description}
> >>>> "
> >>>>
> >>>> Is there any difference between the two "full checksum" here?
> >>> There's no difference.
> >>>
> >>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
> >>> "can
> >>> only" handle packets with full checksum.
> >> This seems to be odd.
> >>
> >> Driver can always handle packet with full checksum, no?
> >
> > Yes.
> >
> >> I meant it
> >> will be then to be functional equivalent to !
> >> VIRTIO_NET_F_GUEST_FULL_CSUM?
> >
> > Are you referring to
> > "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
>
> Sorry, this is a typo. I meant
>
> Are you referring to
> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
>
> > If so, I think it's no.
> >
> > Maybe a description similar to the following would be more clearer:
> >
> > +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
> > packets with partial checksum.

I may miss something here, but what's the difference between

VIRTIO_NET_F_GUEST_FULL_CSUM

and

!VIRTIO_NET_F_GUEST_CSUM?

Thanks

> >
> > Thanks!
> >
> >>
> >> Thanks
> >>
> >>> Thanks!
> >>>
> >>>> Thanks
> >>>>
> >>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
> >>>>>            reconfiguration support.
> >>>>> --
> >>>>> 2.19.1.6.gb485710b
> >>>>>
> >
> >
> > 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/
>


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Heng Qi]

在 2023/12/1 下午3:05, Jason Wang 写道:
> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>
>>
>> 在 2023/12/1 下午2:24, Heng Qi 写道:
>>>
>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
>>>> wrote:
>>>>>
>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
>>>>>> wrote:
>>>>>>> To prevent readers from misunderstanding that the driver can
>>>>>>> only handles packets with partial checksum when
>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
>>>>>>>
>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
>>>>>>> ---
>>>>>>>     device-types/net/description.tex | 2 +-
>>>>>>>     1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/device-types/net/description.tex
>>>>>>> b/device-types/net/description.tex
>>>>>>> index aff5e08..529f470 100644
>>>>>>> --- a/device-types/net/description.tex
>>>>>>> +++ b/device-types/net/description.tex
>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
>>>>>>> / Network Device / Feature bits
>>>>>>>     \begin{description}
>>>>>>>     \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
>>>>>>> partial checksum offload.
>>>>>>>
>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
>>>>>>> partial checksum.
>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
>>>>>>> partial checksum or full checksum.
>>>>>> So patch 2 said
>>>>>>
>>>>>> "
>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
>>>>>> full checksum.
>>>>>>     \end{description}
>>>>>> "
>>>>>>
>>>>>> Is there any difference between the two "full checksum" here?
>>>>> There's no difference.
>>>>>
>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
>>>>> "can
>>>>> only" handle packets with full checksum.
>>>> This seems to be odd.
>>>>
>>>> Driver can always handle packet with full checksum, no?
>>> Yes.
>>>
>>>> I meant it
>>>> will be then to be functional equivalent to !
>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
>>> Are you referring to
>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
>> Sorry, this is a typo. I meant
>>
>> Are you referring to
>> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
>>
>>> If so, I think it's no.
>>>
>>> Maybe a description similar to the following would be more clearer:
>>>
>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
>>> packets with partial checksum.
> I may miss something here, but what's the difference between
>
> VIRTIO_NET_F_GUEST_FULL_CSUM
>
> and
>
> !VIRTIO_NET_F_GUEST_CSUM?

 From the device perspective:

If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full 
checksum to the driver,
but the device can not validate the checksum for these packets. That is, 
the flags in virtio-net-hdr
will not contain _DATA_VALID, and the driver or stack needs to validate 
these packets.

If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full 
checksum to the driver,
and the device can validate the checksum for these packets. That is, the 
flags in virtio-net-hdr
will contain _DATA_VALID, and the driver or stack does not need to 
validate these packets.

Thanks!

>
> Thanks
>
>>> Thanks!
>>>
>>>> Thanks
>>>>
>>>>> Thanks!
>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
>>>>>>>             reconfiguration support.
>>>>>>> --
>>>>>>> 2.19.1.6.gb485710b
>>>>>>>
>>>
>>> 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/


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Jason Wang]

On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>
>
>
> 在 2023/12/1 下午3:05, Jason Wang 写道:
> > On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >>
> >>
> >> 在 2023/12/1 下午2:24, Heng Qi 写道:
> >>>
> >>> 在 2023/12/1 下午1:18, Jason Wang 写道:
> >>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
> >>>> wrote:
> >>>>>
> >>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
> >>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
> >>>>>> wrote:
> >>>>>>> To prevent readers from misunderstanding that the driver can
> >>>>>>> only handles packets with partial checksum when
> >>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
> >>>>>>>
> >>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> >>>>>>> ---
> >>>>>>>     device-types/net/description.tex | 2 +-
> >>>>>>>     1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>>
> >>>>>>> diff --git a/device-types/net/description.tex
> >>>>>>> b/device-types/net/description.tex
> >>>>>>> index aff5e08..529f470 100644
> >>>>>>> --- a/device-types/net/description.tex
> >>>>>>> +++ b/device-types/net/description.tex
> >>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
> >>>>>>> / Network Device / Feature bits
> >>>>>>>     \begin{description}
> >>>>>>>     \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
> >>>>>>> partial checksum offload.
> >>>>>>>
> >>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> >>>>>>> partial checksum.
> >>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> >>>>>>> partial checksum or full checksum.
> >>>>>> So patch 2 said
> >>>>>>
> >>>>>> "
> >>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
> >>>>>> full checksum.
> >>>>>>     \end{description}
> >>>>>> "
> >>>>>>
> >>>>>> Is there any difference between the two "full checksum" here?
> >>>>> There's no difference.
> >>>>>
> >>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
> >>>>> "can
> >>>>> only" handle packets with full checksum.
> >>>> This seems to be odd.
> >>>>
> >>>> Driver can always handle packet with full checksum, no?
> >>> Yes.
> >>>
> >>>> I meant it
> >>>> will be then to be functional equivalent to !
> >>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
> >>> Are you referring to
> >>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
> >> Sorry, this is a typo. I meant
> >>
> >> Are you referring to
> >> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
> >>
> >>> If so, I think it's no.
> >>>
> >>> Maybe a description similar to the following would be more clearer:
> >>>
> >>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
> >>> packets with partial checksum.
> > I may miss something here, but what's the difference between
> >
> > VIRTIO_NET_F_GUEST_FULL_CSUM
> >
> > and
> >
> > !VIRTIO_NET_F_GUEST_CSUM?
>
>  From the device perspective:
>
> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
> checksum to the driver,
> but the device can not validate the checksum for these packets. That is,
> the flags in virtio-net-hdr
> will not contain _DATA_VALID, and the driver or stack needs to validate
> these packets.
>
> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
> checksum to the driver,
> and the device can validate the checksum for these packets. That is, the
> flags in virtio-net-hdr
> will contain _DATA_VALID,

I think DATA_VALID is optional here as device can't recognize all type
of protocols.

> and the driver or stack does not need to
> validate these packets.

Ok, so I think there're something that is subtle here, and that's why
I'm asking here:

1) "Driver does not handle packets with partial checksum" is not
accurate, !GUEST_CUSM also fit for this definition.
2) "Driver handles packets with full checksum" is kind of ambiguous as
it doesn't say whether or not the packet has been validated or not.

Thanks

>
> Thanks!
>
> >
> > Thanks
> >
> >>> Thanks!
> >>>
> >>>> Thanks
> >>>>
> >>>>> Thanks!
> >>>>>
> >>>>>> Thanks
> >>>>>>
> >>>>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
> >>>>>>>             reconfiguration support.
> >>>>>>> --
> >>>>>>> 2.19.1.6.gb485710b
> >>>>>>>
> >>>
> >>> 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/
>
>
> 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/
>


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Heng Qi]

在 2023/12/4 下午3:18, Jason Wang 写道:
> On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>
>>
>> 在 2023/12/1 下午3:05, Jason Wang 写道:
>>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>
>>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
>>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
>>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
>>>>>> wrote:
>>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
>>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>> wrote:
>>>>>>>>> To prevent readers from misunderstanding that the driver can
>>>>>>>>> only handles packets with partial checksum when
>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>> ---
>>>>>>>>>      device-types/net/description.tex | 2 +-
>>>>>>>>>      1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>>
>>>>>>>>> diff --git a/device-types/net/description.tex
>>>>>>>>> b/device-types/net/description.tex
>>>>>>>>> index aff5e08..529f470 100644
>>>>>>>>> --- a/device-types/net/description.tex
>>>>>>>>> +++ b/device-types/net/description.tex
>>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
>>>>>>>>> / Network Device / Feature bits
>>>>>>>>>      \begin{description}
>>>>>>>>>      \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
>>>>>>>>> partial checksum offload.
>>>>>>>>>
>>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
>>>>>>>>> partial checksum.
>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
>>>>>>>>> partial checksum or full checksum.
>>>>>>>> So patch 2 said
>>>>>>>>
>>>>>>>> "
>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
>>>>>>>> full checksum.
>>>>>>>>      \end{description}
>>>>>>>> "
>>>>>>>>
>>>>>>>> Is there any difference between the two "full checksum" here?
>>>>>>> There's no difference.
>>>>>>>
>>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
>>>>>>> "can
>>>>>>> only" handle packets with full checksum.
>>>>>> This seems to be odd.
>>>>>>
>>>>>> Driver can always handle packet with full checksum, no?
>>>>> Yes.
>>>>>
>>>>>> I meant it
>>>>>> will be then to be functional equivalent to !
>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
>>>>> Are you referring to
>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
>>>> Sorry, this is a typo. I meant
>>>>
>>>> Are you referring to
>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
>>>>
>>>>> If so, I think it's no.
>>>>>
>>>>> Maybe a description similar to the following would be more clearer:
>>>>>
>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
>>>>> packets with partial checksum.
>>> I may miss something here, but what's the difference between
>>>
>>> VIRTIO_NET_F_GUEST_FULL_CSUM
>>>
>>> and
>>>
>>> !VIRTIO_NET_F_GUEST_CSUM?
>>   From the device perspective:
>>
>> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
>> checksum to the driver,
>> but the device can not validate the checksum for these packets. That is,
>> the flags in virtio-net-hdr
>> will not contain _DATA_VALID, and the driver or stack needs to validate
>> these packets.
>>
>> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
>> checksum to the driver,
>> and the device can validate the checksum for these packets. That is, the
>> flags in virtio-net-hdr
>> will contain _DATA_VALID,
> I think DATA_VALID is optional here as device can't recognize all type
> of protocols.

Yes, you are right, so I used "device *can*" here. Which packet types 
the device recognizes or validates
depends on the device's implementation. This is also the current 
practice of GUEST_CSUM.

>
>> and the driver or stack does not need to
>> validate these packets.
> Ok, so I think there're something that is subtle here,

Ok, I see.

> and that's why
> I'm asking here:
>
> 1) "Driver does not handle packets with partial checksum" is not
> accurate, !GUEST_CUSM also fit for this definition.
> 2) "Driver handles packets with full checksum" is kind of ambiguous as
> it doesn't say whether or not the packet has been validated or not.

Maybe the description below would be less subtle?
+\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial 
checksum or full checksum.
+\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets 
with full checksum,
and the device optionally validates the packet's checksum.

Thanks!

>
> Thanks
>
>> Thanks!
>>
>>> Thanks
>>>
>>>>> Thanks!
>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
>>>>>>>>>              reconfiguration support.
>>>>>>>>> --
>>>>>>>>> 2.19.1.6.gb485710b
>>>>>>>>>
>>>>> 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/
>>
>> 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/
>>


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Jason Wang]

On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>
>
>
> 在 2023/12/4 下午3:18, Jason Wang 写道:
> > On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >>
> >>
> >> 在 2023/12/1 下午3:05, Jason Wang 写道:
> >>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >>>>
> >>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
> >>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
> >>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
> >>>>>> wrote:
> >>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
> >>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
> >>>>>>>> wrote:
> >>>>>>>>> To prevent readers from misunderstanding that the driver can
> >>>>>>>>> only handles packets with partial checksum when
> >>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> >>>>>>>>> ---
> >>>>>>>>>      device-types/net/description.tex | 2 +-
> >>>>>>>>>      1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>>>>
> >>>>>>>>> diff --git a/device-types/net/description.tex
> >>>>>>>>> b/device-types/net/description.tex
> >>>>>>>>> index aff5e08..529f470 100644
> >>>>>>>>> --- a/device-types/net/description.tex
> >>>>>>>>> +++ b/device-types/net/description.tex
> >>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
> >>>>>>>>> / Network Device / Feature bits
> >>>>>>>>>      \begin{description}
> >>>>>>>>>      \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
> >>>>>>>>> partial checksum offload.
> >>>>>>>>>
> >>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> >>>>>>>>> partial checksum.
> >>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> >>>>>>>>> partial checksum or full checksum.
> >>>>>>>> So patch 2 said
> >>>>>>>>
> >>>>>>>> "
> >>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
> >>>>>>>> full checksum.
> >>>>>>>>      \end{description}
> >>>>>>>> "
> >>>>>>>>
> >>>>>>>> Is there any difference between the two "full checksum" here?
> >>>>>>> There's no difference.
> >>>>>>>
> >>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
> >>>>>>> "can
> >>>>>>> only" handle packets with full checksum.
> >>>>>> This seems to be odd.
> >>>>>>
> >>>>>> Driver can always handle packet with full checksum, no?
> >>>>> Yes.
> >>>>>
> >>>>>> I meant it
> >>>>>> will be then to be functional equivalent to !
> >>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
> >>>>> Are you referring to
> >>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
> >>>> Sorry, this is a typo. I meant
> >>>>
> >>>> Are you referring to
> >>>> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
> >>>>
> >>>>> If so, I think it's no.
> >>>>>
> >>>>> Maybe a description similar to the following would be more clearer:
> >>>>>
> >>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
> >>>>> packets with partial checksum.
> >>> I may miss something here, but what's the difference between
> >>>
> >>> VIRTIO_NET_F_GUEST_FULL_CSUM
> >>>
> >>> and
> >>>
> >>> !VIRTIO_NET_F_GUEST_CSUM?
> >>   From the device perspective:
> >>
> >> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
> >> checksum to the driver,
> >> but the device can not validate the checksum for these packets. That is,
> >> the flags in virtio-net-hdr
> >> will not contain _DATA_VALID, and the driver or stack needs to validate
> >> these packets.
> >>
> >> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
> >> checksum to the driver,
> >> and the device can validate the checksum for these packets. That is, the
> >> flags in virtio-net-hdr
> >> will contain _DATA_VALID,
> > I think DATA_VALID is optional here as device can't recognize all type
> > of protocols.
>
> Yes, you are right, so I used "device *can*" here. Which packet types
> the device recognizes or validates
> depends on the device's implementation. This is also the current
> practice of GUEST_CSUM.
>
> >
> >> and the driver or stack does not need to
> >> validate these packets.
> > Ok, so I think there're something that is subtle here,
>
> Ok, I see.
>
> > and that's why
> > I'm asking here:
> >
> > 1) "Driver does not handle packets with partial checksum" is not
> > accurate, !GUEST_CUSM also fit for this definition.
> > 2) "Driver handles packets with full checksum" is kind of ambiguous as
> > it doesn't say whether or not the packet has been validated or not.
>
> Maybe the description below would be less subtle?
> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
> checksum or full checksum.

I'd suggest to leave it as is. As I didn't find any issue since even
with DATA_VALID. Did you?

> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
> with full checksum,
> and the device optionally validates the packet's checksum.

Or maybe something like (not a native speaker)

The driver handles packets with full checksum which the device has
already validated.

Thanks


>
> Thanks!
>
> >
> > Thanks
> >
> >> Thanks!
> >>
> >>> Thanks
> >>>
> >>>>> Thanks!
> >>>>>
> >>>>>> Thanks
> >>>>>>
> >>>>>>> Thanks!
> >>>>>>>
> >>>>>>>> Thanks
> >>>>>>>>
> >>>>>>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
> >>>>>>>>>              reconfiguration support.
> >>>>>>>>> --
> >>>>>>>>> 2.19.1.6.gb485710b
> >>>>>>>>>
> >>>>> 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/
> >>
> >> 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/
> >>
>
>
> 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/
>


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Michael S. Tsirkin]

On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
> On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >
> >
> >
> > 在 2023/12/4 下午3:18, Jason Wang 写道:
> > > On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > >>
> > >>
> > >> 在 2023/12/1 下午3:05, Jason Wang 写道:
> > >>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > >>>>
> > >>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
> > >>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
> > >>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
> > >>>>>> wrote:
> > >>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
> > >>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
> > >>>>>>>> wrote:
> > >>>>>>>>> To prevent readers from misunderstanding that the driver can
> > >>>>>>>>> only handles packets with partial checksum when
> > >>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
> > >>>>>>>>>
> > >>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> > >>>>>>>>> ---
> > >>>>>>>>>      device-types/net/description.tex | 2 +-
> > >>>>>>>>>      1 file changed, 1 insertion(+), 1 deletion(-)
> > >>>>>>>>>
> > >>>>>>>>> diff --git a/device-types/net/description.tex
> > >>>>>>>>> b/device-types/net/description.tex
> > >>>>>>>>> index aff5e08..529f470 100644
> > >>>>>>>>> --- a/device-types/net/description.tex
> > >>>>>>>>> +++ b/device-types/net/description.tex
> > >>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
> > >>>>>>>>> / Network Device / Feature bits
> > >>>>>>>>>      \begin{description}
> > >>>>>>>>>      \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
> > >>>>>>>>> partial checksum offload.
> > >>>>>>>>>
> > >>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> > >>>>>>>>> partial checksum.
> > >>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> > >>>>>>>>> partial checksum or full checksum.
> > >>>>>>>> So patch 2 said
> > >>>>>>>>
> > >>>>>>>> "
> > >>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
> > >>>>>>>> full checksum.
> > >>>>>>>>      \end{description}
> > >>>>>>>> "
> > >>>>>>>>
> > >>>>>>>> Is there any difference between the two "full checksum" here?
> > >>>>>>> There's no difference.
> > >>>>>>>
> > >>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
> > >>>>>>> "can
> > >>>>>>> only" handle packets with full checksum.
> > >>>>>> This seems to be odd.
> > >>>>>>
> > >>>>>> Driver can always handle packet with full checksum, no?
> > >>>>> Yes.
> > >>>>>
> > >>>>>> I meant it
> > >>>>>> will be then to be functional equivalent to !
> > >>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
> > >>>>> Are you referring to
> > >>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
> > >>>> Sorry, this is a typo. I meant
> > >>>>
> > >>>> Are you referring to
> > >>>> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
> > >>>>
> > >>>>> If so, I think it's no.
> > >>>>>
> > >>>>> Maybe a description similar to the following would be more clearer:
> > >>>>>
> > >>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
> > >>>>> packets with partial checksum.
> > >>> I may miss something here, but what's the difference between
> > >>>
> > >>> VIRTIO_NET_F_GUEST_FULL_CSUM
> > >>>
> > >>> and
> > >>>
> > >>> !VIRTIO_NET_F_GUEST_CSUM?
> > >>   From the device perspective:
> > >>
> > >> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
> > >> checksum to the driver,
> > >> but the device can not validate the checksum for these packets. That is,
> > >> the flags in virtio-net-hdr
> > >> will not contain _DATA_VALID, and the driver or stack needs to validate
> > >> these packets.
> > >>
> > >> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
> > >> checksum to the driver,
> > >> and the device can validate the checksum for these packets. That is, the
> > >> flags in virtio-net-hdr
> > >> will contain _DATA_VALID,
> > > I think DATA_VALID is optional here as device can't recognize all type
> > > of protocols.
> >
> > Yes, you are right, so I used "device *can*" here. Which packet types
> > the device recognizes or validates
> > depends on the device's implementation. This is also the current
> > practice of GUEST_CSUM.
> >
> > >
> > >> and the driver or stack does not need to
> > >> validate these packets.
> > > Ok, so I think there're something that is subtle here,
> >
> > Ok, I see.
> >
> > > and that's why
> > > I'm asking here:
> > >
> > > 1) "Driver does not handle packets with partial checksum" is not
> > > accurate, !GUEST_CUSM also fit for this definition.
> > > 2) "Driver handles packets with full checksum" is kind of ambiguous as
> > > it doesn't say whether or not the packet has been validated or not.
> >
> > Maybe the description below would be less subtle?
> > +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
> > checksum or full checksum.
> 
> I'd suggest to leave it as is. As I didn't find any issue since even
> with DATA_VALID. Did you?
> 
> > +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
> > with full checksum,
> > and the device optionally validates the packet's checksum.
> 
> Or maybe something like (not a native speaker)
> 
> The driver handles packets with full checksum which the device has
> already validated.
> 
> Thanks

I feel we just need a proper definition of what does "full checksum"
mean in this context. It is used but not defined.
Assume this feature was negotiated.
My understanding is that this is just like VIRTIO_NET_F_GUEST_CSUM
but certain values in the header are then disallowed? Which?
This should be in the spec.

After this is written up we will come up with a good short
description for the feature bit.


> 
> >
> > Thanks!
> >
> > >
> > > Thanks
> > >
> > >> Thanks!
> > >>
> > >>> Thanks
> > >>>
> > >>>>> Thanks!
> > >>>>>
> > >>>>>> Thanks
> > >>>>>>
> > >>>>>>> Thanks!
> > >>>>>>>
> > >>>>>>>> Thanks
> > >>>>>>>>
> > >>>>>>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
> > >>>>>>>>>              reconfiguration support.
> > >>>>>>>>> --
> > >>>>>>>>> 2.19.1.6.gb485710b
> > >>>>>>>>>
> > >>>>> 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/
> > >>
> > >> 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/
> > >>
> >
> >
> > 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/
> >


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Jason Wang]

On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
> > On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > >
> > >
> > >
> > > 在 2023/12/4 下午3:18, Jason Wang 写道:
> > > > On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > >>
> > > >>
> > > >> 在 2023/12/1 下午3:05, Jason Wang 写道:
> > > >>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > >>>>
> > > >>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
> > > >>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
> > > >>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
> > > >>>>>> wrote:
> > > >>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
> > > >>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
> > > >>>>>>>> wrote:
> > > >>>>>>>>> To prevent readers from misunderstanding that the driver can
> > > >>>>>>>>> only handles packets with partial checksum when
> > > >>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
> > > >>>>>>>>>
> > > >>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> > > >>>>>>>>> ---
> > > >>>>>>>>>      device-types/net/description.tex | 2 +-
> > > >>>>>>>>>      1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>>>>>>>>
> > > >>>>>>>>> diff --git a/device-types/net/description.tex
> > > >>>>>>>>> b/device-types/net/description.tex
> > > >>>>>>>>> index aff5e08..529f470 100644
> > > >>>>>>>>> --- a/device-types/net/description.tex
> > > >>>>>>>>> +++ b/device-types/net/description.tex
> > > >>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
> > > >>>>>>>>> / Network Device / Feature bits
> > > >>>>>>>>>      \begin{description}
> > > >>>>>>>>>      \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
> > > >>>>>>>>> partial checksum offload.
> > > >>>>>>>>>
> > > >>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> > > >>>>>>>>> partial checksum.
> > > >>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> > > >>>>>>>>> partial checksum or full checksum.
> > > >>>>>>>> So patch 2 said
> > > >>>>>>>>
> > > >>>>>>>> "
> > > >>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
> > > >>>>>>>> full checksum.
> > > >>>>>>>>      \end{description}
> > > >>>>>>>> "
> > > >>>>>>>>
> > > >>>>>>>> Is there any difference between the two "full checksum" here?
> > > >>>>>>> There's no difference.
> > > >>>>>>>
> > > >>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
> > > >>>>>>> "can
> > > >>>>>>> only" handle packets with full checksum.
> > > >>>>>> This seems to be odd.
> > > >>>>>>
> > > >>>>>> Driver can always handle packet with full checksum, no?
> > > >>>>> Yes.
> > > >>>>>
> > > >>>>>> I meant it
> > > >>>>>> will be then to be functional equivalent to !
> > > >>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
> > > >>>>> Are you referring to
> > > >>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
> > > >>>> Sorry, this is a typo. I meant
> > > >>>>
> > > >>>> Are you referring to
> > > >>>> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
> > > >>>>
> > > >>>>> If so, I think it's no.
> > > >>>>>
> > > >>>>> Maybe a description similar to the following would be more clearer:
> > > >>>>>
> > > >>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
> > > >>>>> packets with partial checksum.
> > > >>> I may miss something here, but what's the difference between
> > > >>>
> > > >>> VIRTIO_NET_F_GUEST_FULL_CSUM
> > > >>>
> > > >>> and
> > > >>>
> > > >>> !VIRTIO_NET_F_GUEST_CSUM?
> > > >>   From the device perspective:
> > > >>
> > > >> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
> > > >> checksum to the driver,
> > > >> but the device can not validate the checksum for these packets. That is,
> > > >> the flags in virtio-net-hdr
> > > >> will not contain _DATA_VALID, and the driver or stack needs to validate
> > > >> these packets.
> > > >>
> > > >> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
> > > >> checksum to the driver,
> > > >> and the device can validate the checksum for these packets. That is, the
> > > >> flags in virtio-net-hdr
> > > >> will contain _DATA_VALID,
> > > > I think DATA_VALID is optional here as device can't recognize all type
> > > > of protocols.
> > >
> > > Yes, you are right, so I used "device *can*" here. Which packet types
> > > the device recognizes or validates
> > > depends on the device's implementation. This is also the current
> > > practice of GUEST_CSUM.
> > >
> > > >
> > > >> and the driver or stack does not need to
> > > >> validate these packets.
> > > > Ok, so I think there're something that is subtle here,
> > >
> > > Ok, I see.
> > >
> > > > and that's why
> > > > I'm asking here:
> > > >
> > > > 1) "Driver does not handle packets with partial checksum" is not
> > > > accurate, !GUEST_CUSM also fit for this definition.
> > > > 2) "Driver handles packets with full checksum" is kind of ambiguous as
> > > > it doesn't say whether or not the packet has been validated or not.
> > >
> > > Maybe the description below would be less subtle?
> > > +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
> > > checksum or full checksum.
> >
> > I'd suggest to leave it as is. As I didn't find any issue since even
> > with DATA_VALID. Did you?
> >
> > > +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
> > > with full checksum,
> > > and the device optionally validates the packet's checksum.
> >
> > Or maybe something like (not a native speaker)
> >
> > The driver handles packets with full checksum which the device has
> > already validated.
> >
> > Thanks
>
> I feel we just need a proper definition of what does "full checksum"
> mean in this context. It is used but not defined.
> Assume this feature was negotiated.
> My understanding is that this is just like VIRTIO_NET_F_GUEST_CSUM
> but certain values in the header are then disallowed? Which?
> This should be in the spec.

Yes, I think it is probably the headers that DATA_VALID can work. We
never define it in the past.

E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY, but it can
only work for some specific protocols:

"""
 *   %CHECKSUM_UNNECESSARY is applicable to following protocols:
 *
 *     - TCP: IPv6 and IPv4.
 *     - UDP: IPv4 and IPv6. A device may apply CHECKSUM_UNNECESSARY to a
 *       zero UDP checksum for either IPv4 or IPv6, the networking stack
 *       may perform further validation in this case.
 *     - GRE: only if the checksum is present in the header.
 *     - SCTP: indicates the CRC in SCTP header has been validated.
 *     - FCOE: indicates the CRC in FC frame has been validated.
"""

I'm not sure whether it's just fine to duplicate the definition or
it's too late to define any now.

>
> After this is written up we will come up with a good short
> description for the feature bit.
>

Thanks

>
> >
> > >
> > > Thanks!
> > >
> > > >
> > > > Thanks
> > > >
> > > >> Thanks!
> > > >>
> > > >>> Thanks
> > > >>>
> > > >>>>> Thanks!
> > > >>>>>
> > > >>>>>> Thanks
> > > >>>>>>
> > > >>>>>>> Thanks!
> > > >>>>>>>
> > > >>>>>>>> Thanks
> > > >>>>>>>>
> > > >>>>>>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
> > > >>>>>>>>>              reconfiguration support.
> > > >>>>>>>>> --
> > > >>>>>>>>> 2.19.1.6.gb485710b
> > > >>>>>>>>>
> > > >>>>> 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/
> > > >>
> > > >> 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/
> > > >>
> > >
> > >
> > > 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/
> > >
>


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Michael S. Tsirkin]

On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
> On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
> > > On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > >
> > > >
> > > >
> > > > 在 2023/12/4 下午3:18, Jason Wang 写道:
> > > > > On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > > >>
> > > > >>
> > > > >> 在 2023/12/1 下午3:05, Jason Wang 写道:
> > > > >>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > > >>>>
> > > > >>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
> > > > >>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
> > > > >>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
> > > > >>>>>> wrote:
> > > > >>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
> > > > >>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
> > > > >>>>>>>> wrote:
> > > > >>>>>>>>> To prevent readers from misunderstanding that the driver can
> > > > >>>>>>>>> only handles packets with partial checksum when
> > > > >>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
> > > > >>>>>>>>>
> > > > >>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> > > > >>>>>>>>> ---
> > > > >>>>>>>>>      device-types/net/description.tex | 2 +-
> > > > >>>>>>>>>      1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >>>>>>>>>
> > > > >>>>>>>>> diff --git a/device-types/net/description.tex
> > > > >>>>>>>>> b/device-types/net/description.tex
> > > > >>>>>>>>> index aff5e08..529f470 100644
> > > > >>>>>>>>> --- a/device-types/net/description.tex
> > > > >>>>>>>>> +++ b/device-types/net/description.tex
> > > > >>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
> > > > >>>>>>>>> / Network Device / Feature bits
> > > > >>>>>>>>>      \begin{description}
> > > > >>>>>>>>>      \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
> > > > >>>>>>>>> partial checksum offload.
> > > > >>>>>>>>>
> > > > >>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> > > > >>>>>>>>> partial checksum.
> > > > >>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> > > > >>>>>>>>> partial checksum or full checksum.
> > > > >>>>>>>> So patch 2 said
> > > > >>>>>>>>
> > > > >>>>>>>> "
> > > > >>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
> > > > >>>>>>>> full checksum.
> > > > >>>>>>>>      \end{description}
> > > > >>>>>>>> "
> > > > >>>>>>>>
> > > > >>>>>>>> Is there any difference between the two "full checksum" here?
> > > > >>>>>>> There's no difference.
> > > > >>>>>>>
> > > > >>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
> > > > >>>>>>> "can
> > > > >>>>>>> only" handle packets with full checksum.
> > > > >>>>>> This seems to be odd.
> > > > >>>>>>
> > > > >>>>>> Driver can always handle packet with full checksum, no?
> > > > >>>>> Yes.
> > > > >>>>>
> > > > >>>>>> I meant it
> > > > >>>>>> will be then to be functional equivalent to !
> > > > >>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
> > > > >>>>> Are you referring to
> > > > >>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
> > > > >>>> Sorry, this is a typo. I meant
> > > > >>>>
> > > > >>>> Are you referring to
> > > > >>>> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
> > > > >>>>
> > > > >>>>> If so, I think it's no.
> > > > >>>>>
> > > > >>>>> Maybe a description similar to the following would be more clearer:
> > > > >>>>>
> > > > >>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
> > > > >>>>> packets with partial checksum.
> > > > >>> I may miss something here, but what's the difference between
> > > > >>>
> > > > >>> VIRTIO_NET_F_GUEST_FULL_CSUM
> > > > >>>
> > > > >>> and
> > > > >>>
> > > > >>> !VIRTIO_NET_F_GUEST_CSUM?
> > > > >>   From the device perspective:
> > > > >>
> > > > >> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
> > > > >> checksum to the driver,
> > > > >> but the device can not validate the checksum for these packets. That is,
> > > > >> the flags in virtio-net-hdr
> > > > >> will not contain _DATA_VALID, and the driver or stack needs to validate
> > > > >> these packets.
> > > > >>
> > > > >> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
> > > > >> checksum to the driver,
> > > > >> and the device can validate the checksum for these packets. That is, the
> > > > >> flags in virtio-net-hdr
> > > > >> will contain _DATA_VALID,
> > > > > I think DATA_VALID is optional here as device can't recognize all type
> > > > > of protocols.
> > > >
> > > > Yes, you are right, so I used "device *can*" here. Which packet types
> > > > the device recognizes or validates
> > > > depends on the device's implementation. This is also the current
> > > > practice of GUEST_CSUM.
> > > >
> > > > >
> > > > >> and the driver or stack does not need to
> > > > >> validate these packets.
> > > > > Ok, so I think there're something that is subtle here,
> > > >
> > > > Ok, I see.
> > > >
> > > > > and that's why
> > > > > I'm asking here:
> > > > >
> > > > > 1) "Driver does not handle packets with partial checksum" is not
> > > > > accurate, !GUEST_CUSM also fit for this definition.
> > > > > 2) "Driver handles packets with full checksum" is kind of ambiguous as
> > > > > it doesn't say whether or not the packet has been validated or not.
> > > >
> > > > Maybe the description below would be less subtle?
> > > > +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
> > > > checksum or full checksum.
> > >
> > > I'd suggest to leave it as is. As I didn't find any issue since even
> > > with DATA_VALID. Did you?
> > >
> > > > +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
> > > > with full checksum,
> > > > and the device optionally validates the packet's checksum.
> > >
> > > Or maybe something like (not a native speaker)
> > >
> > > The driver handles packets with full checksum which the device has
> > > already validated.
> > >
> > > Thanks
> >
> > I feel we just need a proper definition of what does "full checksum"
> > mean in this context. It is used but not defined.
> > Assume this feature was negotiated.
> > My understanding is that this is just like VIRTIO_NET_F_GUEST_CSUM
> > but certain values in the header are then disallowed? Which?
> > This should be in the spec.
> 
> Yes, I think it is probably the headers that DATA_VALID can work. We
> never define it in the past.
> 
> E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY, but it can
> only work for some specific protocols:
> 
> """
>  *   %CHECKSUM_UNNECESSARY is applicable to following protocols:
>  *
>  *     - TCP: IPv6 and IPv4.
>  *     - UDP: IPv4 and IPv6. A device may apply CHECKSUM_UNNECESSARY to a
>  *       zero UDP checksum for either IPv4 or IPv6, the networking stack
>  *       may perform further validation in this case.
>  *     - GRE: only if the checksum is present in the header.
>  *     - SCTP: indicates the CRC in SCTP header has been validated.
>  *     - FCOE: indicates the CRC in FC frame has been validated.
> """
> 
> I'm not sure whether it's just fine to duplicate the definition or
> it's too late to define any now.

I think it's mostly harmless for other protocols.

> >
> > After this is written up we will come up with a good short
> > description for the feature bit.
> >
> 
> Thanks
> 
> >
> > >
> > > >
> > > > Thanks!
> > > >
> > > > >
> > > > > Thanks
> > > > >
> > > > >> Thanks!
> > > > >>
> > > > >>> Thanks
> > > > >>>
> > > > >>>>> Thanks!
> > > > >>>>>
> > > > >>>>>> Thanks
> > > > >>>>>>
> > > > >>>>>>> Thanks!
> > > > >>>>>>>
> > > > >>>>>>>> Thanks
> > > > >>>>>>>>
> > > > >>>>>>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
> > > > >>>>>>>>>              reconfiguration support.
> > > > >>>>>>>>> --
> > > > >>>>>>>>> 2.19.1.6.gb485710b
> > > > >>>>>>>>>
> > > > >>>>> 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/
> > > > >>
> > > > >> 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/
> > > > >>
> > > >
> > > >
> > > > 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/
> > > >
> >


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Heng Qi]

在 2023/12/4 下午4:49, Jason Wang 写道:
> On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>
>>
>> 在 2023/12/4 下午3:18, Jason Wang 写道:
>>> On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>
>>>> 在 2023/12/1 下午3:05, Jason Wang 写道:
>>>>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
>>>>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
>>>>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>> wrote:
>>>>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
>>>>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> To prevent readers from misunderstanding that the driver can
>>>>>>>>>>> only handles packets with partial checksum when
>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>>>> ---
>>>>>>>>>>>       device-types/net/description.tex | 2 +-
>>>>>>>>>>>       1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/device-types/net/description.tex
>>>>>>>>>>> b/device-types/net/description.tex
>>>>>>>>>>> index aff5e08..529f470 100644
>>>>>>>>>>> --- a/device-types/net/description.tex
>>>>>>>>>>> +++ b/device-types/net/description.tex
>>>>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
>>>>>>>>>>> / Network Device / Feature bits
>>>>>>>>>>>       \begin{description}
>>>>>>>>>>>       \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
>>>>>>>>>>> partial checksum offload.
>>>>>>>>>>>
>>>>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
>>>>>>>>>>> partial checksum.
>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
>>>>>>>>>>> partial checksum or full checksum.
>>>>>>>>>> So patch 2 said
>>>>>>>>>>
>>>>>>>>>> "
>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
>>>>>>>>>> full checksum.
>>>>>>>>>>       \end{description}
>>>>>>>>>> "
>>>>>>>>>>
>>>>>>>>>> Is there any difference between the two "full checksum" here?
>>>>>>>>> There's no difference.
>>>>>>>>>
>>>>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
>>>>>>>>> "can
>>>>>>>>> only" handle packets with full checksum.
>>>>>>>> This seems to be odd.
>>>>>>>>
>>>>>>>> Driver can always handle packet with full checksum, no?
>>>>>>> Yes.
>>>>>>>
>>>>>>>> I meant it
>>>>>>>> will be then to be functional equivalent to !
>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
>>>>>>> Are you referring to
>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
>>>>>> Sorry, this is a typo. I meant
>>>>>>
>>>>>> Are you referring to
>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
>>>>>>
>>>>>>> If so, I think it's no.
>>>>>>>
>>>>>>> Maybe a description similar to the following would be more clearer:
>>>>>>>
>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
>>>>>>> packets with partial checksum.
>>>>> I may miss something here, but what's the difference between
>>>>>
>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM
>>>>>
>>>>> and
>>>>>
>>>>> !VIRTIO_NET_F_GUEST_CSUM?
>>>>    From the device perspective:
>>>>
>>>> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
>>>> checksum to the driver,
>>>> but the device can not validate the checksum for these packets. That is,
>>>> the flags in virtio-net-hdr
>>>> will not contain _DATA_VALID, and the driver or stack needs to validate
>>>> these packets.
>>>>
>>>> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
>>>> checksum to the driver,
>>>> and the device can validate the checksum for these packets. That is, the
>>>> flags in virtio-net-hdr
>>>> will contain _DATA_VALID,
>>> I think DATA_VALID is optional here as device can't recognize all type
>>> of protocols.
>> Yes, you are right, so I used "device *can*" here. Which packet types
>> the device recognizes or validates
>> depends on the device's implementation. This is also the current
>> practice of GUEST_CSUM.
>>
>>>> and the driver or stack does not need to
>>>> validate these packets.
>>> Ok, so I think there're something that is subtle here,
>> Ok, I see.
>>
>>> and that's why
>>> I'm asking here:
>>>
>>> 1) "Driver does not handle packets with partial checksum" is not
>>> accurate, !GUEST_CUSM also fit for this definition.
>>> 2) "Driver handles packets with full checksum" is kind of ambiguous as
>>> it doesn't say whether or not the packet has been validated or not.
>> Maybe the description below would be less subtle?
>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
>> checksum or full checksum.
> I'd suggest to leave it as is. As I didn't find any issue since even
> with DATA_VALID.

OK, I'm not inclined to update the description for classic features 
either, if that's okay with others.

> Did you?
>
>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
>> with full checksum,
>> and the device optionally validates the packet's checksum.
> Or maybe something like (not a native speaker)
>
> The driver handles packets with full checksum which the device has
> already validated.

Packets which are not validated by the device can still be received by 
the driver. This is basic
and this feature does not break this.

Thanks!

>
> Thanks
>
>
>> Thanks!
>>
>>> Thanks
>>>
>>>> Thanks!
>>>>
>>>>> Thanks
>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
>>>>>>>>>>>               reconfiguration support.
>>>>>>>>>>> --
>>>>>>>>>>> 2.19.1.6.gb485710b
>>>>>>>>>>>
>>>>>>> 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/
>>>> 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/
>>>>
>>
>> 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/
>>


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Jason Wang]

On Mon, Dec 4, 2023 at 5:06 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>
>
>
> 在 2023/12/4 下午4:49, Jason Wang 写道:
> > On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >>
> >>
> >> 在 2023/12/4 下午3:18, Jason Wang 写道:
> >>> On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >>>>
> >>>> 在 2023/12/1 下午3:05, Jason Wang 写道:
> >>>>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >>>>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
> >>>>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
> >>>>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
> >>>>>>>> wrote:
> >>>>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
> >>>>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>> To prevent readers from misunderstanding that the driver can
> >>>>>>>>>>> only handles packets with partial checksum when
> >>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
> >>>>>>>>>>>
> >>>>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> >>>>>>>>>>> ---
> >>>>>>>>>>>       device-types/net/description.tex | 2 +-
> >>>>>>>>>>>       1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>>>>>>
> >>>>>>>>>>> diff --git a/device-types/net/description.tex
> >>>>>>>>>>> b/device-types/net/description.tex
> >>>>>>>>>>> index aff5e08..529f470 100644
> >>>>>>>>>>> --- a/device-types/net/description.tex
> >>>>>>>>>>> +++ b/device-types/net/description.tex
> >>>>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
> >>>>>>>>>>> / Network Device / Feature bits
> >>>>>>>>>>>       \begin{description}
> >>>>>>>>>>>       \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
> >>>>>>>>>>> partial checksum offload.
> >>>>>>>>>>>
> >>>>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> >>>>>>>>>>> partial checksum.
> >>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> >>>>>>>>>>> partial checksum or full checksum.
> >>>>>>>>>> So patch 2 said
> >>>>>>>>>>
> >>>>>>>>>> "
> >>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
> >>>>>>>>>> full checksum.
> >>>>>>>>>>       \end{description}
> >>>>>>>>>> "
> >>>>>>>>>>
> >>>>>>>>>> Is there any difference between the two "full checksum" here?
> >>>>>>>>> There's no difference.
> >>>>>>>>>
> >>>>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
> >>>>>>>>> "can
> >>>>>>>>> only" handle packets with full checksum.
> >>>>>>>> This seems to be odd.
> >>>>>>>>
> >>>>>>>> Driver can always handle packet with full checksum, no?
> >>>>>>> Yes.
> >>>>>>>
> >>>>>>>> I meant it
> >>>>>>>> will be then to be functional equivalent to !
> >>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
> >>>>>>> Are you referring to
> >>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
> >>>>>> Sorry, this is a typo. I meant
> >>>>>>
> >>>>>> Are you referring to
> >>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
> >>>>>>
> >>>>>>> If so, I think it's no.
> >>>>>>>
> >>>>>>> Maybe a description similar to the following would be more clearer:
> >>>>>>>
> >>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
> >>>>>>> packets with partial checksum.
> >>>>> I may miss something here, but what's the difference between
> >>>>>
> >>>>> VIRTIO_NET_F_GUEST_FULL_CSUM
> >>>>>
> >>>>> and
> >>>>>
> >>>>> !VIRTIO_NET_F_GUEST_CSUM?
> >>>>    From the device perspective:
> >>>>
> >>>> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
> >>>> checksum to the driver,
> >>>> but the device can not validate the checksum for these packets. That is,
> >>>> the flags in virtio-net-hdr
> >>>> will not contain _DATA_VALID, and the driver or stack needs to validate
> >>>> these packets.
> >>>>
> >>>> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
> >>>> checksum to the driver,
> >>>> and the device can validate the checksum for these packets. That is, the
> >>>> flags in virtio-net-hdr
> >>>> will contain _DATA_VALID,
> >>> I think DATA_VALID is optional here as device can't recognize all type
> >>> of protocols.
> >> Yes, you are right, so I used "device *can*" here. Which packet types
> >> the device recognizes or validates
> >> depends on the device's implementation. This is also the current
> >> practice of GUEST_CSUM.
> >>
> >>>> and the driver or stack does not need to
> >>>> validate these packets.
> >>> Ok, so I think there're something that is subtle here,
> >> Ok, I see.
> >>
> >>> and that's why
> >>> I'm asking here:
> >>>
> >>> 1) "Driver does not handle packets with partial checksum" is not
> >>> accurate, !GUEST_CUSM also fit for this definition.
> >>> 2) "Driver handles packets with full checksum" is kind of ambiguous as
> >>> it doesn't say whether or not the packet has been validated or not.
> >> Maybe the description below would be less subtle?
> >> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
> >> checksum or full checksum.
> > I'd suggest to leave it as is. As I didn't find any issue since even
> > with DATA_VALID.
>
> OK, I'm not inclined to update the description for classic features
> either, if that's okay with others.
>
> > Did you?
> >
> >> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
> >> with full checksum,
> >> and the device optionally validates the packet's checksum.
> > Or maybe something like (not a native speaker)
> >
> > The driver handles packets with full checksum which the device has
> > already validated.
>
> Packets which are not validated by the device can still be received by
> the driver. This is basic
> and this feature does not break this.

It doesn't break. It doesn't exclude that.

See how GUEST_CSUM defined:

Driver handles packets with partial checksum.

Thanks

>
> Thanks!
>
> >
> > Thanks
> >
> >
> >> Thanks!
> >>
> >>> Thanks
> >>>
> >>>> Thanks!
> >>>>
> >>>>> Thanks
> >>>>>
> >>>>>>> Thanks!
> >>>>>>>
> >>>>>>>> Thanks
> >>>>>>>>
> >>>>>>>>> Thanks!
> >>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>>>
> >>>>>>>>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
> >>>>>>>>>>>               reconfiguration support.
> >>>>>>>>>>> --
> >>>>>>>>>>> 2.19.1.6.gb485710b
> >>>>>>>>>>>
> >>>>>>> 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/
> >>>> 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/
> >>>>
> >>
> >> 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/
> >>
>


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Heng Qi]

在 2023/12/4 下午5:05, Michael S. Tsirkin 写道:
> On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
>> On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>>> On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
>>>> On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>>
>>>>>
>>>>> 在 2023/12/4 下午3:18, Jason Wang 写道:
>>>>>> On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>>>>
>>>>>>> 在 2023/12/1 下午3:05, Jason Wang 写道:
>>>>>>>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>>>>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
>>>>>>>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
>>>>>>>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
>>>>>>>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> To prevent readers from misunderstanding that the driver can
>>>>>>>>>>>>>> only handles packets with partial checksum when
>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>       device-types/net/description.tex | 2 +-
>>>>>>>>>>>>>>       1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git a/device-types/net/description.tex
>>>>>>>>>>>>>> b/device-types/net/description.tex
>>>>>>>>>>>>>> index aff5e08..529f470 100644
>>>>>>>>>>>>>> --- a/device-types/net/description.tex
>>>>>>>>>>>>>> +++ b/device-types/net/description.tex
>>>>>>>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
>>>>>>>>>>>>>> / Network Device / Feature bits
>>>>>>>>>>>>>>       \begin{description}
>>>>>>>>>>>>>>       \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
>>>>>>>>>>>>>> partial checksum offload.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
>>>>>>>>>>>>>> partial checksum.
>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
>>>>>>>>>>>>>> partial checksum or full checksum.
>>>>>>>>>>>>> So patch 2 said
>>>>>>>>>>>>>
>>>>>>>>>>>>> "
>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
>>>>>>>>>>>>> full checksum.
>>>>>>>>>>>>>       \end{description}
>>>>>>>>>>>>> "
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is there any difference between the two "full checksum" here?
>>>>>>>>>>>> There's no difference.
>>>>>>>>>>>>
>>>>>>>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
>>>>>>>>>>>> "can
>>>>>>>>>>>> only" handle packets with full checksum.
>>>>>>>>>>> This seems to be odd.
>>>>>>>>>>>
>>>>>>>>>>> Driver can always handle packet with full checksum, no?
>>>>>>>>>> Yes.
>>>>>>>>>>
>>>>>>>>>>> I meant it
>>>>>>>>>>> will be then to be functional equivalent to !
>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
>>>>>>>>>> Are you referring to
>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
>>>>>>>>> Sorry, this is a typo. I meant
>>>>>>>>>
>>>>>>>>> Are you referring to
>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
>>>>>>>>>
>>>>>>>>>> If so, I think it's no.
>>>>>>>>>>
>>>>>>>>>> Maybe a description similar to the following would be more clearer:
>>>>>>>>>>
>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
>>>>>>>>>> packets with partial checksum.
>>>>>>>> I may miss something here, but what's the difference between
>>>>>>>>
>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM
>>>>>>>>
>>>>>>>> and
>>>>>>>>
>>>>>>>> !VIRTIO_NET_F_GUEST_CSUM?
>>>>>>>    From the device perspective:
>>>>>>>
>>>>>>> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
>>>>>>> checksum to the driver,
>>>>>>> but the device can not validate the checksum for these packets. That is,
>>>>>>> the flags in virtio-net-hdr
>>>>>>> will not contain _DATA_VALID, and the driver or stack needs to validate
>>>>>>> these packets.
>>>>>>>
>>>>>>> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
>>>>>>> checksum to the driver,
>>>>>>> and the device can validate the checksum for these packets. That is, the
>>>>>>> flags in virtio-net-hdr
>>>>>>> will contain _DATA_VALID,
>>>>>> I think DATA_VALID is optional here as device can't recognize all type
>>>>>> of protocols.
>>>>> Yes, you are right, so I used "device *can*" here. Which packet types
>>>>> the device recognizes or validates
>>>>> depends on the device's implementation. This is also the current
>>>>> practice of GUEST_CSUM.
>>>>>
>>>>>>> and the driver or stack does not need to
>>>>>>> validate these packets.
>>>>>> Ok, so I think there're something that is subtle here,
>>>>> Ok, I see.
>>>>>
>>>>>> and that's why
>>>>>> I'm asking here:
>>>>>>
>>>>>> 1) "Driver does not handle packets with partial checksum" is not
>>>>>> accurate, !GUEST_CUSM also fit for this definition.
>>>>>> 2) "Driver handles packets with full checksum" is kind of ambiguous as
>>>>>> it doesn't say whether or not the packet has been validated or not.
>>>>> Maybe the description below would be less subtle?
>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
>>>>> checksum or full checksum.
>>>> I'd suggest to leave it as is. As I didn't find any issue since even
>>>> with DATA_VALID. Did you?
>>>>
>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
>>>>> with full checksum,
>>>>> and the device optionally validates the packet's checksum.
>>>> Or maybe something like (not a native speaker)
>>>>
>>>> The driver handles packets with full checksum which the device has
>>>> already validated.
>>>>
>>>> Thanks
>>> I feel we just need a proper definition of what does "full checksum"
>>> mean in this context. It is used but not defined.
>>> Assume this feature was negotiated.
>>> My understanding is that this is just like VIRTIO_NET_F_GUEST_CSUM
>>> but certain values in the header are then disallowed? Which?
>>> This should be in the spec.
>> Yes, I think it is probably the headers that DATA_VALID can work. We
>> never define it in the past.
>>
>> E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY, but it can
>> only work for some specific protocols:
>>
>> """
>>   *   %CHECKSUM_UNNECESSARY is applicable to following protocols:
>>   *
>>   *     - TCP: IPv6 and IPv4.
>>   *     - UDP: IPv4 and IPv6. A device may apply CHECKSUM_UNNECESSARY to a
>>   *       zero UDP checksum for either IPv4 or IPv6, the networking stack
>>   *       may perform further validation in this case.
>>   *     - GRE: only if the checksum is present in the header.
>>   *     - SCTP: indicates the CRC in SCTP header has been validated.
>>   *     - FCOE: indicates the CRC in FC frame has been validated.
>> """
>>
>> I'm not sure whether it's just fine to duplicate the definition or
>> it's too late to define any now.
> I think it's mostly harmless for other protocols.

I'm not sure if this should be defined by a new FULL_CSUM feature.
This seems to be an issue with GUEST_CSUM.

I think we should supplement these with a new patch for GUEST_CSUM?

Thanks!

>
>>> After this is written up we will come up with a good short
>>> description for the feature bit.
>>>
>> Thanks
>>
>>>>> Thanks!
>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>
>>>>>>>>>>>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
>>>>>>>>>>>>>>               reconfiguration support.
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> 2.19.1.6.gb485710b
>>>>>>>>>>>>>>
>>>>>>>>>> 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/
>>>>>>> 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/
>>>>>>>
>>>>>
>>>>> 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/
>>>>>


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Jason Wang]

On Mon, Dec 4, 2023 at 5:34 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>
>
>
> 在 2023/12/4 下午5:05, Michael S. Tsirkin 写道:
> > On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
> >> On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >>> On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
> >>>> On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >>>>>
> >>>>>
> >>>>> 在 2023/12/4 下午3:18, Jason Wang 写道:
> >>>>>> On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >>>>>>>
> >>>>>>> 在 2023/12/1 下午3:05, Jason Wang 写道:
> >>>>>>>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >>>>>>>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
> >>>>>>>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
> >>>>>>>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
> >>>>>>>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>> To prevent readers from misunderstanding that the driver can
> >>>>>>>>>>>>>> only handles packets with partial checksum when
> >>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> >>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>       device-types/net/description.tex | 2 +-
> >>>>>>>>>>>>>>       1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> diff --git a/device-types/net/description.tex
> >>>>>>>>>>>>>> b/device-types/net/description.tex
> >>>>>>>>>>>>>> index aff5e08..529f470 100644
> >>>>>>>>>>>>>> --- a/device-types/net/description.tex
> >>>>>>>>>>>>>> +++ b/device-types/net/description.tex
> >>>>>>>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
> >>>>>>>>>>>>>> / Network Device / Feature bits
> >>>>>>>>>>>>>>       \begin{description}
> >>>>>>>>>>>>>>       \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
> >>>>>>>>>>>>>> partial checksum offload.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> >>>>>>>>>>>>>> partial checksum.
> >>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> >>>>>>>>>>>>>> partial checksum or full checksum.
> >>>>>>>>>>>>> So patch 2 said
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> "
> >>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
> >>>>>>>>>>>>> full checksum.
> >>>>>>>>>>>>>       \end{description}
> >>>>>>>>>>>>> "
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Is there any difference between the two "full checksum" here?
> >>>>>>>>>>>> There's no difference.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
> >>>>>>>>>>>> "can
> >>>>>>>>>>>> only" handle packets with full checksum.
> >>>>>>>>>>> This seems to be odd.
> >>>>>>>>>>>
> >>>>>>>>>>> Driver can always handle packet with full checksum, no?
> >>>>>>>>>> Yes.
> >>>>>>>>>>
> >>>>>>>>>>> I meant it
> >>>>>>>>>>> will be then to be functional equivalent to !
> >>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
> >>>>>>>>>> Are you referring to
> >>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
> >>>>>>>>> Sorry, this is a typo. I meant
> >>>>>>>>>
> >>>>>>>>> Are you referring to
> >>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
> >>>>>>>>>
> >>>>>>>>>> If so, I think it's no.
> >>>>>>>>>>
> >>>>>>>>>> Maybe a description similar to the following would be more clearer:
> >>>>>>>>>>
> >>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
> >>>>>>>>>> packets with partial checksum.
> >>>>>>>> I may miss something here, but what's the difference between
> >>>>>>>>
> >>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM
> >>>>>>>>
> >>>>>>>> and
> >>>>>>>>
> >>>>>>>> !VIRTIO_NET_F_GUEST_CSUM?
> >>>>>>>    From the device perspective:
> >>>>>>>
> >>>>>>> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
> >>>>>>> checksum to the driver,
> >>>>>>> but the device can not validate the checksum for these packets. That is,
> >>>>>>> the flags in virtio-net-hdr
> >>>>>>> will not contain _DATA_VALID, and the driver or stack needs to validate
> >>>>>>> these packets.
> >>>>>>>
> >>>>>>> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
> >>>>>>> checksum to the driver,
> >>>>>>> and the device can validate the checksum for these packets. That is, the
> >>>>>>> flags in virtio-net-hdr
> >>>>>>> will contain _DATA_VALID,
> >>>>>> I think DATA_VALID is optional here as device can't recognize all type
> >>>>>> of protocols.
> >>>>> Yes, you are right, so I used "device *can*" here. Which packet types
> >>>>> the device recognizes or validates
> >>>>> depends on the device's implementation. This is also the current
> >>>>> practice of GUEST_CSUM.
> >>>>>
> >>>>>>> and the driver or stack does not need to
> >>>>>>> validate these packets.
> >>>>>> Ok, so I think there're something that is subtle here,
> >>>>> Ok, I see.
> >>>>>
> >>>>>> and that's why
> >>>>>> I'm asking here:
> >>>>>>
> >>>>>> 1) "Driver does not handle packets with partial checksum" is not
> >>>>>> accurate, !GUEST_CUSM also fit for this definition.
> >>>>>> 2) "Driver handles packets with full checksum" is kind of ambiguous as
> >>>>>> it doesn't say whether or not the packet has been validated or not.
> >>>>> Maybe the description below would be less subtle?
> >>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
> >>>>> checksum or full checksum.
> >>>> I'd suggest to leave it as is. As I didn't find any issue since even
> >>>> with DATA_VALID. Did you?
> >>>>
> >>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
> >>>>> with full checksum,
> >>>>> and the device optionally validates the packet's checksum.
> >>>> Or maybe something like (not a native speaker)
> >>>>
> >>>> The driver handles packets with full checksum which the device has
> >>>> already validated.
> >>>>
> >>>> Thanks
> >>> I feel we just need a proper definition of what does "full checksum"
> >>> mean in this context. It is used but not defined.
> >>> Assume this feature was negotiated.
> >>> My understanding is that this is just like VIRTIO_NET_F_GUEST_CSUM
> >>> but certain values in the header are then disallowed? Which?
> >>> This should be in the spec.
> >> Yes, I think it is probably the headers that DATA_VALID can work. We
> >> never define it in the past.
> >>
> >> E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY, but it can
> >> only work for some specific protocols:
> >>
> >> """
> >>   *   %CHECKSUM_UNNECESSARY is applicable to following protocols:
> >>   *
> >>   *     - TCP: IPv6 and IPv4.
> >>   *     - UDP: IPv4 and IPv6. A device may apply CHECKSUM_UNNECESSARY to a
> >>   *       zero UDP checksum for either IPv4 or IPv6, the networking stack
> >>   *       may perform further validation in this case.
> >>   *     - GRE: only if the checksum is present in the header.
> >>   *     - SCTP: indicates the CRC in SCTP header has been validated.
> >>   *     - FCOE: indicates the CRC in FC frame has been validated.
> >> """
> >>
> >> I'm not sure whether it's just fine to duplicate the definition or
> >> it's too late to define any now.
> > I think it's mostly harmless for other protocols.
>
> I'm not sure if this should be defined by a new FULL_CSUM feature.
> This seems to be an issue with GUEST_CSUM.
>
> I think we should supplement these with a new patch for GUEST_CSUM?

Probably. My understanding is:

You want to reuse DATA_VALID here, so we need to stick to a consistent
semantic for GUEST_CUSM and FULL_CSUM. So we need a definition of
"full csum" or what kind of packet could DATA_VALID work here.

Thanks

>
> Thanks!
>
> >
> >>> After this is written up we will come up with a good short
> >>> description for the feature bit.
> >>>
> >> Thanks
> >>
> >>>>> Thanks!
> >>>>>
> >>>>>> Thanks
> >>>>>>
> >>>>>>> Thanks!
> >>>>>>>
> >>>>>>>> Thanks
> >>>>>>>>
> >>>>>>>>>> Thanks!
> >>>>>>>>>>
> >>>>>>>>>>> Thanks
> >>>>>>>>>>>
> >>>>>>>>>>>> Thanks!
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
> >>>>>>>>>>>>>>               reconfiguration support.
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> 2.19.1.6.gb485710b
> >>>>>>>>>>>>>>
> >>>>>>>>>> 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/
> >>>>>>> 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/
> >>>>>>>
> >>>>>
> >>>>> 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/
> >>>>>
>


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Heng Qi]

在 2023/12/5 上午11:52, Jason Wang 写道:
> On Mon, Dec 4, 2023 at 5:34 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>
>>
>> 在 2023/12/4 下午5:05, Michael S. Tsirkin 写道:
>>> On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
>>>> On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>>>>> On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
>>>>>> On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>>>>
>>>>>>> 在 2023/12/4 下午3:18, Jason Wang 写道:
>>>>>>>> On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>>>>>> 在 2023/12/1 下午3:05, Jason Wang 写道:
>>>>>>>>>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
>>>>>>>>>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
>>>>>>>>>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
>>>>>>>>>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> To prevent readers from misunderstanding that the driver can
>>>>>>>>>>>>>>>> only handles packets with partial checksum when
>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>        device-types/net/description.tex | 2 +-
>>>>>>>>>>>>>>>>        1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> diff --git a/device-types/net/description.tex
>>>>>>>>>>>>>>>> b/device-types/net/description.tex
>>>>>>>>>>>>>>>> index aff5e08..529f470 100644
>>>>>>>>>>>>>>>> --- a/device-types/net/description.tex
>>>>>>>>>>>>>>>> +++ b/device-types/net/description.tex
>>>>>>>>>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
>>>>>>>>>>>>>>>> / Network Device / Feature bits
>>>>>>>>>>>>>>>>        \begin{description}
>>>>>>>>>>>>>>>>        \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
>>>>>>>>>>>>>>>> partial checksum offload.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
>>>>>>>>>>>>>>>> partial checksum.
>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
>>>>>>>>>>>>>>>> partial checksum or full checksum.
>>>>>>>>>>>>>>> So patch 2 said
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "
>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
>>>>>>>>>>>>>>> full checksum.
>>>>>>>>>>>>>>>        \end{description}
>>>>>>>>>>>>>>> "
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Is there any difference between the two "full checksum" here?
>>>>>>>>>>>>>> There's no difference.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
>>>>>>>>>>>>>> "can
>>>>>>>>>>>>>> only" handle packets with full checksum.
>>>>>>>>>>>>> This seems to be odd.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Driver can always handle packet with full checksum, no?
>>>>>>>>>>>> Yes.
>>>>>>>>>>>>
>>>>>>>>>>>>> I meant it
>>>>>>>>>>>>> will be then to be functional equivalent to !
>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
>>>>>>>>>>>> Are you referring to
>>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
>>>>>>>>>>> Sorry, this is a typo. I meant
>>>>>>>>>>>
>>>>>>>>>>> Are you referring to
>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
>>>>>>>>>>>
>>>>>>>>>>>> If so, I think it's no.
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe a description similar to the following would be more clearer:
>>>>>>>>>>>>
>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
>>>>>>>>>>>> packets with partial checksum.
>>>>>>>>>> I may miss something here, but what's the difference between
>>>>>>>>>>
>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM
>>>>>>>>>>
>>>>>>>>>> and
>>>>>>>>>>
>>>>>>>>>> !VIRTIO_NET_F_GUEST_CSUM?
>>>>>>>>>     From the device perspective:
>>>>>>>>>
>>>>>>>>> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
>>>>>>>>> checksum to the driver,
>>>>>>>>> but the device can not validate the checksum for these packets. That is,
>>>>>>>>> the flags in virtio-net-hdr
>>>>>>>>> will not contain _DATA_VALID, and the driver or stack needs to validate
>>>>>>>>> these packets.
>>>>>>>>>
>>>>>>>>> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
>>>>>>>>> checksum to the driver,
>>>>>>>>> and the device can validate the checksum for these packets. That is, the
>>>>>>>>> flags in virtio-net-hdr
>>>>>>>>> will contain _DATA_VALID,
>>>>>>>> I think DATA_VALID is optional here as device can't recognize all type
>>>>>>>> of protocols.
>>>>>>> Yes, you are right, so I used "device *can*" here. Which packet types
>>>>>>> the device recognizes or validates
>>>>>>> depends on the device's implementation. This is also the current
>>>>>>> practice of GUEST_CSUM.
>>>>>>>
>>>>>>>>> and the driver or stack does not need to
>>>>>>>>> validate these packets.
>>>>>>>> Ok, so I think there're something that is subtle here,
>>>>>>> Ok, I see.
>>>>>>>
>>>>>>>> and that's why
>>>>>>>> I'm asking here:
>>>>>>>>
>>>>>>>> 1) "Driver does not handle packets with partial checksum" is not
>>>>>>>> accurate, !GUEST_CUSM also fit for this definition.
>>>>>>>> 2) "Driver handles packets with full checksum" is kind of ambiguous as
>>>>>>>> it doesn't say whether or not the packet has been validated or not.
>>>>>>> Maybe the description below would be less subtle?
>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
>>>>>>> checksum or full checksum.
>>>>>> I'd suggest to leave it as is. As I didn't find any issue since even
>>>>>> with DATA_VALID. Did you?
>>>>>>
>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
>>>>>>> with full checksum,
>>>>>>> and the device optionally validates the packet's checksum.
>>>>>> Or maybe something like (not a native speaker)
>>>>>>
>>>>>> The driver handles packets with full checksum which the device has
>>>>>> already validated.
>>>>>>
>>>>>> Thanks
>>>>> I feel we just need a proper definition of what does "full checksum"
>>>>> mean in this context. It is used but not defined.
>>>>> Assume this feature was negotiated.
>>>>> My understanding is that this is just like VIRTIO_NET_F_GUEST_CSUM
>>>>> but certain values in the header are then disallowed? Which?
>>>>> This should be in the spec.
>>>> Yes, I think it is probably the headers that DATA_VALID can work. We
>>>> never define it in the past.
>>>>
>>>> E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY, but it can
>>>> only work for some specific protocols:
>>>>
>>>> """
>>>>    *   %CHECKSUM_UNNECESSARY is applicable to following protocols:
>>>>    *
>>>>    *     - TCP: IPv6 and IPv4.
>>>>    *     - UDP: IPv4 and IPv6. A device may apply CHECKSUM_UNNECESSARY to a
>>>>    *       zero UDP checksum for either IPv4 or IPv6, the networking stack
>>>>    *       may perform further validation in this case.
>>>>    *     - GRE: only if the checksum is present in the header.
>>>>    *     - SCTP: indicates the CRC in SCTP header has been validated.
>>>>    *     - FCOE: indicates the CRC in FC frame has been validated.
>>>> """
>>>>
>>>> I'm not sure whether it's just fine to duplicate the definition or
>>>> it's too late to define any now.
>>> I think it's mostly harmless for other protocols.
>> I'm not sure if this should be defined by a new FULL_CSUM feature.
>> This seems to be an issue with GUEST_CSUM.
>>
>> I think we should supplement these with a new patch for GUEST_CSUM?
> Probably. My understanding is:
>
> You want to reuse DATA_VALID here, so we need to stick to a consistent
> semantic for GUEST_CUSM and FULL_CSUM. So we need a definition of
> "full csum" or what kind of packet could DATA_VALID work here.

I agree, we can be clear about what types of packets DATA_VALID might
cover, e.g. TCP/UDP/GRE/SCTP/FoCE.

But I think we also need something like \field{supported_validate_types} to
indicate which packet types the device supports validating and setting 
DATA_VALID,
otherwise the device driver that negotiates this feature may fail to 
live migration.
Am I right?

I'm not sure how GUEST_CSUM works now as it should also suffer from the 
above
mentioned issues with live migration, but no devices are reporting this 
right now.

Maybe, each device only supports checksum verification for TCP/UDP by 
default? I don't know.
But I hope we can focus on this and get consensus, because our hw 
release date is coming soon.

Thanks a lot!

>
> Thanks
>
>> Thanks!
>>
>>>>> After this is written up we will come up with a good short
>>>>> description for the feature bit.
>>>>>
>>>> Thanks
>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
>>>>>>>>>>>>>>>>                reconfiguration support.
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> 2.19.1.6.gb485710b
>>>>>>>>>>>>>>>>
>>>>>>>>>>>> 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/
>>>>>>>>> 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/
>>>>>>>>>
>>>>>>> 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/
>>>>>>>


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Michael S. Tsirkin]

On Tue, Dec 05, 2023 at 10:18:32PM +0800, Heng Qi wrote:
> 
> 
> 在 2023/12/5 上午11:52, Jason Wang 写道:
> > On Mon, Dec 4, 2023 at 5:34 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > 
> > > 
> > > 在 2023/12/4 下午5:05, Michael S. Tsirkin 写道:
> > > > On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
> > > > > On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > > On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
> > > > > > > On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > > > > > > 
> > > > > > > > 在 2023/12/4 下午3:18, Jason Wang 写道:
> > > > > > > > > On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > > > > > > > > 在 2023/12/1 下午3:05, Jason Wang 写道:
> > > > > > > > > > > On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > > > > > > > > > > 在 2023/12/1 下午2:24, Heng Qi 写道:
> > > > > > > > > > > > > 在 2023/12/1 下午1:18, Jason Wang 写道:
> > > > > > > > > > > > > > On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > 在 2023/11/29 下午4:00, Jason Wang 写道:
> > > > > > > > > > > > > > > > On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > To prevent readers from misunderstanding that the driver can
> > > > > > > > > > > > > > > > > only handles packets with partial checksum when
> > > > > > > > > > > > > > > > > VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> > > > > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > > > >        device-types/net/description.tex | 2 +-
> > > > > > > > > > > > > > > > >        1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > diff --git a/device-types/net/description.tex
> > > > > > > > > > > > > > > > > b/device-types/net/description.tex
> > > > > > > > > > > > > > > > > index aff5e08..529f470 100644
> > > > > > > > > > > > > > > > > --- a/device-types/net/description.tex
> > > > > > > > > > > > > > > > > +++ b/device-types/net/description.tex
> > > > > > > > > > > > > > > > > @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
> > > > > > > > > > > > > > > > > / Network Device / Feature bits
> > > > > > > > > > > > > > > > >        \begin{description}
> > > > > > > > > > > > > > > > >        \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
> > > > > > > > > > > > > > > > > partial checksum offload.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> > > > > > > > > > > > > > > > > partial checksum.
> > > > > > > > > > > > > > > > > +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> > > > > > > > > > > > > > > > > partial checksum or full checksum.
> > > > > > > > > > > > > > > > So patch 2 said
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > "
> > > > > > > > > > > > > > > > +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
> > > > > > > > > > > > > > > > full checksum.
> > > > > > > > > > > > > > > >        \end{description}
> > > > > > > > > > > > > > > > "
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Is there any difference between the two "full checksum" here?
> > > > > > > > > > > > > > > There's no difference.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
> > > > > > > > > > > > > > > "can
> > > > > > > > > > > > > > > only" handle packets with full checksum.
> > > > > > > > > > > > > > This seems to be odd.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Driver can always handle packet with full checksum, no?
> > > > > > > > > > > > > Yes.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > I meant it
> > > > > > > > > > > > > > will be then to be functional equivalent to !
> > > > > > > > > > > > > > VIRTIO_NET_F_GUEST_FULL_CSUM?
> > > > > > > > > > > > > Are you referring to
> > > > > > > > > > > > > "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
> > > > > > > > > > > > Sorry, this is a typo. I meant
> > > > > > > > > > > > 
> > > > > > > > > > > > Are you referring to
> > > > > > > > > > > > "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
> > > > > > > > > > > > 
> > > > > > > > > > > > > If so, I think it's no.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Maybe a description similar to the following would be more clearer:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
> > > > > > > > > > > > > packets with partial checksum.
> > > > > > > > > > > I may miss something here, but what's the difference between
> > > > > > > > > > > 
> > > > > > > > > > > VIRTIO_NET_F_GUEST_FULL_CSUM
> > > > > > > > > > > 
> > > > > > > > > > > and
> > > > > > > > > > > 
> > > > > > > > > > > !VIRTIO_NET_F_GUEST_CSUM?
> > > > > > > > > >     From the device perspective:
> > > > > > > > > > 
> > > > > > > > > > If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
> > > > > > > > > > checksum to the driver,
> > > > > > > > > > but the device can not validate the checksum for these packets. That is,
> > > > > > > > > > the flags in virtio-net-hdr
> > > > > > > > > > will not contain _DATA_VALID, and the driver or stack needs to validate
> > > > > > > > > > these packets.
> > > > > > > > > > 
> > > > > > > > > > If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
> > > > > > > > > > checksum to the driver,
> > > > > > > > > > and the device can validate the checksum for these packets. That is, the
> > > > > > > > > > flags in virtio-net-hdr
> > > > > > > > > > will contain _DATA_VALID,
> > > > > > > > > I think DATA_VALID is optional here as device can't recognize all type
> > > > > > > > > of protocols.
> > > > > > > > Yes, you are right, so I used "device *can*" here. Which packet types
> > > > > > > > the device recognizes or validates
> > > > > > > > depends on the device's implementation. This is also the current
> > > > > > > > practice of GUEST_CSUM.
> > > > > > > > 
> > > > > > > > > > and the driver or stack does not need to
> > > > > > > > > > validate these packets.
> > > > > > > > > Ok, so I think there're something that is subtle here,
> > > > > > > > Ok, I see.
> > > > > > > > 
> > > > > > > > > and that's why
> > > > > > > > > I'm asking here:
> > > > > > > > > 
> > > > > > > > > 1) "Driver does not handle packets with partial checksum" is not
> > > > > > > > > accurate, !GUEST_CUSM also fit for this definition.
> > > > > > > > > 2) "Driver handles packets with full checksum" is kind of ambiguous as
> > > > > > > > > it doesn't say whether or not the packet has been validated or not.
> > > > > > > > Maybe the description below would be less subtle?
> > > > > > > > +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
> > > > > > > > checksum or full checksum.
> > > > > > > I'd suggest to leave it as is. As I didn't find any issue since even
> > > > > > > with DATA_VALID. Did you?
> > > > > > > 
> > > > > > > > +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
> > > > > > > > with full checksum,
> > > > > > > > and the device optionally validates the packet's checksum.
> > > > > > > Or maybe something like (not a native speaker)
> > > > > > > 
> > > > > > > The driver handles packets with full checksum which the device has
> > > > > > > already validated.
> > > > > > > 
> > > > > > > Thanks
> > > > > > I feel we just need a proper definition of what does "full checksum"
> > > > > > mean in this context. It is used but not defined.
> > > > > > Assume this feature was negotiated.
> > > > > > My understanding is that this is just like VIRTIO_NET_F_GUEST_CSUM
> > > > > > but certain values in the header are then disallowed? Which?
> > > > > > This should be in the spec.
> > > > > Yes, I think it is probably the headers that DATA_VALID can work. We
> > > > > never define it in the past.
> > > > > 
> > > > > E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY, but it can
> > > > > only work for some specific protocols:
> > > > > 
> > > > > """
> > > > >    *   %CHECKSUM_UNNECESSARY is applicable to following protocols:
> > > > >    *
> > > > >    *     - TCP: IPv6 and IPv4.
> > > > >    *     - UDP: IPv4 and IPv6. A device may apply CHECKSUM_UNNECESSARY to a
> > > > >    *       zero UDP checksum for either IPv4 or IPv6, the networking stack
> > > > >    *       may perform further validation in this case.
> > > > >    *     - GRE: only if the checksum is present in the header.
> > > > >    *     - SCTP: indicates the CRC in SCTP header has been validated.
> > > > >    *     - FCOE: indicates the CRC in FC frame has been validated.
> > > > > """
> > > > > 
> > > > > I'm not sure whether it's just fine to duplicate the definition or
> > > > > it's too late to define any now.
> > > > I think it's mostly harmless for other protocols.
> > > I'm not sure if this should be defined by a new FULL_CSUM feature.
> > > This seems to be an issue with GUEST_CSUM.
> > > 
> > > I think we should supplement these with a new patch for GUEST_CSUM?
> > Probably. My understanding is:
> > 
> > You want to reuse DATA_VALID here, so we need to stick to a consistent
> > semantic for GUEST_CUSM and FULL_CSUM. So we need a definition of
> > "full csum" or what kind of packet could DATA_VALID work here.
> 
> I agree, we can be clear about what types of packets DATA_VALID might
> cover, e.g. TCP/UDP/GRE/SCTP/FoCE.
> 
> But I think we also need something like \field{supported_validate_types} to
> indicate which packet types the device supports validating and setting
> DATA_VALID,
> otherwise the device driver that negotiates this feature may fail to live
> migration.
> Am I right?
> 
> I'm not sure how GUEST_CSUM works now as it should also suffer from the
> above
> mentioned issues with live migration, but no devices are reporting this
> right now.
> 
> Maybe, each device only supports checksum verification for TCP/UDP by
> default? I don't know.
> But I hope we can focus on this and get consensus, because our hw release
> date is coming soon.
> 
> Thanks a lot!


First, DATA_VALID is not a thing that hardware should ever use.
It's a hack when packets are passed within host.
Second I don't understand what it has to do with this
discussion.
Your patch should be more specific and define which
header fields are compatible with the new offload option.



> > 
> > Thanks
> > 
> > > Thanks!
> > > 
> > > > > > After this is written up we will come up with a good short
> > > > > > description for the feature bit.
> > > > > > 
> > > > > Thanks
> > > > > 
> > > > > > > > Thanks!
> > > > > > > > 
> > > > > > > > > Thanks
> > > > > > > > > 
> > > > > > > > > > Thanks!
> > > > > > > > > > 
> > > > > > > > > > > Thanks
> > > > > > > > > > > 
> > > > > > > > > > > > > Thanks!
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > Thanks
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Thanks!
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Thanks
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
> > > > > > > > > > > > > > > > >                reconfiguration support.
> > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > 2.19.1.6.gb485710b
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > 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/
> > > > > > > > > > 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/
> > > > > > > > > > 
> > > > > > > > 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/
> > > > > > > > 


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Heng Qi]

在 2023/12/5 下午10:45, Michael S. Tsirkin 写道:
> On Tue, Dec 05, 2023 at 10:18:32PM +0800, Heng Qi wrote:
>>
>> 在 2023/12/5 上午11:52, Jason Wang 写道:
>>> On Mon, Dec 4, 2023 at 5:34 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>
>>>> 在 2023/12/4 下午5:05, Michael S. Tsirkin 写道:
>>>>> On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
>>>>>> On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>>>>>>> On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
>>>>>>>> On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>>>>>> 在 2023/12/4 下午3:18, Jason Wang 写道:
>>>>>>>>>> On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>> 在 2023/12/1 下午3:05, Jason Wang 写道:
>>>>>>>>>>>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
>>>>>>>>>>>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
>>>>>>>>>>>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
>>>>>>>>>>>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> To prevent readers from misunderstanding that the driver can
>>>>>>>>>>>>>>>>>> only handles packets with partial checksum when
>>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>>         device-types/net/description.tex | 2 +-
>>>>>>>>>>>>>>>>>>         1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> diff --git a/device-types/net/description.tex
>>>>>>>>>>>>>>>>>> b/device-types/net/description.tex
>>>>>>>>>>>>>>>>>> index aff5e08..529f470 100644
>>>>>>>>>>>>>>>>>> --- a/device-types/net/description.tex
>>>>>>>>>>>>>>>>>> +++ b/device-types/net/description.tex
>>>>>>>>>>>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
>>>>>>>>>>>>>>>>>> / Network Device / Feature bits
>>>>>>>>>>>>>>>>>>         \begin{description}
>>>>>>>>>>>>>>>>>>         \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
>>>>>>>>>>>>>>>>>> partial checksum offload.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
>>>>>>>>>>>>>>>>>> partial checksum.
>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
>>>>>>>>>>>>>>>>>> partial checksum or full checksum.
>>>>>>>>>>>>>>>>> So patch 2 said
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> "
>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
>>>>>>>>>>>>>>>>> full checksum.
>>>>>>>>>>>>>>>>>         \end{description}
>>>>>>>>>>>>>>>>> "
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Is there any difference between the two "full checksum" here?
>>>>>>>>>>>>>>>> There's no difference.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
>>>>>>>>>>>>>>>> "can
>>>>>>>>>>>>>>>> only" handle packets with full checksum.
>>>>>>>>>>>>>>> This seems to be odd.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Driver can always handle packet with full checksum, no?
>>>>>>>>>>>>>> Yes.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I meant it
>>>>>>>>>>>>>>> will be then to be functional equivalent to !
>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
>>>>>>>>>>>>>> Are you referring to
>>>>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
>>>>>>>>>>>>> Sorry, this is a typo. I meant
>>>>>>>>>>>>>
>>>>>>>>>>>>> Are you referring to
>>>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
>>>>>>>>>>>>>
>>>>>>>>>>>>>> If so, I think it's no.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe a description similar to the following would be more clearer:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
>>>>>>>>>>>>>> packets with partial checksum.
>>>>>>>>>>>> I may miss something here, but what's the difference between
>>>>>>>>>>>>
>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM
>>>>>>>>>>>>
>>>>>>>>>>>> and
>>>>>>>>>>>>
>>>>>>>>>>>> !VIRTIO_NET_F_GUEST_CSUM?
>>>>>>>>>>>      From the device perspective:
>>>>>>>>>>>
>>>>>>>>>>> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
>>>>>>>>>>> checksum to the driver,
>>>>>>>>>>> but the device can not validate the checksum for these packets. That is,
>>>>>>>>>>> the flags in virtio-net-hdr
>>>>>>>>>>> will not contain _DATA_VALID, and the driver or stack needs to validate
>>>>>>>>>>> these packets.
>>>>>>>>>>>
>>>>>>>>>>> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
>>>>>>>>>>> checksum to the driver,
>>>>>>>>>>> and the device can validate the checksum for these packets. That is, the
>>>>>>>>>>> flags in virtio-net-hdr
>>>>>>>>>>> will contain _DATA_VALID,
>>>>>>>>>> I think DATA_VALID is optional here as device can't recognize all type
>>>>>>>>>> of protocols.
>>>>>>>>> Yes, you are right, so I used "device *can*" here. Which packet types
>>>>>>>>> the device recognizes or validates
>>>>>>>>> depends on the device's implementation. This is also the current
>>>>>>>>> practice of GUEST_CSUM.
>>>>>>>>>
>>>>>>>>>>> and the driver or stack does not need to
>>>>>>>>>>> validate these packets.
>>>>>>>>>> Ok, so I think there're something that is subtle here,
>>>>>>>>> Ok, I see.
>>>>>>>>>
>>>>>>>>>> and that's why
>>>>>>>>>> I'm asking here:
>>>>>>>>>>
>>>>>>>>>> 1) "Driver does not handle packets with partial checksum" is not
>>>>>>>>>> accurate, !GUEST_CUSM also fit for this definition.
>>>>>>>>>> 2) "Driver handles packets with full checksum" is kind of ambiguous as
>>>>>>>>>> it doesn't say whether or not the packet has been validated or not.
>>>>>>>>> Maybe the description below would be less subtle?
>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
>>>>>>>>> checksum or full checksum.
>>>>>>>> I'd suggest to leave it as is. As I didn't find any issue since even
>>>>>>>> with DATA_VALID. Did you?
>>>>>>>>
>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
>>>>>>>>> with full checksum,
>>>>>>>>> and the device optionally validates the packet's checksum.
>>>>>>>> Or maybe something like (not a native speaker)
>>>>>>>>
>>>>>>>> The driver handles packets with full checksum which the device has
>>>>>>>> already validated.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>> I feel we just need a proper definition of what does "full checksum"
>>>>>>> mean in this context. It is used but not defined.
>>>>>>> Assume this feature was negotiated.
>>>>>>> My understanding is that this is just like VIRTIO_NET_F_GUEST_CSUM
>>>>>>> but certain values in the header are then disallowed? Which?
>>>>>>> This should be in the spec.
>>>>>> Yes, I think it is probably the headers that DATA_VALID can work. We
>>>>>> never define it in the past.
>>>>>>
>>>>>> E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY, but it can
>>>>>> only work for some specific protocols:
>>>>>>
>>>>>> """
>>>>>>     *   %CHECKSUM_UNNECESSARY is applicable to following protocols:
>>>>>>     *
>>>>>>     *     - TCP: IPv6 and IPv4.
>>>>>>     *     - UDP: IPv4 and IPv6. A device may apply CHECKSUM_UNNECESSARY to a
>>>>>>     *       zero UDP checksum for either IPv4 or IPv6, the networking stack
>>>>>>     *       may perform further validation in this case.
>>>>>>     *     - GRE: only if the checksum is present in the header.
>>>>>>     *     - SCTP: indicates the CRC in SCTP header has been validated.
>>>>>>     *     - FCOE: indicates the CRC in FC frame has been validated.
>>>>>> """
>>>>>>
>>>>>> I'm not sure whether it's just fine to duplicate the definition or
>>>>>> it's too late to define any now.
>>>>> I think it's mostly harmless for other protocols.
>>>> I'm not sure if this should be defined by a new FULL_CSUM feature.
>>>> This seems to be an issue with GUEST_CSUM.
>>>>
>>>> I think we should supplement these with a new patch for GUEST_CSUM?
>>> Probably. My understanding is:
>>>
>>> You want to reuse DATA_VALID here, so we need to stick to a consistent
>>> semantic for GUEST_CUSM and FULL_CSUM. So we need a definition of
>>> "full csum" or what kind of packet could DATA_VALID work here.
>> I agree, we can be clear about what types of packets DATA_VALID might
>> cover, e.g. TCP/UDP/GRE/SCTP/FoCE.
>>
>> But I think we also need something like \field{supported_validate_types} to
>> indicate which packet types the device supports validating and setting
>> DATA_VALID,
>> otherwise the device driver that negotiates this feature may fail to live
>> migration.
>> Am I right?
>>
>> I'm not sure how GUEST_CSUM works now as it should also suffer from the
>> above
>> mentioned issues with live migration, but no devices are reporting this
>> right now.
>>
>> Maybe, each device only supports checksum verification for TCP/UDP by
>> default? I don't know.
>> But I hope we can focus on this and get consensus, because our hw release
>> date is coming soon.
>>
>> Thanks a lot!
>
> First, DATA_VALID is not a thing that hardware should ever use.
> It's a hack when packets are passed within host.

Get here. Thanks!

> Second I don't understand what it has to do with this
> discussion.
> Your patch should be more specific and define which
> header fields are compatible with the new offload option.
>
>
>
>>> Thanks
>>>
>>>> Thanks!
>>>>
>>>>>>> After this is written up we will come up with a good short
>>>>>>> description for the feature bit.
>>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
>>>>>>>>>>>>>>>>>>                 reconfiguration support.
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> 2.19.1.6.gb485710b
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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/
>>>>>>>>>>> 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/
>>>>>>>>>>>
>>>>>>>>> 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/
>>>>>>>>>
>
> 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/


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Jason Wang]

On Tue, Dec 5, 2023 at 10:18 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>
>
>
> 在 2023/12/5 上午11:52, Jason Wang 写道:
> > On Mon, Dec 4, 2023 at 5:34 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >>
> >>
> >> 在 2023/12/4 下午5:05, Michael S. Tsirkin 写道:
> >>> On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
> >>>> On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >>>>> On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
> >>>>>> On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >>>>>>>
> >>>>>>> 在 2023/12/4 下午3:18, Jason Wang 写道:
> >>>>>>>> On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >>>>>>>>> 在 2023/12/1 下午3:05, Jason Wang 写道:
> >>>>>>>>>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >>>>>>>>>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
> >>>>>>>>>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
> >>>>>>>>>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
> >>>>>>>>>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>> To prevent readers from misunderstanding that the driver can
> >>>>>>>>>>>>>>>> only handles packets with partial checksum when
> >>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> >>>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>>>        device-types/net/description.tex | 2 +-
> >>>>>>>>>>>>>>>>        1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> diff --git a/device-types/net/description.tex
> >>>>>>>>>>>>>>>> b/device-types/net/description.tex
> >>>>>>>>>>>>>>>> index aff5e08..529f470 100644
> >>>>>>>>>>>>>>>> --- a/device-types/net/description.tex
> >>>>>>>>>>>>>>>> +++ b/device-types/net/description.tex
> >>>>>>>>>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
> >>>>>>>>>>>>>>>> / Network Device / Feature bits
> >>>>>>>>>>>>>>>>        \begin{description}
> >>>>>>>>>>>>>>>>        \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
> >>>>>>>>>>>>>>>> partial checksum offload.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> >>>>>>>>>>>>>>>> partial checksum.
> >>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> >>>>>>>>>>>>>>>> partial checksum or full checksum.
> >>>>>>>>>>>>>>> So patch 2 said
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> "
> >>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
> >>>>>>>>>>>>>>> full checksum.
> >>>>>>>>>>>>>>>        \end{description}
> >>>>>>>>>>>>>>> "
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Is there any difference between the two "full checksum" here?
> >>>>>>>>>>>>>> There's no difference.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
> >>>>>>>>>>>>>> "can
> >>>>>>>>>>>>>> only" handle packets with full checksum.
> >>>>>>>>>>>>> This seems to be odd.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Driver can always handle packet with full checksum, no?
> >>>>>>>>>>>> Yes.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I meant it
> >>>>>>>>>>>>> will be then to be functional equivalent to !
> >>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
> >>>>>>>>>>>> Are you referring to
> >>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
> >>>>>>>>>>> Sorry, this is a typo. I meant
> >>>>>>>>>>>
> >>>>>>>>>>> Are you referring to
> >>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
> >>>>>>>>>>>
> >>>>>>>>>>>> If so, I think it's no.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Maybe a description similar to the following would be more clearer:
> >>>>>>>>>>>>
> >>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
> >>>>>>>>>>>> packets with partial checksum.
> >>>>>>>>>> I may miss something here, but what's the difference between
> >>>>>>>>>>
> >>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM
> >>>>>>>>>>
> >>>>>>>>>> and
> >>>>>>>>>>
> >>>>>>>>>> !VIRTIO_NET_F_GUEST_CSUM?
> >>>>>>>>>     From the device perspective:
> >>>>>>>>>
> >>>>>>>>> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
> >>>>>>>>> checksum to the driver,
> >>>>>>>>> but the device can not validate the checksum for these packets. That is,
> >>>>>>>>> the flags in virtio-net-hdr
> >>>>>>>>> will not contain _DATA_VALID, and the driver or stack needs to validate
> >>>>>>>>> these packets.
> >>>>>>>>>
> >>>>>>>>> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
> >>>>>>>>> checksum to the driver,
> >>>>>>>>> and the device can validate the checksum for these packets. That is, the
> >>>>>>>>> flags in virtio-net-hdr
> >>>>>>>>> will contain _DATA_VALID,
> >>>>>>>> I think DATA_VALID is optional here as device can't recognize all type
> >>>>>>>> of protocols.
> >>>>>>> Yes, you are right, so I used "device *can*" here. Which packet types
> >>>>>>> the device recognizes or validates
> >>>>>>> depends on the device's implementation. This is also the current
> >>>>>>> practice of GUEST_CSUM.
> >>>>>>>
> >>>>>>>>> and the driver or stack does not need to
> >>>>>>>>> validate these packets.
> >>>>>>>> Ok, so I think there're something that is subtle here,
> >>>>>>> Ok, I see.
> >>>>>>>
> >>>>>>>> and that's why
> >>>>>>>> I'm asking here:
> >>>>>>>>
> >>>>>>>> 1) "Driver does not handle packets with partial checksum" is not
> >>>>>>>> accurate, !GUEST_CUSM also fit for this definition.
> >>>>>>>> 2) "Driver handles packets with full checksum" is kind of ambiguous as
> >>>>>>>> it doesn't say whether or not the packet has been validated or not.
> >>>>>>> Maybe the description below would be less subtle?
> >>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
> >>>>>>> checksum or full checksum.
> >>>>>> I'd suggest to leave it as is. As I didn't find any issue since even
> >>>>>> with DATA_VALID. Did you?
> >>>>>>
> >>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
> >>>>>>> with full checksum,
> >>>>>>> and the device optionally validates the packet's checksum.
> >>>>>> Or maybe something like (not a native speaker)
> >>>>>>
> >>>>>> The driver handles packets with full checksum which the device has
> >>>>>> already validated.
> >>>>>>
> >>>>>> Thanks
> >>>>> I feel we just need a proper definition of what does "full checksum"
> >>>>> mean in this context. It is used but not defined.
> >>>>> Assume this feature was negotiated.
> >>>>> My understanding is that this is just like VIRTIO_NET_F_GUEST_CSUM
> >>>>> but certain values in the header are then disallowed? Which?
> >>>>> This should be in the spec.
> >>>> Yes, I think it is probably the headers that DATA_VALID can work. We
> >>>> never define it in the past.
> >>>>
> >>>> E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY, but it can
> >>>> only work for some specific protocols:
> >>>>
> >>>> """
> >>>>    *   %CHECKSUM_UNNECESSARY is applicable to following protocols:
> >>>>    *
> >>>>    *     - TCP: IPv6 and IPv4.
> >>>>    *     - UDP: IPv4 and IPv6. A device may apply CHECKSUM_UNNECESSARY to a
> >>>>    *       zero UDP checksum for either IPv4 or IPv6, the networking stack
> >>>>    *       may perform further validation in this case.
> >>>>    *     - GRE: only if the checksum is present in the header.
> >>>>    *     - SCTP: indicates the CRC in SCTP header has been validated.
> >>>>    *     - FCOE: indicates the CRC in FC frame has been validated.
> >>>> """
> >>>>
> >>>> I'm not sure whether it's just fine to duplicate the definition or
> >>>> it's too late to define any now.
> >>> I think it's mostly harmless for other protocols.
> >> I'm not sure if this should be defined by a new FULL_CSUM feature.
> >> This seems to be an issue with GUEST_CSUM.
> >>
> >> I think we should supplement these with a new patch for GUEST_CSUM?
> > Probably. My understanding is:
> >
> > You want to reuse DATA_VALID here, so we need to stick to a consistent
> > semantic for GUEST_CUSM and FULL_CSUM. So we need a definition of
> > "full csum" or what kind of packet could DATA_VALID work here.
>
> I agree, we can be clear about what types of packets DATA_VALID might
> cover, e.g. TCP/UDP/GRE/SCTP/FoCE.
>
> But I think we also need something like \field{supported_validate_types} to
> indicate which packet types the device supports validating and setting
> DATA_VALID,
> otherwise the device driver that negotiates this feature may fail to
> live migration.
> Am I right?

Probably, but I think most devices only do this for TCP/UDP packets
now, so we are fine.

>
> I'm not sure how GUEST_CSUM works now as it should also suffer from the
> above
> mentioned issues with live migration, but no devices are reporting this
> right now.
>
> Maybe, each device only supports checksum verification for TCP/UDP by
> default?

Maybe.

Thanks

> I don't know.
> But I hope we can focus on this and get consensus, because our hw
> release date is coming soon.
>
> Thanks a lot!
>
> >
> > Thanks
> >
> >> Thanks!
> >>
> >>>>> After this is written up we will come up with a good short
> >>>>> description for the feature bit.
> >>>>>
> >>>> Thanks
> >>>>
> >>>>>>> Thanks!
> >>>>>>>
> >>>>>>>> Thanks
> >>>>>>>>
> >>>>>>>>> Thanks!
> >>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>>>
> >>>>>>>>>>>> Thanks!
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks!
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thanks
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
> >>>>>>>>>>>>>>>>                reconfiguration support.
> >>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>> 2.19.1.6.gb485710b
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>> 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/
> >>>>>>>>> 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/
> >>>>>>>>>
> >>>>>>> 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/
> >>>>>>>
>
>
> 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/
>


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Jason Wang]

On Wed, Dec 6, 2023 at 10:21 AM Heng Qi <hengqi@linux.alibaba.com> wrote:
>
>
>
> 在 2023/12/5 下午10:45, Michael S. Tsirkin 写道:
> > On Tue, Dec 05, 2023 at 10:18:32PM +0800, Heng Qi wrote:
> >>
> >> 在 2023/12/5 上午11:52, Jason Wang 写道:
> >>> On Mon, Dec 4, 2023 at 5:34 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >>>>
> >>>> 在 2023/12/4 下午5:05, Michael S. Tsirkin 写道:
> >>>>> On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
> >>>>>> On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >>>>>>> On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
> >>>>>>>> On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >>>>>>>>> 在 2023/12/4 下午3:18, Jason Wang 写道:
> >>>>>>>>>> On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >>>>>>>>>>> 在 2023/12/1 下午3:05, Jason Wang 写道:
> >>>>>>>>>>>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >>>>>>>>>>>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
> >>>>>>>>>>>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
> >>>>>>>>>>>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
> >>>>>>>>>>>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>> To prevent readers from misunderstanding that the driver can
> >>>>>>>>>>>>>>>>>> only handles packets with partial checksum when
> >>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> >>>>>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>>>>>         device-types/net/description.tex | 2 +-
> >>>>>>>>>>>>>>>>>>         1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> diff --git a/device-types/net/description.tex
> >>>>>>>>>>>>>>>>>> b/device-types/net/description.tex
> >>>>>>>>>>>>>>>>>> index aff5e08..529f470 100644
> >>>>>>>>>>>>>>>>>> --- a/device-types/net/description.tex
> >>>>>>>>>>>>>>>>>> +++ b/device-types/net/description.tex
> >>>>>>>>>>>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
> >>>>>>>>>>>>>>>>>> / Network Device / Feature bits
> >>>>>>>>>>>>>>>>>>         \begin{description}
> >>>>>>>>>>>>>>>>>>         \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
> >>>>>>>>>>>>>>>>>> partial checksum offload.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> >>>>>>>>>>>>>>>>>> partial checksum.
> >>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> >>>>>>>>>>>>>>>>>> partial checksum or full checksum.
> >>>>>>>>>>>>>>>>> So patch 2 said
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> "
> >>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
> >>>>>>>>>>>>>>>>> full checksum.
> >>>>>>>>>>>>>>>>>         \end{description}
> >>>>>>>>>>>>>>>>> "
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Is there any difference between the two "full checksum" here?
> >>>>>>>>>>>>>>>> There's no difference.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
> >>>>>>>>>>>>>>>> "can
> >>>>>>>>>>>>>>>> only" handle packets with full checksum.
> >>>>>>>>>>>>>>> This seems to be odd.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Driver can always handle packet with full checksum, no?
> >>>>>>>>>>>>>> Yes.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I meant it
> >>>>>>>>>>>>>>> will be then to be functional equivalent to !
> >>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
> >>>>>>>>>>>>>> Are you referring to
> >>>>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
> >>>>>>>>>>>>> Sorry, this is a typo. I meant
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Are you referring to
> >>>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> If so, I think it's no.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Maybe a description similar to the following would be more clearer:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
> >>>>>>>>>>>>>> packets with partial checksum.
> >>>>>>>>>>>> I may miss something here, but what's the difference between
> >>>>>>>>>>>>
> >>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM
> >>>>>>>>>>>>
> >>>>>>>>>>>> and
> >>>>>>>>>>>>
> >>>>>>>>>>>> !VIRTIO_NET_F_GUEST_CSUM?
> >>>>>>>>>>>      From the device perspective:
> >>>>>>>>>>>
> >>>>>>>>>>> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
> >>>>>>>>>>> checksum to the driver,
> >>>>>>>>>>> but the device can not validate the checksum for these packets. That is,
> >>>>>>>>>>> the flags in virtio-net-hdr
> >>>>>>>>>>> will not contain _DATA_VALID, and the driver or stack needs to validate
> >>>>>>>>>>> these packets.
> >>>>>>>>>>>
> >>>>>>>>>>> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
> >>>>>>>>>>> checksum to the driver,
> >>>>>>>>>>> and the device can validate the checksum for these packets. That is, the
> >>>>>>>>>>> flags in virtio-net-hdr
> >>>>>>>>>>> will contain _DATA_VALID,
> >>>>>>>>>> I think DATA_VALID is optional here as device can't recognize all type
> >>>>>>>>>> of protocols.
> >>>>>>>>> Yes, you are right, so I used "device *can*" here. Which packet types
> >>>>>>>>> the device recognizes or validates
> >>>>>>>>> depends on the device's implementation. This is also the current
> >>>>>>>>> practice of GUEST_CSUM.
> >>>>>>>>>
> >>>>>>>>>>> and the driver or stack does not need to
> >>>>>>>>>>> validate these packets.
> >>>>>>>>>> Ok, so I think there're something that is subtle here,
> >>>>>>>>> Ok, I see.
> >>>>>>>>>
> >>>>>>>>>> and that's why
> >>>>>>>>>> I'm asking here:
> >>>>>>>>>>
> >>>>>>>>>> 1) "Driver does not handle packets with partial checksum" is not
> >>>>>>>>>> accurate, !GUEST_CUSM also fit for this definition.
> >>>>>>>>>> 2) "Driver handles packets with full checksum" is kind of ambiguous as
> >>>>>>>>>> it doesn't say whether or not the packet has been validated or not.
> >>>>>>>>> Maybe the description below would be less subtle?
> >>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
> >>>>>>>>> checksum or full checksum.
> >>>>>>>> I'd suggest to leave it as is. As I didn't find any issue since even
> >>>>>>>> with DATA_VALID. Did you?
> >>>>>>>>
> >>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
> >>>>>>>>> with full checksum,
> >>>>>>>>> and the device optionally validates the packet's checksum.
> >>>>>>>> Or maybe something like (not a native speaker)
> >>>>>>>>
> >>>>>>>> The driver handles packets with full checksum which the device has
> >>>>>>>> already validated.
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>> I feel we just need a proper definition of what does "full checksum"
> >>>>>>> mean in this context. It is used but not defined.
> >>>>>>> Assume this feature was negotiated.
> >>>>>>> My understanding is that this is just like VIRTIO_NET_F_GUEST_CSUM
> >>>>>>> but certain values in the header are then disallowed? Which?
> >>>>>>> This should be in the spec.
> >>>>>> Yes, I think it is probably the headers that DATA_VALID can work. We
> >>>>>> never define it in the past.
> >>>>>>
> >>>>>> E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY, but it can
> >>>>>> only work for some specific protocols:
> >>>>>>
> >>>>>> """
> >>>>>>     *   %CHECKSUM_UNNECESSARY is applicable to following protocols:
> >>>>>>     *
> >>>>>>     *     - TCP: IPv6 and IPv4.
> >>>>>>     *     - UDP: IPv4 and IPv6. A device may apply CHECKSUM_UNNECESSARY to a
> >>>>>>     *       zero UDP checksum for either IPv4 or IPv6, the networking stack
> >>>>>>     *       may perform further validation in this case.
> >>>>>>     *     - GRE: only if the checksum is present in the header.
> >>>>>>     *     - SCTP: indicates the CRC in SCTP header has been validated.
> >>>>>>     *     - FCOE: indicates the CRC in FC frame has been validated.
> >>>>>> """
> >>>>>>
> >>>>>> I'm not sure whether it's just fine to duplicate the definition or
> >>>>>> it's too late to define any now.
> >>>>> I think it's mostly harmless for other protocols.
> >>>> I'm not sure if this should be defined by a new FULL_CSUM feature.
> >>>> This seems to be an issue with GUEST_CSUM.
> >>>>
> >>>> I think we should supplement these with a new patch for GUEST_CSUM?
> >>> Probably. My understanding is:
> >>>
> >>> You want to reuse DATA_VALID here, so we need to stick to a consistent
> >>> semantic for GUEST_CUSM and FULL_CSUM. So we need a definition of
> >>> "full csum" or what kind of packet could DATA_VALID work here.
> >> I agree, we can be clear about what types of packets DATA_VALID might
> >> cover, e.g. TCP/UDP/GRE/SCTP/FoCE.
> >>
> >> But I think we also need something like \field{supported_validate_types} to
> >> indicate which packet types the device supports validating and setting
> >> DATA_VALID,
> >> otherwise the device driver that negotiates this feature may fail to live
> >> migration.
> >> Am I right?
> >>
> >> I'm not sure how GUEST_CSUM works now as it should also suffer from the
> >> above
> >> mentioned issues with live migration, but no devices are reporting this
> >> right now.
> >>
> >> Maybe, each device only supports checksum verification for TCP/UDP by
> >> default? I don't know.
> >> But I hope we can focus on this and get consensus, because our hw release
> >> date is coming soon.
> >>
> >> Thanks a lot!
> >
> > First, DATA_VALID is not a thing that hardware should ever use.
> > It's a hack when packets are passed within host.
>
> Get here. Thanks!

So if I understand correctly, we need a new flag here and define the
supported protocols.

Thanks

>
> > Second I don't understand what it has to do with this
> > discussion.
> > Your patch should be more specific and define which
> > header fields are compatible with the new offload option.
> >
> >
> >
> >>> Thanks
> >>>
> >>>> Thanks!
> >>>>
> >>>>>>> After this is written up we will come up with a good short
> >>>>>>> description for the feature bit.
> >>>>>>>
> >>>>>> Thanks
> >>>>>>
> >>>>>>>>> Thanks!
> >>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>>>
> >>>>>>>>>>> Thanks!
> >>>>>>>>>>>
> >>>>>>>>>>>> Thanks
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks!
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thanks
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thanks!
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Thanks
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
> >>>>>>>>>>>>>>>>>>                 reconfiguration support.
> >>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>> 2.19.1.6.gb485710b
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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/
> >>>>>>>>>>> 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/
> >>>>>>>>>>>
> >>>>>>>>> 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/
> >>>>>>>>>
> >
> > 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/
>


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Heng Qi]

在 2023/12/6 下午12:36, Jason Wang 写道:
> On Wed, Dec 6, 2023 at 10:21 AM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>
>>
>> 在 2023/12/5 下午10:45, Michael S. Tsirkin 写道:
>>> On Tue, Dec 05, 2023 at 10:18:32PM +0800, Heng Qi wrote:
>>>> 在 2023/12/5 上午11:52, Jason Wang 写道:
>>>>> On Mon, Dec 4, 2023 at 5:34 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>>> 在 2023/12/4 下午5:05, Michael S. Tsirkin 写道:
>>>>>>> On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
>>>>>>>> On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>>>>>>>>> On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
>>>>>>>>>> On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>> 在 2023/12/4 下午3:18, Jason Wang 写道:
>>>>>>>>>>>> On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>>>> 在 2023/12/1 下午3:05, Jason Wang 写道:
>>>>>>>>>>>>>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>>>>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
>>>>>>>>>>>>>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
>>>>>>>>>>>>>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
>>>>>>>>>>>>>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> To prevent readers from misunderstanding that the driver can
>>>>>>>>>>>>>>>>>>>> only handles packets with partial checksum when
>>>>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>>>>          device-types/net/description.tex | 2 +-
>>>>>>>>>>>>>>>>>>>>          1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> diff --git a/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>> b/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>> index aff5e08..529f470 100644
>>>>>>>>>>>>>>>>>>>> --- a/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>> +++ b/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
>>>>>>>>>>>>>>>>>>>> / Network Device / Feature bits
>>>>>>>>>>>>>>>>>>>>          \begin{description}
>>>>>>>>>>>>>>>>>>>>          \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
>>>>>>>>>>>>>>>>>>>> partial checksum offload.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
>>>>>>>>>>>>>>>>>>>> partial checksum.
>>>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
>>>>>>>>>>>>>>>>>>>> partial checksum or full checksum.
>>>>>>>>>>>>>>>>>>> So patch 2 said
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> "
>>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
>>>>>>>>>>>>>>>>>>> full checksum.
>>>>>>>>>>>>>>>>>>>          \end{description}
>>>>>>>>>>>>>>>>>>> "
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Is there any difference between the two "full checksum" here?
>>>>>>>>>>>>>>>>>> There's no difference.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
>>>>>>>>>>>>>>>>>> "can
>>>>>>>>>>>>>>>>>> only" handle packets with full checksum.
>>>>>>>>>>>>>>>>> This seems to be odd.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Driver can always handle packet with full checksum, no?
>>>>>>>>>>>>>>>> Yes.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I meant it
>>>>>>>>>>>>>>>>> will be then to be functional equivalent to !
>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
>>>>>>>>>>>>>>>> Are you referring to
>>>>>>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
>>>>>>>>>>>>>>> Sorry, this is a typo. I meant
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Are you referring to
>>>>>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If so, I think it's no.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Maybe a description similar to the following would be more clearer:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
>>>>>>>>>>>>>>>> packets with partial checksum.
>>>>>>>>>>>>>> I may miss something here, but what's the difference between
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> !VIRTIO_NET_F_GUEST_CSUM?
>>>>>>>>>>>>>       From the device perspective:
>>>>>>>>>>>>>
>>>>>>>>>>>>> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
>>>>>>>>>>>>> checksum to the driver,
>>>>>>>>>>>>> but the device can not validate the checksum for these packets. That is,
>>>>>>>>>>>>> the flags in virtio-net-hdr
>>>>>>>>>>>>> will not contain _DATA_VALID, and the driver or stack needs to validate
>>>>>>>>>>>>> these packets.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
>>>>>>>>>>>>> checksum to the driver,
>>>>>>>>>>>>> and the device can validate the checksum for these packets. That is, the
>>>>>>>>>>>>> flags in virtio-net-hdr
>>>>>>>>>>>>> will contain _DATA_VALID,
>>>>>>>>>>>> I think DATA_VALID is optional here as device can't recognize all type
>>>>>>>>>>>> of protocols.
>>>>>>>>>>> Yes, you are right, so I used "device *can*" here. Which packet types
>>>>>>>>>>> the device recognizes or validates
>>>>>>>>>>> depends on the device's implementation. This is also the current
>>>>>>>>>>> practice of GUEST_CSUM.
>>>>>>>>>>>
>>>>>>>>>>>>> and the driver or stack does not need to
>>>>>>>>>>>>> validate these packets.
>>>>>>>>>>>> Ok, so I think there're something that is subtle here,
>>>>>>>>>>> Ok, I see.
>>>>>>>>>>>
>>>>>>>>>>>> and that's why
>>>>>>>>>>>> I'm asking here:
>>>>>>>>>>>>
>>>>>>>>>>>> 1) "Driver does not handle packets with partial checksum" is not
>>>>>>>>>>>> accurate, !GUEST_CUSM also fit for this definition.
>>>>>>>>>>>> 2) "Driver handles packets with full checksum" is kind of ambiguous as
>>>>>>>>>>>> it doesn't say whether or not the packet has been validated or not.
>>>>>>>>>>> Maybe the description below would be less subtle?
>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
>>>>>>>>>>> checksum or full checksum.
>>>>>>>>>> I'd suggest to leave it as is. As I didn't find any issue since even
>>>>>>>>>> with DATA_VALID. Did you?
>>>>>>>>>>
>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
>>>>>>>>>>> with full checksum,
>>>>>>>>>>> and the device optionally validates the packet's checksum.
>>>>>>>>>> Or maybe something like (not a native speaker)
>>>>>>>>>>
>>>>>>>>>> The driver handles packets with full checksum which the device has
>>>>>>>>>> already validated.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>> I feel we just need a proper definition of what does "full checksum"
>>>>>>>>> mean in this context. It is used but not defined.
>>>>>>>>> Assume this feature was negotiated.
>>>>>>>>> My understanding is that this is just like VIRTIO_NET_F_GUEST_CSUM
>>>>>>>>> but certain values in the header are then disallowed? Which?
>>>>>>>>> This should be in the spec.
>>>>>>>> Yes, I think it is probably the headers that DATA_VALID can work. We
>>>>>>>> never define it in the past.
>>>>>>>>
>>>>>>>> E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY, but it can
>>>>>>>> only work for some specific protocols:
>>>>>>>>
>>>>>>>> """
>>>>>>>>      *   %CHECKSUM_UNNECESSARY is applicable to following protocols:
>>>>>>>>      *
>>>>>>>>      *     - TCP: IPv6 and IPv4.
>>>>>>>>      *     - UDP: IPv4 and IPv6. A device may apply CHECKSUM_UNNECESSARY to a
>>>>>>>>      *       zero UDP checksum for either IPv4 or IPv6, the networking stack
>>>>>>>>      *       may perform further validation in this case.
>>>>>>>>      *     - GRE: only if the checksum is present in the header.
>>>>>>>>      *     - SCTP: indicates the CRC in SCTP header has been validated.
>>>>>>>>      *     - FCOE: indicates the CRC in FC frame has been validated.
>>>>>>>> """
>>>>>>>>
>>>>>>>> I'm not sure whether it's just fine to duplicate the definition or
>>>>>>>> it's too late to define any now.
>>>>>>> I think it's mostly harmless for other protocols.
>>>>>> I'm not sure if this should be defined by a new FULL_CSUM feature.
>>>>>> This seems to be an issue with GUEST_CSUM.
>>>>>>
>>>>>> I think we should supplement these with a new patch for GUEST_CSUM?
>>>>> Probably. My understanding is:
>>>>>
>>>>> You want to reuse DATA_VALID here, so we need to stick to a consistent
>>>>> semantic for GUEST_CUSM and FULL_CSUM. So we need a definition of
>>>>> "full csum" or what kind of packet could DATA_VALID work here.
>>>> I agree, we can be clear about what types of packets DATA_VALID might
>>>> cover, e.g. TCP/UDP/GRE/SCTP/FoCE.
>>>>
>>>> But I think we also need something like \field{supported_validate_types} to
>>>> indicate which packet types the device supports validating and setting
>>>> DATA_VALID,
>>>> otherwise the device driver that negotiates this feature may fail to live
>>>> migration.
>>>> Am I right?
>>>>
>>>> I'm not sure how GUEST_CSUM works now as it should also suffer from the
>>>> above
>>>> mentioned issues with live migration, but no devices are reporting this
>>>> right now.
>>>>
>>>> Maybe, each device only supports checksum verification for TCP/UDP by
>>>> default? I don't know.
>>>> But I hope we can focus on this and get consensus, because our hw release
>>>> date is coming soon.
>>>>
>>>> Thanks a lot!
>>> First, DATA_VALID is not a thing that hardware should ever use.
>>> It's a hack when packets are passed within host.
>> Get here. Thanks!
> So if I understand correctly, we need a new flag here and define the
> supported protocols.

Seems not, I understand what Michael means is that we don't need 
supported_validate_types.
Because DATA_VALID is set per packet, similar to streaming. From the 
perspective of the driver
and the device, there is no need to know which packet types the device 
supports setting DATA_VALID for.
We just need to know what packet types DATA_VALID might cover. Is this 
aligning, Michael?

Hi Xuan! WDYT?

Thanks!

>
> Thanks
>
>>> Second I don't understand what it has to do with this
>>> discussion.
>>> Your patch should be more specific and define which
>>> header fields are compatible with the new offload option.
>>>
>>>
>>>
>>>>> Thanks
>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>>>> After this is written up we will come up with a good short
>>>>>>>>> description for the feature bit.
>>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
>>>>>>>>>>>>>>>>>>>>                  reconfiguration support.
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> 2.19.1.6.gb485710b
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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/
>>>>>>>>>>>>> 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/
>>>>>>>>>>>>>
>>>>>>>>>>> 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/
>>>>>>>>>>>
>>> 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/
>
> 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/


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Michael S. Tsirkin]

On Wed, Dec 06, 2023 at 12:51:32PM +0800, Heng Qi wrote:
> 
> 
> 在 2023/12/6 下午12:36, Jason Wang 写道:
> > On Wed, Dec 6, 2023 at 10:21 AM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > 
> > > 
> > > 在 2023/12/5 下午10:45, Michael S. Tsirkin 写道:
> > > > On Tue, Dec 05, 2023 at 10:18:32PM +0800, Heng Qi wrote:
> > > > > 在 2023/12/5 上午11:52, Jason Wang 写道:
> > > > > > On Mon, Dec 4, 2023 at 5:34 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > > > > > 在 2023/12/4 下午5:05, Michael S. Tsirkin 写道:
> > > > > > > > On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
> > > > > > > > > On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > > > > > > On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
> > > > > > > > > > > On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > > > > > > > > > > 在 2023/12/4 下午3:18, Jason Wang 写道:
> > > > > > > > > > > > > On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > > > > > > > > > > > > 在 2023/12/1 下午3:05, Jason Wang 写道:
> > > > > > > > > > > > > > > On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > > > > > > > > > > > > > > 在 2023/12/1 下午2:24, Heng Qi 写道:
> > > > > > > > > > > > > > > > > 在 2023/12/1 下午1:18, Jason Wang 写道:
> > > > > > > > > > > > > > > > > > On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > 在 2023/11/29 下午4:00, Jason Wang 写道:
> > > > > > > > > > > > > > > > > > > > On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > To prevent readers from misunderstanding that the driver can
> > > > > > > > > > > > > > > > > > > > > only handles packets with partial checksum when
> > > > > > > > > > > > > > > > > > > > > VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> > > > > > > > > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > > > > > > > >          device-types/net/description.tex | 2 +-
> > > > > > > > > > > > > > > > > > > > >          1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > diff --git a/device-types/net/description.tex
> > > > > > > > > > > > > > > > > > > > > b/device-types/net/description.tex
> > > > > > > > > > > > > > > > > > > > > index aff5e08..529f470 100644
> > > > > > > > > > > > > > > > > > > > > --- a/device-types/net/description.tex
> > > > > > > > > > > > > > > > > > > > > +++ b/device-types/net/description.tex
> > > > > > > > > > > > > > > > > > > > > @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
> > > > > > > > > > > > > > > > > > > > > / Network Device / Feature bits
> > > > > > > > > > > > > > > > > > > > >          \begin{description}
> > > > > > > > > > > > > > > > > > > > >          \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
> > > > > > > > > > > > > > > > > > > > > partial checksum offload.
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> > > > > > > > > > > > > > > > > > > > > partial checksum.
> > > > > > > > > > > > > > > > > > > > > +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> > > > > > > > > > > > > > > > > > > > > partial checksum or full checksum.
> > > > > > > > > > > > > > > > > > > > So patch 2 said
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > "
> > > > > > > > > > > > > > > > > > > > +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
> > > > > > > > > > > > > > > > > > > > full checksum.
> > > > > > > > > > > > > > > > > > > >          \end{description}
> > > > > > > > > > > > > > > > > > > > "
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > Is there any difference between the two "full checksum" here?
> > > > > > > > > > > > > > > > > > > There's no difference.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
> > > > > > > > > > > > > > > > > > > "can
> > > > > > > > > > > > > > > > > > > only" handle packets with full checksum.
> > > > > > > > > > > > > > > > > > This seems to be odd.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Driver can always handle packet with full checksum, no?
> > > > > > > > > > > > > > > > > Yes.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > I meant it
> > > > > > > > > > > > > > > > > > will be then to be functional equivalent to !
> > > > > > > > > > > > > > > > > > VIRTIO_NET_F_GUEST_FULL_CSUM?
> > > > > > > > > > > > > > > > > Are you referring to
> > > > > > > > > > > > > > > > > "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
> > > > > > > > > > > > > > > > Sorry, this is a typo. I meant
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Are you referring to
> > > > > > > > > > > > > > > > "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > If so, I think it's no.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Maybe a description similar to the following would be more clearer:
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
> > > > > > > > > > > > > > > > > packets with partial checksum.
> > > > > > > > > > > > > > > I may miss something here, but what's the difference between
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > VIRTIO_NET_F_GUEST_FULL_CSUM
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > !VIRTIO_NET_F_GUEST_CSUM?
> > > > > > > > > > > > > >       From the device perspective:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
> > > > > > > > > > > > > > checksum to the driver,
> > > > > > > > > > > > > > but the device can not validate the checksum for these packets. That is,
> > > > > > > > > > > > > > the flags in virtio-net-hdr
> > > > > > > > > > > > > > will not contain _DATA_VALID, and the driver or stack needs to validate
> > > > > > > > > > > > > > these packets.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
> > > > > > > > > > > > > > checksum to the driver,
> > > > > > > > > > > > > > and the device can validate the checksum for these packets. That is, the
> > > > > > > > > > > > > > flags in virtio-net-hdr
> > > > > > > > > > > > > > will contain _DATA_VALID,
> > > > > > > > > > > > > I think DATA_VALID is optional here as device can't recognize all type
> > > > > > > > > > > > > of protocols.
> > > > > > > > > > > > Yes, you are right, so I used "device *can*" here. Which packet types
> > > > > > > > > > > > the device recognizes or validates
> > > > > > > > > > > > depends on the device's implementation. This is also the current
> > > > > > > > > > > > practice of GUEST_CSUM.
> > > > > > > > > > > > 
> > > > > > > > > > > > > > and the driver or stack does not need to
> > > > > > > > > > > > > > validate these packets.
> > > > > > > > > > > > > Ok, so I think there're something that is subtle here,
> > > > > > > > > > > > Ok, I see.
> > > > > > > > > > > > 
> > > > > > > > > > > > > and that's why
> > > > > > > > > > > > > I'm asking here:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 1) "Driver does not handle packets with partial checksum" is not
> > > > > > > > > > > > > accurate, !GUEST_CUSM also fit for this definition.
> > > > > > > > > > > > > 2) "Driver handles packets with full checksum" is kind of ambiguous as
> > > > > > > > > > > > > it doesn't say whether or not the packet has been validated or not.
> > > > > > > > > > > > Maybe the description below would be less subtle?
> > > > > > > > > > > > +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
> > > > > > > > > > > > checksum or full checksum.
> > > > > > > > > > > I'd suggest to leave it as is. As I didn't find any issue since even
> > > > > > > > > > > with DATA_VALID. Did you?
> > > > > > > > > > > 
> > > > > > > > > > > > +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
> > > > > > > > > > > > with full checksum,
> > > > > > > > > > > > and the device optionally validates the packet's checksum.
> > > > > > > > > > > Or maybe something like (not a native speaker)
> > > > > > > > > > > 
> > > > > > > > > > > The driver handles packets with full checksum which the device has
> > > > > > > > > > > already validated.
> > > > > > > > > > > 
> > > > > > > > > > > Thanks
> > > > > > > > > > I feel we just need a proper definition of what does "full checksum"
> > > > > > > > > > mean in this context. It is used but not defined.
> > > > > > > > > > Assume this feature was negotiated.
> > > > > > > > > > My understanding is that this is just like VIRTIO_NET_F_GUEST_CSUM
> > > > > > > > > > but certain values in the header are then disallowed? Which?
> > > > > > > > > > This should be in the spec.
> > > > > > > > > Yes, I think it is probably the headers that DATA_VALID can work. We
> > > > > > > > > never define it in the past.
> > > > > > > > > 
> > > > > > > > > E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY, but it can
> > > > > > > > > only work for some specific protocols:
> > > > > > > > > 
> > > > > > > > > """
> > > > > > > > >      *   %CHECKSUM_UNNECESSARY is applicable to following protocols:
> > > > > > > > >      *
> > > > > > > > >      *     - TCP: IPv6 and IPv4.
> > > > > > > > >      *     - UDP: IPv4 and IPv6. A device may apply CHECKSUM_UNNECESSARY to a
> > > > > > > > >      *       zero UDP checksum for either IPv4 or IPv6, the networking stack
> > > > > > > > >      *       may perform further validation in this case.
> > > > > > > > >      *     - GRE: only if the checksum is present in the header.
> > > > > > > > >      *     - SCTP: indicates the CRC in SCTP header has been validated.
> > > > > > > > >      *     - FCOE: indicates the CRC in FC frame has been validated.
> > > > > > > > > """
> > > > > > > > > 
> > > > > > > > > I'm not sure whether it's just fine to duplicate the definition or
> > > > > > > > > it's too late to define any now.
> > > > > > > > I think it's mostly harmless for other protocols.
> > > > > > > I'm not sure if this should be defined by a new FULL_CSUM feature.
> > > > > > > This seems to be an issue with GUEST_CSUM.
> > > > > > > 
> > > > > > > I think we should supplement these with a new patch for GUEST_CSUM?
> > > > > > Probably. My understanding is:
> > > > > > 
> > > > > > You want to reuse DATA_VALID here, so we need to stick to a consistent
> > > > > > semantic for GUEST_CUSM and FULL_CSUM. So we need a definition of
> > > > > > "full csum" or what kind of packet could DATA_VALID work here.
> > > > > I agree, we can be clear about what types of packets DATA_VALID might
> > > > > cover, e.g. TCP/UDP/GRE/SCTP/FoCE.
> > > > > 
> > > > > But I think we also need something like \field{supported_validate_types} to
> > > > > indicate which packet types the device supports validating and setting
> > > > > DATA_VALID,
> > > > > otherwise the device driver that negotiates this feature may fail to live
> > > > > migration.
> > > > > Am I right?
> > > > > 
> > > > > I'm not sure how GUEST_CSUM works now as it should also suffer from the
> > > > > above
> > > > > mentioned issues with live migration, but no devices are reporting this
> > > > > right now.
> > > > > 
> > > > > Maybe, each device only supports checksum verification for TCP/UDP by
> > > > > default? I don't know.
> > > > > But I hope we can focus on this and get consensus, because our hw release
> > > > > date is coming soon.
> > > > > 
> > > > > Thanks a lot!
> > > > First, DATA_VALID is not a thing that hardware should ever use.
> > > > It's a hack when packets are passed within host.
> > > Get here. Thanks!
> > So if I understand correctly, we need a new flag here and define the
> > supported protocols.
> 
> Seems not, I understand what Michael means is that we don't need
> supported_validate_types.
> Because DATA_VALID is set per packet, similar to streaming. From the
> perspective of the driver
> and the device, there is no need to know which packet types the device
> supports setting DATA_VALID for.
> We just need to know what packet types DATA_VALID might cover. Is this
> aligning, Michael?

I don't know if it's even that. IIRC DATA_VALID mostly just means "this
packet is local, don't worry about checksums".
That being said I don't see how improving the description here
is related to the discussion around XDP.


> Hi Xuan! WDYT?
> 
> Thanks!
> 
> > 
> > Thanks
> > 
> > > > Second I don't understand what it has to do with this
> > > > discussion.
> > > > Your patch should be more specific and define which
> > > > header fields are compatible with the new offload option.
> > > > 
> > > > 
> > > > 
> > > > > > Thanks
> > > > > > 
> > > > > > > Thanks!
> > > > > > > 
> > > > > > > > > > After this is written up we will come up with a good short
> > > > > > > > > > description for the feature bit.
> > > > > > > > > > 
> > > > > > > > > Thanks
> > > > > > > > > 
> > > > > > > > > > > > Thanks!
> > > > > > > > > > > > 
> > > > > > > > > > > > > Thanks
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > Thanks!
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Thanks
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Thanks!
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Thanks
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Thanks!
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > Thanks
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
> > > > > > > > > > > > > > > > > > > > >                  reconfiguration support.
> > > > > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > > > > 2.19.1.6.gb485710b
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > 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/
> > > > > > > > > > > > > > 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/
> > > > > > > > > > > > > > 
> > > > > > > > > > > > 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/
> > > > > > > > > > > > 
> > > > 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/
> > 
> > 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/


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Xuan Zhuo]

On Wed, 6 Dec 2023 01:51:48 -0500, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, Dec 06, 2023 at 12:51:32PM +0800, Heng Qi wrote:
> >
> >
> > 在 2023/12/6 下午12:36, Jason Wang 写道:
> > > On Wed, Dec 6, 2023 at 10:21 AM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > >
> > > >
> > > > 在 2023/12/5 下午10:45, Michael S. Tsirkin 写道:
> > > > > On Tue, Dec 05, 2023 at 10:18:32PM +0800, Heng Qi wrote:
> > > > > > 在 2023/12/5 上午11:52, Jason Wang 写道:
> > > > > > > On Mon, Dec 4, 2023 at 5:34 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > > > > > > 在 2023/12/4 下午5:05, Michael S. Tsirkin 写道:
> > > > > > > > > On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
> > > > > > > > > > On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > > > > > > > On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
> > > > > > > > > > > > On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > > > > > > > > > > > 在 2023/12/4 下午3:18, Jason Wang 写道:
> > > > > > > > > > > > > > On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > > > > > > > > > > > > > 在 2023/12/1 下午3:05, Jason Wang 写道:
> > > > > > > > > > > > > > > > On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > > > > > > > > > > > > > > > 在 2023/12/1 下午2:24, Heng Qi 写道:
> > > > > > > > > > > > > > > > > > 在 2023/12/1 下午1:18, Jason Wang 写道:
> > > > > > > > > > > > > > > > > > > On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
> > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > 在 2023/11/29 下午4:00, Jason Wang 写道:
> > > > > > > > > > > > > > > > > > > > > On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
> > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > To prevent readers from misunderstanding that the driver can
> > > > > > > > > > > > > > > > > > > > > > only handles packets with partial checksum when
> > > > > > > > > > > > > > > > > > > > > > VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> > > > > > > > > > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > > > > > > > > >          device-types/net/description.tex | 2 +-
> > > > > > > > > > > > > > > > > > > > > >          1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > diff --git a/device-types/net/description.tex
> > > > > > > > > > > > > > > > > > > > > > b/device-types/net/description.tex
> > > > > > > > > > > > > > > > > > > > > > index aff5e08..529f470 100644
> > > > > > > > > > > > > > > > > > > > > > --- a/device-types/net/description.tex
> > > > > > > > > > > > > > > > > > > > > > +++ b/device-types/net/description.tex
> > > > > > > > > > > > > > > > > > > > > > @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
> > > > > > > > > > > > > > > > > > > > > > / Network Device / Feature bits
> > > > > > > > > > > > > > > > > > > > > >          \begin{description}
> > > > > > > > > > > > > > > > > > > > > >          \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
> > > > > > > > > > > > > > > > > > > > > > partial checksum offload.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> > > > > > > > > > > > > > > > > > > > > > partial checksum.
> > > > > > > > > > > > > > > > > > > > > > +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> > > > > > > > > > > > > > > > > > > > > > partial checksum or full checksum.
> > > > > > > > > > > > > > > > > > > > > So patch 2 said
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > "
> > > > > > > > > > > > > > > > > > > > > +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
> > > > > > > > > > > > > > > > > > > > > full checksum.
> > > > > > > > > > > > > > > > > > > > >          \end{description}
> > > > > > > > > > > > > > > > > > > > > "
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Is there any difference between the two "full checksum" here?
> > > > > > > > > > > > > > > > > > > > There's no difference.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
> > > > > > > > > > > > > > > > > > > > "can
> > > > > > > > > > > > > > > > > > > > only" handle packets with full checksum.
> > > > > > > > > > > > > > > > > > > This seems to be odd.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Driver can always handle packet with full checksum, no?
> > > > > > > > > > > > > > > > > > Yes.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I meant it
> > > > > > > > > > > > > > > > > > > will be then to be functional equivalent to !
> > > > > > > > > > > > > > > > > > > VIRTIO_NET_F_GUEST_FULL_CSUM?
> > > > > > > > > > > > > > > > > > Are you referring to
> > > > > > > > > > > > > > > > > > "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
> > > > > > > > > > > > > > > > > Sorry, this is a typo. I meant
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Are you referring to
> > > > > > > > > > > > > > > > > "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > If so, I think it's no.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Maybe a description similar to the following would be more clearer:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
> > > > > > > > > > > > > > > > > > packets with partial checksum.
> > > > > > > > > > > > > > > > I may miss something here, but what's the difference between
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > VIRTIO_NET_F_GUEST_FULL_CSUM
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > !VIRTIO_NET_F_GUEST_CSUM?
> > > > > > > > > > > > > > >       From the device perspective:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
> > > > > > > > > > > > > > > checksum to the driver,
> > > > > > > > > > > > > > > but the device can not validate the checksum for these packets. That is,
> > > > > > > > > > > > > > > the flags in virtio-net-hdr
> > > > > > > > > > > > > > > will not contain _DATA_VALID, and the driver or stack needs to validate
> > > > > > > > > > > > > > > these packets.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
> > > > > > > > > > > > > > > checksum to the driver,
> > > > > > > > > > > > > > > and the device can validate the checksum for these packets. That is, the
> > > > > > > > > > > > > > > flags in virtio-net-hdr
> > > > > > > > > > > > > > > will contain _DATA_VALID,
> > > > > > > > > > > > > > I think DATA_VALID is optional here as device can't recognize all type
> > > > > > > > > > > > > > of protocols.
> > > > > > > > > > > > > Yes, you are right, so I used "device *can*" here. Which packet types
> > > > > > > > > > > > > the device recognizes or validates
> > > > > > > > > > > > > depends on the device's implementation. This is also the current
> > > > > > > > > > > > > practice of GUEST_CSUM.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > and the driver or stack does not need to
> > > > > > > > > > > > > > > validate these packets.
> > > > > > > > > > > > > > Ok, so I think there're something that is subtle here,
> > > > > > > > > > > > > Ok, I see.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > and that's why
> > > > > > > > > > > > > > I'm asking here:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 1) "Driver does not handle packets with partial checksum" is not
> > > > > > > > > > > > > > accurate, !GUEST_CUSM also fit for this definition.
> > > > > > > > > > > > > > 2) "Driver handles packets with full checksum" is kind of ambiguous as
> > > > > > > > > > > > > > it doesn't say whether or not the packet has been validated or not.
> > > > > > > > > > > > > Maybe the description below would be less subtle?
> > > > > > > > > > > > > +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
> > > > > > > > > > > > > checksum or full checksum.
> > > > > > > > > > > > I'd suggest to leave it as is. As I didn't find any issue since even
> > > > > > > > > > > > with DATA_VALID. Did you?
> > > > > > > > > > > >
> > > > > > > > > > > > > +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
> > > > > > > > > > > > > with full checksum,
> > > > > > > > > > > > > and the device optionally validates the packet's checksum.
> > > > > > > > > > > > Or maybe something like (not a native speaker)
> > > > > > > > > > > >
> > > > > > > > > > > > The driver handles packets with full checksum which the device has
> > > > > > > > > > > > already validated.
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks
> > > > > > > > > > > I feel we just need a proper definition of what does "full checksum"
> > > > > > > > > > > mean in this context. It is used but not defined.
> > > > > > > > > > > Assume this feature was negotiated.
> > > > > > > > > > > My understanding is that this is just like VIRTIO_NET_F_GUEST_CSUM
> > > > > > > > > > > but certain values in the header are then disallowed? Which?
> > > > > > > > > > > This should be in the spec.
> > > > > > > > > > Yes, I think it is probably the headers that DATA_VALID can work. We
> > > > > > > > > > never define it in the past.
> > > > > > > > > >
> > > > > > > > > > E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY, but it can
> > > > > > > > > > only work for some specific protocols:
> > > > > > > > > >
> > > > > > > > > > """
> > > > > > > > > >      *   %CHECKSUM_UNNECESSARY is applicable to following protocols:
> > > > > > > > > >      *
> > > > > > > > > >      *     - TCP: IPv6 and IPv4.
> > > > > > > > > >      *     - UDP: IPv4 and IPv6. A device may apply CHECKSUM_UNNECESSARY to a
> > > > > > > > > >      *       zero UDP checksum for either IPv4 or IPv6, the networking stack
> > > > > > > > > >      *       may perform further validation in this case.
> > > > > > > > > >      *     - GRE: only if the checksum is present in the header.
> > > > > > > > > >      *     - SCTP: indicates the CRC in SCTP header has been validated.
> > > > > > > > > >      *     - FCOE: indicates the CRC in FC frame has been validated.
> > > > > > > > > > """
> > > > > > > > > >
> > > > > > > > > > I'm not sure whether it's just fine to duplicate the definition or
> > > > > > > > > > it's too late to define any now.
> > > > > > > > > I think it's mostly harmless for other protocols.
> > > > > > > > I'm not sure if this should be defined by a new FULL_CSUM feature.
> > > > > > > > This seems to be an issue with GUEST_CSUM.
> > > > > > > >
> > > > > > > > I think we should supplement these with a new patch for GUEST_CSUM?
> > > > > > > Probably. My understanding is:
> > > > > > >
> > > > > > > You want to reuse DATA_VALID here, so we need to stick to a consistent
> > > > > > > semantic for GUEST_CUSM and FULL_CSUM. So we need a definition of
> > > > > > > "full csum" or what kind of packet could DATA_VALID work here.
> > > > > > I agree, we can be clear about what types of packets DATA_VALID might
> > > > > > cover, e.g. TCP/UDP/GRE/SCTP/FoCE.
> > > > > >
> > > > > > But I think we also need something like \field{supported_validate_types} to
> > > > > > indicate which packet types the device supports validating and setting
> > > > > > DATA_VALID,
> > > > > > otherwise the device driver that negotiates this feature may fail to live
> > > > > > migration.
> > > > > > Am I right?
> > > > > >
> > > > > > I'm not sure how GUEST_CSUM works now as it should also suffer from the
> > > > > > above
> > > > > > mentioned issues with live migration, but no devices are reporting this
> > > > > > right now.
> > > > > >
> > > > > > Maybe, each device only supports checksum verification for TCP/UDP by
> > > > > > default? I don't know.
> > > > > > But I hope we can focus on this and get consensus, because our hw release
> > > > > > date is coming soon.
> > > > > >
> > > > > > Thanks a lot!
> > > > > First, DATA_VALID is not a thing that hardware should ever use.
> > > > > It's a hack when packets are passed within host.
> > > > Get here. Thanks!
> > > So if I understand correctly, we need a new flag here and define the
> > > supported protocols.
> >
> > Seems not, I understand what Michael means is that we don't need
> > supported_validate_types.
> > Because DATA_VALID is set per packet, similar to streaming. From the
> > perspective of the driver
> > and the device, there is no need to know which packet types the device
> > supports setting DATA_VALID for.
> > We just need to know what packet types DATA_VALID might cover. Is this
> > aligning, Michael?
>
> I don't know if it's even that. IIRC DATA_VALID mostly just means "this
> packet is local, don't worry about checksums".

	If the VIRTIO_NET_F_GUEST_CSUM feature was negotiated, the
	VIRTIO_NET_HDR_F_DATA_VALID bit in flags can be set: if so, device has
	validated the packet checksum.

So it means "this packet csum is checked, don't worry about checksums".

> That being said I don't see how improving the description here
> is related to the discussion around XDP.
>
>
> > Hi Xuan! WDYT?
> >
> > Thanks!
> >
> > >
> > > Thanks
> > >
> > > > > Second I don't understand what it has to do with this
> > > > > discussion.
> > > > > Your patch should be more specific and define which
> > > > > header fields are compatible with the new offload option.
> > > > >
> > > > >
> > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > > > Thanks!
> > > > > > > >
> > > > > > > > > > > After this is written up we will come up with a good short
> > > > > > > > > > > description for the feature bit.
> > > > > > > > > > >
> > > > > > > > > > Thanks
> > > > > > > > > >
> > > > > > > > > > > > > Thanks!
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thanks!
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Thanks!
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Thanks
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Thanks!
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Thanks
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
> > > > > > > > > > > > > > > > > > > > > >                  reconfiguration support.
> > > > > > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > > > > > 2.19.1.6.gb485710b
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 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/
> > > > > > > > > > > > > > > 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/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > 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/
> > > > > > > > > > > > >
> > > > > 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/
> > >
> > > 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/
>

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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Xuan Zhuo]

On Wed, 6 Dec 2023 12:36:53 +0800, Jason Wang <jasowang@redhat.com> wrote:
> On Wed, Dec 6, 2023 at 10:21 AM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >
> >
> >
> > 在 2023/12/5 下午10:45, Michael S. Tsirkin 写道:
> > > On Tue, Dec 05, 2023 at 10:18:32PM +0800, Heng Qi wrote:
> > >>
> > >> 在 2023/12/5 上午11:52, Jason Wang 写道:
> > >>> On Mon, Dec 4, 2023 at 5:34 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > >>>>
> > >>>> 在 2023/12/4 下午5:05, Michael S. Tsirkin 写道:
> > >>>>> On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
> > >>>>>> On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > >>>>>>> On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
> > >>>>>>>> On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > >>>>>>>>> 在 2023/12/4 下午3:18, Jason Wang 写道:
> > >>>>>>>>>> On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > >>>>>>>>>>> 在 2023/12/1 下午3:05, Jason Wang 写道:
> > >>>>>>>>>>>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > >>>>>>>>>>>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
> > >>>>>>>>>>>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
> > >>>>>>>>>>>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
> > >>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
> > >>>>>>>>>>>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
> > >>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>> To prevent readers from misunderstanding that the driver can
> > >>>>>>>>>>>>>>>>>> only handles packets with partial checksum when
> > >>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> > >>>>>>>>>>>>>>>>>> ---
> > >>>>>>>>>>>>>>>>>>         device-types/net/description.tex | 2 +-
> > >>>>>>>>>>>>>>>>>>         1 file changed, 1 insertion(+), 1 deletion(-)
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> diff --git a/device-types/net/description.tex
> > >>>>>>>>>>>>>>>>>> b/device-types/net/description.tex
> > >>>>>>>>>>>>>>>>>> index aff5e08..529f470 100644
> > >>>>>>>>>>>>>>>>>> --- a/device-types/net/description.tex
> > >>>>>>>>>>>>>>>>>> +++ b/device-types/net/description.tex
> > >>>>>>>>>>>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
> > >>>>>>>>>>>>>>>>>> / Network Device / Feature bits
> > >>>>>>>>>>>>>>>>>>         \begin{description}
> > >>>>>>>>>>>>>>>>>>         \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
> > >>>>>>>>>>>>>>>>>> partial checksum offload.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> > >>>>>>>>>>>>>>>>>> partial checksum.
> > >>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> > >>>>>>>>>>>>>>>>>> partial checksum or full checksum.
> > >>>>>>>>>>>>>>>>> So patch 2 said
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> "
> > >>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
> > >>>>>>>>>>>>>>>>> full checksum.
> > >>>>>>>>>>>>>>>>>         \end{description}
> > >>>>>>>>>>>>>>>>> "
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Is there any difference between the two "full checksum" here?
> > >>>>>>>>>>>>>>>> There's no difference.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
> > >>>>>>>>>>>>>>>> "can
> > >>>>>>>>>>>>>>>> only" handle packets with full checksum.
> > >>>>>>>>>>>>>>> This seems to be odd.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Driver can always handle packet with full checksum, no?
> > >>>>>>>>>>>>>> Yes.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> I meant it
> > >>>>>>>>>>>>>>> will be then to be functional equivalent to !
> > >>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
> > >>>>>>>>>>>>>> Are you referring to
> > >>>>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
> > >>>>>>>>>>>>> Sorry, this is a typo. I meant
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Are you referring to
> > >>>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> If so, I think it's no.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Maybe a description similar to the following would be more clearer:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
> > >>>>>>>>>>>>>> packets with partial checksum.
> > >>>>>>>>>>>> I may miss something here, but what's the difference between
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> and
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> !VIRTIO_NET_F_GUEST_CSUM?
> > >>>>>>>>>>>      From the device perspective:
> > >>>>>>>>>>>
> > >>>>>>>>>>> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
> > >>>>>>>>>>> checksum to the driver,
> > >>>>>>>>>>> but the device can not validate the checksum for these packets. That is,
> > >>>>>>>>>>> the flags in virtio-net-hdr
> > >>>>>>>>>>> will not contain _DATA_VALID, and the driver or stack needs to validate
> > >>>>>>>>>>> these packets.
> > >>>>>>>>>>>
> > >>>>>>>>>>> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
> > >>>>>>>>>>> checksum to the driver,
> > >>>>>>>>>>> and the device can validate the checksum for these packets. That is, the
> > >>>>>>>>>>> flags in virtio-net-hdr
> > >>>>>>>>>>> will contain _DATA_VALID,
> > >>>>>>>>>> I think DATA_VALID is optional here as device can't recognize all type
> > >>>>>>>>>> of protocols.
> > >>>>>>>>> Yes, you are right, so I used "device *can*" here. Which packet types
> > >>>>>>>>> the device recognizes or validates
> > >>>>>>>>> depends on the device's implementation. This is also the current
> > >>>>>>>>> practice of GUEST_CSUM.
> > >>>>>>>>>
> > >>>>>>>>>>> and the driver or stack does not need to
> > >>>>>>>>>>> validate these packets.
> > >>>>>>>>>> Ok, so I think there're something that is subtle here,
> > >>>>>>>>> Ok, I see.
> > >>>>>>>>>
> > >>>>>>>>>> and that's why
> > >>>>>>>>>> I'm asking here:
> > >>>>>>>>>>
> > >>>>>>>>>> 1) "Driver does not handle packets with partial checksum" is not
> > >>>>>>>>>> accurate, !GUEST_CUSM also fit for this definition.
> > >>>>>>>>>> 2) "Driver handles packets with full checksum" is kind of ambiguous as
> > >>>>>>>>>> it doesn't say whether or not the packet has been validated or not.
> > >>>>>>>>> Maybe the description below would be less subtle?
> > >>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
> > >>>>>>>>> checksum or full checksum.
> > >>>>>>>> I'd suggest to leave it as is. As I didn't find any issue since even
> > >>>>>>>> with DATA_VALID. Did you?
> > >>>>>>>>
> > >>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
> > >>>>>>>>> with full checksum,
> > >>>>>>>>> and the device optionally validates the packet's checksum.
> > >>>>>>>> Or maybe something like (not a native speaker)
> > >>>>>>>>
> > >>>>>>>> The driver handles packets with full checksum which the device has
> > >>>>>>>> already validated.
> > >>>>>>>>
> > >>>>>>>> Thanks
> > >>>>>>> I feel we just need a proper definition of what does "full checksum"
> > >>>>>>> mean in this context. It is used but not defined.
> > >>>>>>> Assume this feature was negotiated.
> > >>>>>>> My understanding is that this is just like VIRTIO_NET_F_GUEST_CSUM
> > >>>>>>> but certain values in the header are then disallowed? Which?
> > >>>>>>> This should be in the spec.
> > >>>>>> Yes, I think it is probably the headers that DATA_VALID can work. We
> > >>>>>> never define it in the past.
> > >>>>>>
> > >>>>>> E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY, but it can
> > >>>>>> only work for some specific protocols:
> > >>>>>>
> > >>>>>> """
> > >>>>>>     *   %CHECKSUM_UNNECESSARY is applicable to following protocols:
> > >>>>>>     *
> > >>>>>>     *     - TCP: IPv6 and IPv4.
> > >>>>>>     *     - UDP: IPv4 and IPv6. A device may apply CHECKSUM_UNNECESSARY to a
> > >>>>>>     *       zero UDP checksum for either IPv4 or IPv6, the networking stack
> > >>>>>>     *       may perform further validation in this case.
> > >>>>>>     *     - GRE: only if the checksum is present in the header.
> > >>>>>>     *     - SCTP: indicates the CRC in SCTP header has been validated.
> > >>>>>>     *     - FCOE: indicates the CRC in FC frame has been validated.
> > >>>>>> """
> > >>>>>>
> > >>>>>> I'm not sure whether it's just fine to duplicate the definition or
> > >>>>>> it's too late to define any now.
> > >>>>> I think it's mostly harmless for other protocols.
> > >>>> I'm not sure if this should be defined by a new FULL_CSUM feature.
> > >>>> This seems to be an issue with GUEST_CSUM.
> > >>>>
> > >>>> I think we should supplement these with a new patch for GUEST_CSUM?
> > >>> Probably. My understanding is:
> > >>>
> > >>> You want to reuse DATA_VALID here, so we need to stick to a consistent
> > >>> semantic for GUEST_CUSM and FULL_CSUM. So we need a definition of
> > >>> "full csum" or what kind of packet could DATA_VALID work here.
> > >> I agree, we can be clear about what types of packets DATA_VALID might
> > >> cover, e.g. TCP/UDP/GRE/SCTP/FoCE.
> > >>
> > >> But I think we also need something like \field{supported_validate_types} to
> > >> indicate which packet types the device supports validating and setting
> > >> DATA_VALID,
> > >> otherwise the device driver that negotiates this feature may fail to live
> > >> migration.
> > >> Am I right?
> > >>
> > >> I'm not sure how GUEST_CSUM works now as it should also suffer from the
> > >> above
> > >> mentioned issues with live migration, but no devices are reporting this
> > >> right now.
> > >>
> > >> Maybe, each device only supports checksum verification for TCP/UDP by
> > >> default? I don't know.
> > >> But I hope we can focus on this and get consensus, because our hw release
> > >> date is coming soon.
> > >>
> > >> Thanks a lot!
> > >
> > > First, DATA_VALID is not a thing that hardware should ever use.
> > > It's a hack when packets are passed within host.
> >
> > Get here. Thanks!
>
> So if I understand correctly, we need a new flag here and define the
> supported protocols.


For what, migration?

I don't think so.

Every packet has the flag(valid or none). The guest will check this flag.
If we support this flag in config, the driver need to check this?

For migration, if we want to migrate one from src to dst.
If the src device supports tcp and udp checksum and
the dst device just supports tcp checksum.
I think we should not migrate to this dst device. But this process
does not need the involvement of the driver.

But for describing the supported protocols, I think that is ok.
We lost that for GUEST_CSUM, we should not lost again for the new one.

Thanks.




>
> Thanks
>
> >
> > > Second I don't understand what it has to do with this
> > > discussion.
> > > Your patch should be more specific and define which
> > > header fields are compatible with the new offload option.
> > >
> > >
> > >
> > >>> Thanks
> > >>>
> > >>>> Thanks!
> > >>>>
> > >>>>>>> After this is written up we will come up with a good short
> > >>>>>>> description for the feature bit.
> > >>>>>>>
> > >>>>>> Thanks
> > >>>>>>
> > >>>>>>>>> Thanks!
> > >>>>>>>>>
> > >>>>>>>>>> Thanks
> > >>>>>>>>>>
> > >>>>>>>>>>> Thanks!
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Thanks
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>> Thanks!
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Thanks
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Thanks!
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Thanks
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> \item[VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (2)] Control channel offloads
> > >>>>>>>>>>>>>>>>>>                 reconfiguration support.
> > >>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>> 2.19.1.6.gb485710b
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 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/
> > >>>>>>>>>>> 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/
> > >>>>>>>>>>>
> > >>>>>>>>> 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/
> > >>>>>>>>>
> > >
> > > 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/
> >
>

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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Jason Wang]

On Wed, Dec 6, 2023 at 4:08 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com> wrote:
>
> On Wed, 6 Dec 2023 12:36:53 +0800, Jason Wang <jasowang@redhat.com> wrote:
> > On Wed, Dec 6, 2023 at 10:21 AM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > >
> > >
> > >
> > > 在 2023/12/5 下午10:45, Michael S. Tsirkin 写道:
> > > > On Tue, Dec 05, 2023 at 10:18:32PM +0800, Heng Qi wrote:
> > > >>
> > > >> 在 2023/12/5 上午11:52, Jason Wang 写道:
> > > >>> On Mon, Dec 4, 2023 at 5:34 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > >>>>
> > > >>>> 在 2023/12/4 下午5:05, Michael S. Tsirkin 写道:
> > > >>>>> On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
> > > >>>>>> On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >>>>>>> On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
> > > >>>>>>>> On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > >>>>>>>>> 在 2023/12/4 下午3:18, Jason Wang 写道:
> > > >>>>>>>>>> On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > >>>>>>>>>>> 在 2023/12/1 下午3:05, Jason Wang 写道:
> > > >>>>>>>>>>>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> > > >>>>>>>>>>>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
> > > >>>>>>>>>>>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
> > > >>>>>>>>>>>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
> > > >>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
> > > >>>>>>>>>>>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
> > > >>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>> To prevent readers from misunderstanding that the driver can
> > > >>>>>>>>>>>>>>>>>> only handles packets with partial checksum when
> > > >>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> > > >>>>>>>>>>>>>>>>>> ---
> > > >>>>>>>>>>>>>>>>>>         device-types/net/description.tex | 2 +-
> > > >>>>>>>>>>>>>>>>>>         1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> diff --git a/device-types/net/description.tex
> > > >>>>>>>>>>>>>>>>>> b/device-types/net/description.tex
> > > >>>>>>>>>>>>>>>>>> index aff5e08..529f470 100644
> > > >>>>>>>>>>>>>>>>>> --- a/device-types/net/description.tex
> > > >>>>>>>>>>>>>>>>>> +++ b/device-types/net/description.tex
> > > >>>>>>>>>>>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
> > > >>>>>>>>>>>>>>>>>> / Network Device / Feature bits
> > > >>>>>>>>>>>>>>>>>>         \begin{description}
> > > >>>>>>>>>>>>>>>>>>         \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
> > > >>>>>>>>>>>>>>>>>> partial checksum offload.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> > > >>>>>>>>>>>>>>>>>> partial checksum.
> > > >>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
> > > >>>>>>>>>>>>>>>>>> partial checksum or full checksum.
> > > >>>>>>>>>>>>>>>>> So patch 2 said
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> "
> > > >>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
> > > >>>>>>>>>>>>>>>>> full checksum.
> > > >>>>>>>>>>>>>>>>>         \end{description}
> > > >>>>>>>>>>>>>>>>> "
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Is there any difference between the two "full checksum" here?
> > > >>>>>>>>>>>>>>>> There's no difference.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
> > > >>>>>>>>>>>>>>>> "can
> > > >>>>>>>>>>>>>>>> only" handle packets with full checksum.
> > > >>>>>>>>>>>>>>> This seems to be odd.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Driver can always handle packet with full checksum, no?
> > > >>>>>>>>>>>>>> Yes.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> I meant it
> > > >>>>>>>>>>>>>>> will be then to be functional equivalent to !
> > > >>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
> > > >>>>>>>>>>>>>> Are you referring to
> > > >>>>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
> > > >>>>>>>>>>>>> Sorry, this is a typo. I meant
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Are you referring to
> > > >>>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> If so, I think it's no.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Maybe a description similar to the following would be more clearer:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
> > > >>>>>>>>>>>>>> packets with partial checksum.
> > > >>>>>>>>>>>> I may miss something here, but what's the difference between
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> and
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> !VIRTIO_NET_F_GUEST_CSUM?
> > > >>>>>>>>>>>      From the device perspective:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
> > > >>>>>>>>>>> checksum to the driver,
> > > >>>>>>>>>>> but the device can not validate the checksum for these packets. That is,
> > > >>>>>>>>>>> the flags in virtio-net-hdr
> > > >>>>>>>>>>> will not contain _DATA_VALID, and the driver or stack needs to validate
> > > >>>>>>>>>>> these packets.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
> > > >>>>>>>>>>> checksum to the driver,
> > > >>>>>>>>>>> and the device can validate the checksum for these packets. That is, the
> > > >>>>>>>>>>> flags in virtio-net-hdr
> > > >>>>>>>>>>> will contain _DATA_VALID,
> > > >>>>>>>>>> I think DATA_VALID is optional here as device can't recognize all type
> > > >>>>>>>>>> of protocols.
> > > >>>>>>>>> Yes, you are right, so I used "device *can*" here. Which packet types
> > > >>>>>>>>> the device recognizes or validates
> > > >>>>>>>>> depends on the device's implementation. This is also the current
> > > >>>>>>>>> practice of GUEST_CSUM.
> > > >>>>>>>>>
> > > >>>>>>>>>>> and the driver or stack does not need to
> > > >>>>>>>>>>> validate these packets.
> > > >>>>>>>>>> Ok, so I think there're something that is subtle here,
> > > >>>>>>>>> Ok, I see.
> > > >>>>>>>>>
> > > >>>>>>>>>> and that's why
> > > >>>>>>>>>> I'm asking here:
> > > >>>>>>>>>>
> > > >>>>>>>>>> 1) "Driver does not handle packets with partial checksum" is not
> > > >>>>>>>>>> accurate, !GUEST_CUSM also fit for this definition.
> > > >>>>>>>>>> 2) "Driver handles packets with full checksum" is kind of ambiguous as
> > > >>>>>>>>>> it doesn't say whether or not the packet has been validated or not.
> > > >>>>>>>>> Maybe the description below would be less subtle?
> > > >>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
> > > >>>>>>>>> checksum or full checksum.
> > > >>>>>>>> I'd suggest to leave it as is. As I didn't find any issue since even
> > > >>>>>>>> with DATA_VALID. Did you?
> > > >>>>>>>>
> > > >>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
> > > >>>>>>>>> with full checksum,
> > > >>>>>>>>> and the device optionally validates the packet's checksum.
> > > >>>>>>>> Or maybe something like (not a native speaker)
> > > >>>>>>>>
> > > >>>>>>>> The driver handles packets with full checksum which the device has
> > > >>>>>>>> already validated.
> > > >>>>>>>>
> > > >>>>>>>> Thanks
> > > >>>>>>> I feel we just need a proper definition of what does "full checksum"
> > > >>>>>>> mean in this context. It is used but not defined.
> > > >>>>>>> Assume this feature was negotiated.
> > > >>>>>>> My understanding is that this is just like VIRTIO_NET_F_GUEST_CSUM
> > > >>>>>>> but certain values in the header are then disallowed? Which?
> > > >>>>>>> This should be in the spec.
> > > >>>>>> Yes, I think it is probably the headers that DATA_VALID can work. We
> > > >>>>>> never define it in the past.
> > > >>>>>>
> > > >>>>>> E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY, but it can
> > > >>>>>> only work for some specific protocols:
> > > >>>>>>
> > > >>>>>> """
> > > >>>>>>     *   %CHECKSUM_UNNECESSARY is applicable to following protocols:
> > > >>>>>>     *
> > > >>>>>>     *     - TCP: IPv6 and IPv4.
> > > >>>>>>     *     - UDP: IPv4 and IPv6. A device may apply CHECKSUM_UNNECESSARY to a
> > > >>>>>>     *       zero UDP checksum for either IPv4 or IPv6, the networking stack
> > > >>>>>>     *       may perform further validation in this case.
> > > >>>>>>     *     - GRE: only if the checksum is present in the header.
> > > >>>>>>     *     - SCTP: indicates the CRC in SCTP header has been validated.
> > > >>>>>>     *     - FCOE: indicates the CRC in FC frame has been validated.
> > > >>>>>> """
> > > >>>>>>
> > > >>>>>> I'm not sure whether it's just fine to duplicate the definition or
> > > >>>>>> it's too late to define any now.
> > > >>>>> I think it's mostly harmless for other protocols.
> > > >>>> I'm not sure if this should be defined by a new FULL_CSUM feature.
> > > >>>> This seems to be an issue with GUEST_CSUM.
> > > >>>>
> > > >>>> I think we should supplement these with a new patch for GUEST_CSUM?
> > > >>> Probably. My understanding is:
> > > >>>
> > > >>> You want to reuse DATA_VALID here, so we need to stick to a consistent
> > > >>> semantic for GUEST_CUSM and FULL_CSUM. So we need a definition of
> > > >>> "full csum" or what kind of packet could DATA_VALID work here.
> > > >> I agree, we can be clear about what types of packets DATA_VALID might
> > > >> cover, e.g. TCP/UDP/GRE/SCTP/FoCE.
> > > >>
> > > >> But I think we also need something like \field{supported_validate_types} to
> > > >> indicate which packet types the device supports validating and setting
> > > >> DATA_VALID,
> > > >> otherwise the device driver that negotiates this feature may fail to live
> > > >> migration.
> > > >> Am I right?
> > > >>
> > > >> I'm not sure how GUEST_CSUM works now as it should also suffer from the
> > > >> above
> > > >> mentioned issues with live migration, but no devices are reporting this
> > > >> right now.
> > > >>
> > > >> Maybe, each device only supports checksum verification for TCP/UDP by
> > > >> default? I don't know.
> > > >> But I hope we can focus on this and get consensus, because our hw release
> > > >> date is coming soon.
> > > >>
> > > >> Thanks a lot!
> > > >
> > > > First, DATA_VALID is not a thing that hardware should ever use.
> > > > It's a hack when packets are passed within host.
> > >
> > > Get here. Thanks!
> >
> > So if I understand correctly, we need a new flag here and define the
> > supported protocols.
>
>
> For what, migration?

No.

It's basically a question of whether or not we want to reuse
DATA_VALID. It has limitations that it only works for some specific
protocols.

If we don't, we need a new flag.

Thanks


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Heng Qi]

在 2023/12/6 下午4:46, Jason Wang 写道:
> On Wed, Dec 6, 2023 at 4:08 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com> wrote:
>> On Wed, 6 Dec 2023 12:36:53 +0800, Jason Wang <jasowang@redhat.com> wrote:
>>> On Wed, Dec 6, 2023 at 10:21 AM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>
>>>>
>>>> 在 2023/12/5 下午10:45, Michael S. Tsirkin 写道:
>>>>> On Tue, Dec 05, 2023 at 10:18:32PM +0800, Heng Qi wrote:
>>>>>> 在 2023/12/5 上午11:52, Jason Wang 写道:
>>>>>>> On Mon, Dec 4, 2023 at 5:34 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>>>>> 在 2023/12/4 下午5:05, Michael S. Tsirkin 写道:
>>>>>>>>> On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
>>>>>>>>>> On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>>>>>>>>>>> On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
>>>>>>>>>>>> On Mon, Dec 4, 2023 at 3:37 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>>>> 在 2023/12/4 下午3:18, Jason Wang 写道:
>>>>>>>>>>>>>> On Fri, Dec 1, 2023 at 3:16 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>>>>>> 在 2023/12/1 下午3:05, Jason Wang 写道:
>>>>>>>>>>>>>>>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>>>>>>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
>>>>>>>>>>>>>>>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
>>>>>>>>>>>>>>>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
>>>>>>>>>>>>>>>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> To prevent readers from misunderstanding that the driver can
>>>>>>>>>>>>>>>>>>>>>> only handles packets with partial checksum when
>>>>>>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update the description.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>>>>>>          device-types/net/description.tex | 2 +-
>>>>>>>>>>>>>>>>>>>>>>          1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> diff --git a/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>>>> b/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>>>> index aff5e08..529f470 100644
>>>>>>>>>>>>>>>>>>>>>> --- a/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>>>> +++ b/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types
>>>>>>>>>>>>>>>>>>>>>> / Network Device / Feature bits
>>>>>>>>>>>>>>>>>>>>>>          \begin{description}
>>>>>>>>>>>>>>>>>>>>>>          \item[VIRTIO_NET_F_CSUM (0)] Device handles packets with
>>>>>>>>>>>>>>>>>>>>>> partial checksum offload.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
>>>>>>>>>>>>>>>>>>>>>> partial checksum.
>>>>>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with
>>>>>>>>>>>>>>>>>>>>>> partial checksum or full checksum.
>>>>>>>>>>>>>>>>>>>>> So patch 2 said
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> "
>>>>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver handles packets with
>>>>>>>>>>>>>>>>>>>>> full checksum.
>>>>>>>>>>>>>>>>>>>>>          \end{description}
>>>>>>>>>>>>>>>>>>>>> "
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Is there any difference between the two "full checksum" here?
>>>>>>>>>>>>>>>>>>>> There's no difference.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM means that the driver
>>>>>>>>>>>>>>>>>>>> "can
>>>>>>>>>>>>>>>>>>>> only" handle packets with full checksum.
>>>>>>>>>>>>>>>>>>> This seems to be odd.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Driver can always handle packet with full checksum, no?
>>>>>>>>>>>>>>>>>> Yes.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I meant it
>>>>>>>>>>>>>>>>>>> will be then to be functional equivalent to !
>>>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
>>>>>>>>>>>>>>>>>> Are you referring to
>>>>>>>>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
>>>>>>>>>>>>>>>>> Sorry, this is a typo. I meant
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Are you referring to
>>>>>>>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If so, I think it's no.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Maybe a description similar to the following would be more clearer:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver does not handle
>>>>>>>>>>>>>>>>>> packets with partial checksum.
>>>>>>>>>>>>>>>> I may miss something here, but what's the difference between
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> !VIRTIO_NET_F_GUEST_CSUM?
>>>>>>>>>>>>>>>       From the device perspective:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers packets with full
>>>>>>>>>>>>>>> checksum to the driver,
>>>>>>>>>>>>>>> but the device can not validate the checksum for these packets. That is,
>>>>>>>>>>>>>>> the flags in virtio-net-hdr
>>>>>>>>>>>>>>> will not contain _DATA_VALID, and the driver or stack needs to validate
>>>>>>>>>>>>>>> these packets.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers packets with full
>>>>>>>>>>>>>>> checksum to the driver,
>>>>>>>>>>>>>>> and the device can validate the checksum for these packets. That is, the
>>>>>>>>>>>>>>> flags in virtio-net-hdr
>>>>>>>>>>>>>>> will contain _DATA_VALID,
>>>>>>>>>>>>>> I think DATA_VALID is optional here as device can't recognize all type
>>>>>>>>>>>>>> of protocols.
>>>>>>>>>>>>> Yes, you are right, so I used "device *can*" here. Which packet types
>>>>>>>>>>>>> the device recognizes or validates
>>>>>>>>>>>>> depends on the device's implementation. This is also the current
>>>>>>>>>>>>> practice of GUEST_CSUM.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> and the driver or stack does not need to
>>>>>>>>>>>>>>> validate these packets.
>>>>>>>>>>>>>> Ok, so I think there're something that is subtle here,
>>>>>>>>>>>>> Ok, I see.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> and that's why
>>>>>>>>>>>>>> I'm asking here:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1) "Driver does not handle packets with partial checksum" is not
>>>>>>>>>>>>>> accurate, !GUEST_CUSM also fit for this definition.
>>>>>>>>>>>>>> 2) "Driver handles packets with full checksum" is kind of ambiguous as
>>>>>>>>>>>>>> it doesn't say whether or not the packet has been validated or not.
>>>>>>>>>>>>> Maybe the description below would be less subtle?
>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles packets with partial
>>>>>>>>>>>>> checksum or full checksum.
>>>>>>>>>>>> I'd suggest to leave it as is. As I didn't find any issue since even
>>>>>>>>>>>> with DATA_VALID. Did you?
>>>>>>>>>>>>
>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver handles packets
>>>>>>>>>>>>> with full checksum,
>>>>>>>>>>>>> and the device optionally validates the packet's checksum.
>>>>>>>>>>>> Or maybe something like (not a native speaker)
>>>>>>>>>>>>
>>>>>>>>>>>> The driver handles packets with full checksum which the device has
>>>>>>>>>>>> already validated.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>> I feel we just need a proper definition of what does "full checksum"
>>>>>>>>>>> mean in this context. It is used but not defined.
>>>>>>>>>>> Assume this feature was negotiated.
>>>>>>>>>>> My understanding is that this is just like VIRTIO_NET_F_GUEST_CSUM
>>>>>>>>>>> but certain values in the header are then disallowed? Which?
>>>>>>>>>>> This should be in the spec.
>>>>>>>>>> Yes, I think it is probably the headers that DATA_VALID can work. We
>>>>>>>>>> never define it in the past.
>>>>>>>>>>
>>>>>>>>>> E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY, but it can
>>>>>>>>>> only work for some specific protocols:
>>>>>>>>>>
>>>>>>>>>> """
>>>>>>>>>>      *   %CHECKSUM_UNNECESSARY is applicable to following protocols:
>>>>>>>>>>      *
>>>>>>>>>>      *     - TCP: IPv6 and IPv4.
>>>>>>>>>>      *     - UDP: IPv4 and IPv6. A device may apply CHECKSUM_UNNECESSARY to a
>>>>>>>>>>      *       zero UDP checksum for either IPv4 or IPv6, the networking stack
>>>>>>>>>>      *       may perform further validation in this case.
>>>>>>>>>>      *     - GRE: only if the checksum is present in the header.
>>>>>>>>>>      *     - SCTP: indicates the CRC in SCTP header has been validated.
>>>>>>>>>>      *     - FCOE: indicates the CRC in FC frame has been validated.
>>>>>>>>>> """
>>>>>>>>>>
>>>>>>>>>> I'm not sure whether it's just fine to duplicate the definition or
>>>>>>>>>> it's too late to define any now.
>>>>>>>>> I think it's mostly harmless for other protocols.
>>>>>>>> I'm not sure if this should be defined by a new FULL_CSUM feature.
>>>>>>>> This seems to be an issue with GUEST_CSUM.
>>>>>>>>
>>>>>>>> I think we should supplement these with a new patch for GUEST_CSUM?
>>>>>>> Probably. My understanding is:
>>>>>>>
>>>>>>> You want to reuse DATA_VALID here, so we need to stick to a consistent
>>>>>>> semantic for GUEST_CUSM and FULL_CSUM. So we need a definition of
>>>>>>> "full csum" or what kind of packet could DATA_VALID work here.
>>>>>> I agree, we can be clear about what types of packets DATA_VALID might
>>>>>> cover, e.g. TCP/UDP/GRE/SCTP/FoCE.
>>>>>>
>>>>>> But I think we also need something like \field{supported_validate_types} to
>>>>>> indicate which packet types the device supports validating and setting
>>>>>> DATA_VALID,
>>>>>> otherwise the device driver that negotiates this feature may fail to live
>>>>>> migration.
>>>>>> Am I right?
>>>>>>
>>>>>> I'm not sure how GUEST_CSUM works now as it should also suffer from the
>>>>>> above
>>>>>> mentioned issues with live migration, but no devices are reporting this
>>>>>> right now.
>>>>>>
>>>>>> Maybe, each device only supports checksum verification for TCP/UDP by
>>>>>> default? I don't know.
>>>>>> But I hope we can focus on this and get consensus, because our hw release
>>>>>> date is coming soon.
>>>>>>
>>>>>> Thanks a lot!
>>>>> First, DATA_VALID is not a thing that hardware should ever use.
>>>>> It's a hack when packets are passed within host.
>>>> Get here. Thanks!
>>> So if I understand correctly, we need a new flag here and define the
>>> supported protocols.
>>
>> For what, migration?
> No.
>
> It's basically a question of whether or not we want to reuse
> DATA_VALID. It has limitations that it only works for some specific
> protocols.

Yes, I understand what Xuan means is that we reuse DATA_VALID and advertise
what specific protocols DATA_VALID covers.

Back to supported_validate_types, now I think we really don't need to 
let the device
provide this field. Why? Because asssuming the device provides it, it 
seems useless
because the driver does not parse the protocol type for each packet and 
does not use this field.
The driver and stack just want to know whether the packet is valid or 
checksum unneccessary.

Thanks!

>
> If we don't, we need a new flag.
>
> Thanks


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Heng Qi]

在 2023/12/6 下午5:03, Heng Qi 写道:
>
>
> 在 2023/12/6 下午4:46, Jason Wang 写道:
>> On Wed, Dec 6, 2023 at 4:08 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com> 
>> wrote:
>>> On Wed, 6 Dec 2023 12:36:53 +0800, Jason Wang <jasowang@redhat.com> 
>>> wrote:
>>>> On Wed, Dec 6, 2023 at 10:21 AM Heng Qi <hengqi@linux.alibaba.com> 
>>>> wrote:
>>>>>
>>>>>
>>>>> 在 2023/12/5 下午10:45, Michael S. Tsirkin 写道:
>>>>>> On Tue, Dec 05, 2023 at 10:18:32PM +0800, Heng Qi wrote:
>>>>>>> 在 2023/12/5 上午11:52, Jason Wang 写道:
>>>>>>>> On Mon, Dec 4, 2023 at 5:34 PM Heng Qi 
>>>>>>>> <hengqi@linux.alibaba.com> wrote:
>>>>>>>>> 在 2023/12/4 下午5:05, Michael S. Tsirkin 写道:
>>>>>>>>>> On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
>>>>>>>>>>> On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin 
>>>>>>>>>>> <mst@redhat.com> wrote:
>>>>>>>>>>>> On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
>>>>>>>>>>>>> On Mon, Dec 4, 2023 at 3:37 PM Heng Qi 
>>>>>>>>>>>>> <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>>>>> 在 2023/12/4 下午3:18, Jason Wang 写道:
>>>>>>>>>>>>>>> On Fri, Dec 1, 2023 at 3:16 PM Heng Qi 
>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>>>>>>> 在 2023/12/1 下午3:05, Jason Wang 写道:
>>>>>>>>>>>>>>>>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi 
>>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>>>>>>>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
>>>>>>>>>>>>>>>>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
>>>>>>>>>>>>>>>>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi 
>>>>>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
>>>>>>>>>>>>>>>>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi 
>>>>>>>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>> To prevent readers from misunderstanding that 
>>>>>>>>>>>>>>>>>>>>>>> the driver can
>>>>>>>>>>>>>>>>>>>>>>> only handles packets with partial checksum when
>>>>>>>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update 
>>>>>>>>>>>>>>>>>>>>>>> the description.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>>>>>>> device-types/net/description.tex | 2 +-
>>>>>>>>>>>>>>>>>>>>>>>          1 file changed, 1 insertion(+), 1 
>>>>>>>>>>>>>>>>>>>>>>> deletion(-)
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> diff --git a/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>>>>> b/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>>>>> index aff5e08..529f470 100644
>>>>>>>>>>>>>>>>>>>>>>> --- a/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>>>>> +++ b/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature 
>>>>>>>>>>>>>>>>>>>>>>> bits}\label{sec:Device Types
>>>>>>>>>>>>>>>>>>>>>>> / Network Device / Feature bits
>>>>>>>>>>>>>>>>>>>>>>> \begin{description}
>>>>>>>>>>>>>>>>>>>>>>> \item[VIRTIO_NET_F_CSUM (0)] Device handles 
>>>>>>>>>>>>>>>>>>>>>>> packets with
>>>>>>>>>>>>>>>>>>>>>>> partial checksum offload.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver 
>>>>>>>>>>>>>>>>>>>>>>> handles packets with
>>>>>>>>>>>>>>>>>>>>>>> partial checksum.
>>>>>>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver 
>>>>>>>>>>>>>>>>>>>>>>> handles packets with
>>>>>>>>>>>>>>>>>>>>>>> partial checksum or full checksum.
>>>>>>>>>>>>>>>>>>>>>> So patch 2 said
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> "
>>>>>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver 
>>>>>>>>>>>>>>>>>>>>>> handles packets with
>>>>>>>>>>>>>>>>>>>>>> full checksum.
>>>>>>>>>>>>>>>>>>>>>> \end{description}
>>>>>>>>>>>>>>>>>>>>>> "
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Is there any difference between the two "full 
>>>>>>>>>>>>>>>>>>>>>> checksum" here?
>>>>>>>>>>>>>>>>>>>>> There's no difference.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM 
>>>>>>>>>>>>>>>>>>>>> means that the driver
>>>>>>>>>>>>>>>>>>>>> "can
>>>>>>>>>>>>>>>>>>>>> only" handle packets with full checksum.
>>>>>>>>>>>>>>>>>>>> This seems to be odd.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Driver can always handle packet with full checksum, 
>>>>>>>>>>>>>>>>>>>> no?
>>>>>>>>>>>>>>>>>>> Yes.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I meant it
>>>>>>>>>>>>>>>>>>>> will be then to be functional equivalent to !
>>>>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
>>>>>>>>>>>>>>>>>>> Are you referring to
>>>>>>>>>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
>>>>>>>>>>>>>>>>>> Sorry, this is a typo. I meant
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Are you referring to
>>>>>>>>>>>>>>>>>> "functional equivalent to 
>>>>>>>>>>>>>>>>>> !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If so, I think it's no.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Maybe a description similar to the following would 
>>>>>>>>>>>>>>>>>>> be more clearer:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver 
>>>>>>>>>>>>>>>>>>> does not handle
>>>>>>>>>>>>>>>>>>> packets with partial checksum.
>>>>>>>>>>>>>>>>> I may miss something here, but what's the difference 
>>>>>>>>>>>>>>>>> between
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> !VIRTIO_NET_F_GUEST_CSUM?
>>>>>>>>>>>>>>>>       From the device perspective:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers 
>>>>>>>>>>>>>>>> packets with full
>>>>>>>>>>>>>>>> checksum to the driver,
>>>>>>>>>>>>>>>> but the device can not validate the checksum for these 
>>>>>>>>>>>>>>>> packets. That is,
>>>>>>>>>>>>>>>> the flags in virtio-net-hdr
>>>>>>>>>>>>>>>> will not contain _DATA_VALID, and the driver or stack 
>>>>>>>>>>>>>>>> needs to validate
>>>>>>>>>>>>>>>> these packets.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers 
>>>>>>>>>>>>>>>> packets with full
>>>>>>>>>>>>>>>> checksum to the driver,
>>>>>>>>>>>>>>>> and the device can validate the checksum for these 
>>>>>>>>>>>>>>>> packets. That is, the
>>>>>>>>>>>>>>>> flags in virtio-net-hdr
>>>>>>>>>>>>>>>> will contain _DATA_VALID,
>>>>>>>>>>>>>>> I think DATA_VALID is optional here as device can't 
>>>>>>>>>>>>>>> recognize all type
>>>>>>>>>>>>>>> of protocols.
>>>>>>>>>>>>>> Yes, you are right, so I used "device *can*" here. Which 
>>>>>>>>>>>>>> packet types
>>>>>>>>>>>>>> the device recognizes or validates
>>>>>>>>>>>>>> depends on the device's implementation. This is also the 
>>>>>>>>>>>>>> current
>>>>>>>>>>>>>> practice of GUEST_CSUM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> and the driver or stack does not need to
>>>>>>>>>>>>>>>> validate these packets.
>>>>>>>>>>>>>>> Ok, so I think there're something that is subtle here,
>>>>>>>>>>>>>> Ok, I see.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> and that's why
>>>>>>>>>>>>>>> I'm asking here:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1) "Driver does not handle packets with partial 
>>>>>>>>>>>>>>> checksum" is not
>>>>>>>>>>>>>>> accurate, !GUEST_CUSM also fit for this definition.
>>>>>>>>>>>>>>> 2) "Driver handles packets with full checksum" is kind 
>>>>>>>>>>>>>>> of ambiguous as
>>>>>>>>>>>>>>> it doesn't say whether or not the packet has been 
>>>>>>>>>>>>>>> validated or not.
>>>>>>>>>>>>>> Maybe the description below would be less subtle?
>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles 
>>>>>>>>>>>>>> packets with partial
>>>>>>>>>>>>>> checksum or full checksum.
>>>>>>>>>>>>> I'd suggest to leave it as is. As I didn't find any issue 
>>>>>>>>>>>>> since even
>>>>>>>>>>>>> with DATA_VALID. Did you?
>>>>>>>>>>>>>
>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver 
>>>>>>>>>>>>>> handles packets
>>>>>>>>>>>>>> with full checksum,
>>>>>>>>>>>>>> and the device optionally validates the packet's checksum.
>>>>>>>>>>>>> Or maybe something like (not a native speaker)
>>>>>>>>>>>>>
>>>>>>>>>>>>> The driver handles packets with full checksum which the 
>>>>>>>>>>>>> device has
>>>>>>>>>>>>> already validated.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>> I feel we just need a proper definition of what does "full 
>>>>>>>>>>>> checksum"
>>>>>>>>>>>> mean in this context. It is used but not defined.
>>>>>>>>>>>> Assume this feature was negotiated.
>>>>>>>>>>>> My understanding is that this is just like 
>>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM
>>>>>>>>>>>> but certain values in the header are then disallowed? Which?
>>>>>>>>>>>> This should be in the spec.
>>>>>>>>>>> Yes, I think it is probably the headers that DATA_VALID can 
>>>>>>>>>>> work. We
>>>>>>>>>>> never define it in the past.
>>>>>>>>>>>
>>>>>>>>>>> E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY, 
>>>>>>>>>>> but it can
>>>>>>>>>>> only work for some specific protocols:
>>>>>>>>>>>
>>>>>>>>>>> """
>>>>>>>>>>>      *   %CHECKSUM_UNNECESSARY is applicable to following 
>>>>>>>>>>> protocols:
>>>>>>>>>>>      *
>>>>>>>>>>>      *     - TCP: IPv6 and IPv4.
>>>>>>>>>>>      *     - UDP: IPv4 and IPv6. A device may apply 
>>>>>>>>>>> CHECKSUM_UNNECESSARY to a
>>>>>>>>>>>      *       zero UDP checksum for either IPv4 or IPv6, the 
>>>>>>>>>>> networking stack
>>>>>>>>>>>      *       may perform further validation in this case.
>>>>>>>>>>>      *     - GRE: only if the checksum is present in the 
>>>>>>>>>>> header.
>>>>>>>>>>>      *     - SCTP: indicates the CRC in SCTP header has been 
>>>>>>>>>>> validated.
>>>>>>>>>>>      *     - FCOE: indicates the CRC in FC frame has been 
>>>>>>>>>>> validated.
>>>>>>>>>>> """
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure whether it's just fine to duplicate the 
>>>>>>>>>>> definition or
>>>>>>>>>>> it's too late to define any now.
>>>>>>>>>> I think it's mostly harmless for other protocols.
>>>>>>>>> I'm not sure if this should be defined by a new FULL_CSUM 
>>>>>>>>> feature.
>>>>>>>>> This seems to be an issue with GUEST_CSUM.
>>>>>>>>>
>>>>>>>>> I think we should supplement these with a new patch for 
>>>>>>>>> GUEST_CSUM?
>>>>>>>> Probably. My understanding is:
>>>>>>>>
>>>>>>>> You want to reuse DATA_VALID here, so we need to stick to a 
>>>>>>>> consistent
>>>>>>>> semantic for GUEST_CUSM and FULL_CSUM. So we need a definition of
>>>>>>>> "full csum" or what kind of packet could DATA_VALID work here.
>>>>>>> I agree, we can be clear about what types of packets DATA_VALID 
>>>>>>> might
>>>>>>> cover, e.g. TCP/UDP/GRE/SCTP/FoCE.
>>>>>>>
>>>>>>> But I think we also need something like 
>>>>>>> \field{supported_validate_types} to
>>>>>>> indicate which packet types the device supports validating and 
>>>>>>> setting
>>>>>>> DATA_VALID,
>>>>>>> otherwise the device driver that negotiates this feature may 
>>>>>>> fail to live
>>>>>>> migration.
>>>>>>> Am I right?
>>>>>>>
>>>>>>> I'm not sure how GUEST_CSUM works now as it should also suffer 
>>>>>>> from the
>>>>>>> above
>>>>>>> mentioned issues with live migration, but no devices are 
>>>>>>> reporting this
>>>>>>> right now.
>>>>>>>
>>>>>>> Maybe, each device only supports checksum verification for 
>>>>>>> TCP/UDP by
>>>>>>> default? I don't know.
>>>>>>> But I hope we can focus on this and get consensus, because our 
>>>>>>> hw release
>>>>>>> date is coming soon.
>>>>>>>
>>>>>>> Thanks a lot!
>>>>>> First, DATA_VALID is not a thing that hardware should ever use.
>>>>>> It's a hack when packets are passed within host.
>>>>> Get here. Thanks!
>>>> So if I understand correctly, we need a new flag here and define the
>>>> supported protocols.
>>>
>>> For what, migration?
>> No.
>>
>> It's basically a question of whether or not we want to reuse
>> DATA_VALID. It has limitations that it only works for some specific
>> protocols.
>
> Yes, I understand what Xuan means is that we reuse DATA_VALID and 
> advertise
> what specific protocols DATA_VALID covers.
>
> Back to supported_validate_types, now I think we really don't need to 
> let the device
> provide this field. Why? Because asssuming the device provides it, it 
> seems useless
> because the driver does not parse the protocol type for each packet 
> and does not use this field.
> The driver and stack just want to know whether the packet is valid or 
> checksum unneccessary.

Hi Jason and Michael.

Are we aligned on this?

If yes, I'll write a new version to refresh the thread and try to avoid 
future rollbacks.

Thanks a lot!

>
> Thanks!
>
>>
>> If we don't, we need a new flag.
>>
>> Thanks
>
>
> 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/


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Jason Wang]

On Thu, Dec 7, 2023 at 12:52 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>
>
>
> 在 2023/12/6 下午5:03, Heng Qi 写道:
> >
> >
> > 在 2023/12/6 下午4:46, Jason Wang 写道:
> >> On Wed, Dec 6, 2023 at 4:08 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> >> wrote:
> >>> On Wed, 6 Dec 2023 12:36:53 +0800, Jason Wang <jasowang@redhat.com>
> >>> wrote:
> >>>> On Wed, Dec 6, 2023 at 10:21 AM Heng Qi <hengqi@linux.alibaba.com>
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>> 在 2023/12/5 下午10:45, Michael S. Tsirkin 写道:
> >>>>>> On Tue, Dec 05, 2023 at 10:18:32PM +0800, Heng Qi wrote:
> >>>>>>> 在 2023/12/5 上午11:52, Jason Wang 写道:
> >>>>>>>> On Mon, Dec 4, 2023 at 5:34 PM Heng Qi
> >>>>>>>> <hengqi@linux.alibaba.com> wrote:
> >>>>>>>>> 在 2023/12/4 下午5:05, Michael S. Tsirkin 写道:
> >>>>>>>>>> On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
> >>>>>>>>>>> On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin
> >>>>>>>>>>> <mst@redhat.com> wrote:
> >>>>>>>>>>>> On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
> >>>>>>>>>>>>> On Mon, Dec 4, 2023 at 3:37 PM Heng Qi
> >>>>>>>>>>>>> <hengqi@linux.alibaba.com> wrote:
> >>>>>>>>>>>>>> 在 2023/12/4 下午3:18, Jason Wang 写道:
> >>>>>>>>>>>>>>> On Fri, Dec 1, 2023 at 3:16 PM Heng Qi
> >>>>>>>>>>>>>>> <hengqi@linux.alibaba.com> wrote:
> >>>>>>>>>>>>>>>> 在 2023/12/1 下午3:05, Jason Wang 写道:
> >>>>>>>>>>>>>>>>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi
> >>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com> wrote:
> >>>>>>>>>>>>>>>>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
> >>>>>>>>>>>>>>>>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
> >>>>>>>>>>>>>>>>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi
> >>>>>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
> >>>>>>>>>>>>>>>>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi
> >>>>>>>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com>
> >>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>> To prevent readers from misunderstanding that
> >>>>>>>>>>>>>>>>>>>>>>> the driver can
> >>>>>>>>>>>>>>>>>>>>>>> only handles packets with partial checksum when
> >>>>>>>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update
> >>>>>>>>>>>>>>>>>>>>>>> the description.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> >>>>>>>>>>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>>>>>>>>>> device-types/net/description.tex | 2 +-
> >>>>>>>>>>>>>>>>>>>>>>>          1 file changed, 1 insertion(+), 1
> >>>>>>>>>>>>>>>>>>>>>>> deletion(-)
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> diff --git a/device-types/net/description.tex
> >>>>>>>>>>>>>>>>>>>>>>> b/device-types/net/description.tex
> >>>>>>>>>>>>>>>>>>>>>>> index aff5e08..529f470 100644
> >>>>>>>>>>>>>>>>>>>>>>> --- a/device-types/net/description.tex
> >>>>>>>>>>>>>>>>>>>>>>> +++ b/device-types/net/description.tex
> >>>>>>>>>>>>>>>>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature
> >>>>>>>>>>>>>>>>>>>>>>> bits}\label{sec:Device Types
> >>>>>>>>>>>>>>>>>>>>>>> / Network Device / Feature bits
> >>>>>>>>>>>>>>>>>>>>>>> \begin{description}
> >>>>>>>>>>>>>>>>>>>>>>> \item[VIRTIO_NET_F_CSUM (0)] Device handles
> >>>>>>>>>>>>>>>>>>>>>>> packets with
> >>>>>>>>>>>>>>>>>>>>>>> partial checksum offload.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver
> >>>>>>>>>>>>>>>>>>>>>>> handles packets with
> >>>>>>>>>>>>>>>>>>>>>>> partial checksum.
> >>>>>>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver
> >>>>>>>>>>>>>>>>>>>>>>> handles packets with
> >>>>>>>>>>>>>>>>>>>>>>> partial checksum or full checksum.
> >>>>>>>>>>>>>>>>>>>>>> So patch 2 said
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> "
> >>>>>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver
> >>>>>>>>>>>>>>>>>>>>>> handles packets with
> >>>>>>>>>>>>>>>>>>>>>> full checksum.
> >>>>>>>>>>>>>>>>>>>>>> \end{description}
> >>>>>>>>>>>>>>>>>>>>>> "
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Is there any difference between the two "full
> >>>>>>>>>>>>>>>>>>>>>> checksum" here?
> >>>>>>>>>>>>>>>>>>>>> There's no difference.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM
> >>>>>>>>>>>>>>>>>>>>> means that the driver
> >>>>>>>>>>>>>>>>>>>>> "can
> >>>>>>>>>>>>>>>>>>>>> only" handle packets with full checksum.
> >>>>>>>>>>>>>>>>>>>> This seems to be odd.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Driver can always handle packet with full checksum,
> >>>>>>>>>>>>>>>>>>>> no?
> >>>>>>>>>>>>>>>>>>> Yes.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I meant it
> >>>>>>>>>>>>>>>>>>>> will be then to be functional equivalent to !
> >>>>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
> >>>>>>>>>>>>>>>>>>> Are you referring to
> >>>>>>>>>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
> >>>>>>>>>>>>>>>>>> Sorry, this is a typo. I meant
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Are you referring to
> >>>>>>>>>>>>>>>>>> "functional equivalent to
> >>>>>>>>>>>>>>>>>> !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> If so, I think it's no.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Maybe a description similar to the following would
> >>>>>>>>>>>>>>>>>>> be more clearer:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver
> >>>>>>>>>>>>>>>>>>> does not handle
> >>>>>>>>>>>>>>>>>>> packets with partial checksum.
> >>>>>>>>>>>>>>>>> I may miss something here, but what's the difference
> >>>>>>>>>>>>>>>>> between
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> !VIRTIO_NET_F_GUEST_CSUM?
> >>>>>>>>>>>>>>>>       From the device perspective:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers
> >>>>>>>>>>>>>>>> packets with full
> >>>>>>>>>>>>>>>> checksum to the driver,
> >>>>>>>>>>>>>>>> but the device can not validate the checksum for these
> >>>>>>>>>>>>>>>> packets. That is,
> >>>>>>>>>>>>>>>> the flags in virtio-net-hdr
> >>>>>>>>>>>>>>>> will not contain _DATA_VALID, and the driver or stack
> >>>>>>>>>>>>>>>> needs to validate
> >>>>>>>>>>>>>>>> these packets.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers
> >>>>>>>>>>>>>>>> packets with full
> >>>>>>>>>>>>>>>> checksum to the driver,
> >>>>>>>>>>>>>>>> and the device can validate the checksum for these
> >>>>>>>>>>>>>>>> packets. That is, the
> >>>>>>>>>>>>>>>> flags in virtio-net-hdr
> >>>>>>>>>>>>>>>> will contain _DATA_VALID,
> >>>>>>>>>>>>>>> I think DATA_VALID is optional here as device can't
> >>>>>>>>>>>>>>> recognize all type
> >>>>>>>>>>>>>>> of protocols.
> >>>>>>>>>>>>>> Yes, you are right, so I used "device *can*" here. Which
> >>>>>>>>>>>>>> packet types
> >>>>>>>>>>>>>> the device recognizes or validates
> >>>>>>>>>>>>>> depends on the device's implementation. This is also the
> >>>>>>>>>>>>>> current
> >>>>>>>>>>>>>> practice of GUEST_CSUM.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> and the driver or stack does not need to
> >>>>>>>>>>>>>>>> validate these packets.
> >>>>>>>>>>>>>>> Ok, so I think there're something that is subtle here,
> >>>>>>>>>>>>>> Ok, I see.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> and that's why
> >>>>>>>>>>>>>>> I'm asking here:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 1) "Driver does not handle packets with partial
> >>>>>>>>>>>>>>> checksum" is not
> >>>>>>>>>>>>>>> accurate, !GUEST_CUSM also fit for this definition.
> >>>>>>>>>>>>>>> 2) "Driver handles packets with full checksum" is kind
> >>>>>>>>>>>>>>> of ambiguous as
> >>>>>>>>>>>>>>> it doesn't say whether or not the packet has been
> >>>>>>>>>>>>>>> validated or not.
> >>>>>>>>>>>>>> Maybe the description below would be less subtle?
> >>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles
> >>>>>>>>>>>>>> packets with partial
> >>>>>>>>>>>>>> checksum or full checksum.
> >>>>>>>>>>>>> I'd suggest to leave it as is. As I didn't find any issue
> >>>>>>>>>>>>> since even
> >>>>>>>>>>>>> with DATA_VALID. Did you?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver
> >>>>>>>>>>>>>> handles packets
> >>>>>>>>>>>>>> with full checksum,
> >>>>>>>>>>>>>> and the device optionally validates the packet's checksum.
> >>>>>>>>>>>>> Or maybe something like (not a native speaker)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The driver handles packets with full checksum which the
> >>>>>>>>>>>>> device has
> >>>>>>>>>>>>> already validated.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks
> >>>>>>>>>>>> I feel we just need a proper definition of what does "full
> >>>>>>>>>>>> checksum"
> >>>>>>>>>>>> mean in this context. It is used but not defined.
> >>>>>>>>>>>> Assume this feature was negotiated.
> >>>>>>>>>>>> My understanding is that this is just like
> >>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM
> >>>>>>>>>>>> but certain values in the header are then disallowed? Which?
> >>>>>>>>>>>> This should be in the spec.
> >>>>>>>>>>> Yes, I think it is probably the headers that DATA_VALID can
> >>>>>>>>>>> work. We
> >>>>>>>>>>> never define it in the past.
> >>>>>>>>>>>
> >>>>>>>>>>> E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY,
> >>>>>>>>>>> but it can
> >>>>>>>>>>> only work for some specific protocols:
> >>>>>>>>>>>
> >>>>>>>>>>> """
> >>>>>>>>>>>      *   %CHECKSUM_UNNECESSARY is applicable to following
> >>>>>>>>>>> protocols:
> >>>>>>>>>>>      *
> >>>>>>>>>>>      *     - TCP: IPv6 and IPv4.
> >>>>>>>>>>>      *     - UDP: IPv4 and IPv6. A device may apply
> >>>>>>>>>>> CHECKSUM_UNNECESSARY to a
> >>>>>>>>>>>      *       zero UDP checksum for either IPv4 or IPv6, the
> >>>>>>>>>>> networking stack
> >>>>>>>>>>>      *       may perform further validation in this case.
> >>>>>>>>>>>      *     - GRE: only if the checksum is present in the
> >>>>>>>>>>> header.
> >>>>>>>>>>>      *     - SCTP: indicates the CRC in SCTP header has been
> >>>>>>>>>>> validated.
> >>>>>>>>>>>      *     - FCOE: indicates the CRC in FC frame has been
> >>>>>>>>>>> validated.
> >>>>>>>>>>> """
> >>>>>>>>>>>
> >>>>>>>>>>> I'm not sure whether it's just fine to duplicate the
> >>>>>>>>>>> definition or
> >>>>>>>>>>> it's too late to define any now.
> >>>>>>>>>> I think it's mostly harmless for other protocols.
> >>>>>>>>> I'm not sure if this should be defined by a new FULL_CSUM
> >>>>>>>>> feature.
> >>>>>>>>> This seems to be an issue with GUEST_CSUM.
> >>>>>>>>>
> >>>>>>>>> I think we should supplement these with a new patch for
> >>>>>>>>> GUEST_CSUM?
> >>>>>>>> Probably. My understanding is:
> >>>>>>>>
> >>>>>>>> You want to reuse DATA_VALID here, so we need to stick to a
> >>>>>>>> consistent
> >>>>>>>> semantic for GUEST_CUSM and FULL_CSUM. So we need a definition of
> >>>>>>>> "full csum" or what kind of packet could DATA_VALID work here.
> >>>>>>> I agree, we can be clear about what types of packets DATA_VALID
> >>>>>>> might
> >>>>>>> cover, e.g. TCP/UDP/GRE/SCTP/FoCE.
> >>>>>>>
> >>>>>>> But I think we also need something like
> >>>>>>> \field{supported_validate_types} to
> >>>>>>> indicate which packet types the device supports validating and
> >>>>>>> setting
> >>>>>>> DATA_VALID,
> >>>>>>> otherwise the device driver that negotiates this feature may
> >>>>>>> fail to live
> >>>>>>> migration.
> >>>>>>> Am I right?
> >>>>>>>
> >>>>>>> I'm not sure how GUEST_CSUM works now as it should also suffer
> >>>>>>> from the
> >>>>>>> above
> >>>>>>> mentioned issues with live migration, but no devices are
> >>>>>>> reporting this
> >>>>>>> right now.
> >>>>>>>
> >>>>>>> Maybe, each device only supports checksum verification for
> >>>>>>> TCP/UDP by
> >>>>>>> default? I don't know.
> >>>>>>> But I hope we can focus on this and get consensus, because our
> >>>>>>> hw release
> >>>>>>> date is coming soon.
> >>>>>>>
> >>>>>>> Thanks a lot!
> >>>>>> First, DATA_VALID is not a thing that hardware should ever use.
> >>>>>> It's a hack when packets are passed within host.
> >>>>> Get here. Thanks!
> >>>> So if I understand correctly, we need a new flag here and define the
> >>>> supported protocols.
> >>>
> >>> For what, migration?
> >> No.
> >>
> >> It's basically a question of whether or not we want to reuse
> >> DATA_VALID. It has limitations that it only works for some specific
> >> protocols.
> >
> > Yes, I understand what Xuan means is that we reuse DATA_VALID and
> > advertise
> > what specific protocols DATA_VALID covers.
> >
> > Back to supported_validate_types, now I think we really don't need to
> > let the device
> > provide this field. Why? Because asssuming the device provides it, it
> > seems useless
> > because the driver does not parse the protocol type for each packet
> > and does not use this field.
> > The driver and stack just want to know whether the packet is valid or
> > checksum unneccessary.
>
> Hi Jason and Michael.
>
> Are we aligned on this?

For supported_validate_types, I don't think we need it.

But I'm not sure if we are aligned.

>
> If yes, I'll write a new version to refresh the thread and try to avoid
> future rollbacks.

Maybe you can post a new version.

Thanks

>
> Thanks a lot!
>
> >
> > Thanks!
> >
> >>
> >> If we don't, we need a new flag.
> >>
> >> Thanks
> >
> >
> > 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/
>


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Yuri Benditovich]

[-- Attachment #1: Type: text/plain, Size: 16794 bytes --]

If somebody explains the problem that this patch addresses it will be very,
_very_ helpful.
We _were_ sure that if the host suggests  VIRTIO_NET_F_GUEST_CSUM and the
driver acks it - they both can do _more_ than without this feature.
Specifically the driver claims that it is able to deal with additional
types of incoming packets and such a way the device is able to provide
_more_ types of incoming packets than if this feature is not acked..
Shall we change our mind somehow?
I believe that if due to the presence of this feature the driver is _not_
able to do something this is a bug somewhere around the driver, isn't it?
Thank you in advance for the clarification.

On Thu, Dec 7, 2023 at 7:35 AM Jason Wang <jasowang@redhat.com> wrote:

> On Thu, Dec 7, 2023 at 12:52 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
> >
> >
> >
> > 在 2023/12/6 下午5:03, Heng Qi 写道:
> > >
> > >
> > > 在 2023/12/6 下午4:46, Jason Wang 写道:
> > >> On Wed, Dec 6, 2023 at 4:08 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > >> wrote:
> > >>> On Wed, 6 Dec 2023 12:36:53 +0800, Jason Wang <jasowang@redhat.com>
> > >>> wrote:
> > >>>> On Wed, Dec 6, 2023 at 10:21 AM Heng Qi <hengqi@linux.alibaba.com>
> > >>>> wrote:
> > >>>>>
> > >>>>>
> > >>>>> 在 2023/12/5 下午10:45, Michael S. Tsirkin 写道:
> > >>>>>> On Tue, Dec 05, 2023 at 10:18:32PM +0800, Heng Qi wrote:
> > >>>>>>> 在 2023/12/5 上午11:52, Jason Wang 写道:
> > >>>>>>>> On Mon, Dec 4, 2023 at 5:34 PM Heng Qi
> > >>>>>>>> <hengqi@linux.alibaba.com> wrote:
> > >>>>>>>>> 在 2023/12/4 下午5:05, Michael S. Tsirkin 写道:
> > >>>>>>>>>> On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
> > >>>>>>>>>>> On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin
> > >>>>>>>>>>> <mst@redhat.com> wrote:
> > >>>>>>>>>>>> On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
> > >>>>>>>>>>>>> On Mon, Dec 4, 2023 at 3:37 PM Heng Qi
> > >>>>>>>>>>>>> <hengqi@linux.alibaba.com> wrote:
> > >>>>>>>>>>>>>> 在 2023/12/4 下午3:18, Jason Wang 写道:
> > >>>>>>>>>>>>>>> On Fri, Dec 1, 2023 at 3:16 PM Heng Qi
> > >>>>>>>>>>>>>>> <hengqi@linux.alibaba.com> wrote:
> > >>>>>>>>>>>>>>>> 在 2023/12/1 下午3:05, Jason Wang 写道:
> > >>>>>>>>>>>>>>>>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi
> > >>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com> wrote:
> > >>>>>>>>>>>>>>>>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
> > >>>>>>>>>>>>>>>>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
> > >>>>>>>>>>>>>>>>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi
> > >>>>>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com>
> > >>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
> > >>>>>>>>>>>>>>>>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi
> > >>>>>>>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com>
> > >>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>> To prevent readers from misunderstanding that
> > >>>>>>>>>>>>>>>>>>>>>>> the driver can
> > >>>>>>>>>>>>>>>>>>>>>>> only handles packets with partial checksum when
> > >>>>>>>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update
> > >>>>>>>>>>>>>>>>>>>>>>> the description.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com
> >
> > >>>>>>>>>>>>>>>>>>>>>>> ---
> > >>>>>>>>>>>>>>>>>>>>>>> device-types/net/description.tex | 2 +-
> > >>>>>>>>>>>>>>>>>>>>>>>          1 file changed, 1 insertion(+), 1
> > >>>>>>>>>>>>>>>>>>>>>>> deletion(-)
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> diff --git a/device-types/net/description.tex
> > >>>>>>>>>>>>>>>>>>>>>>> b/device-types/net/description.tex
> > >>>>>>>>>>>>>>>>>>>>>>> index aff5e08..529f470 100644
> > >>>>>>>>>>>>>>>>>>>>>>> --- a/device-types/net/description.tex
> > >>>>>>>>>>>>>>>>>>>>>>> +++ b/device-types/net/description.tex
> > >>>>>>>>>>>>>>>>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature
> > >>>>>>>>>>>>>>>>>>>>>>> bits}\label{sec:Device Types
> > >>>>>>>>>>>>>>>>>>>>>>> / Network Device / Feature bits
> > >>>>>>>>>>>>>>>>>>>>>>> \begin{description}
> > >>>>>>>>>>>>>>>>>>>>>>> \item[VIRTIO_NET_F_CSUM (0)] Device handles
> > >>>>>>>>>>>>>>>>>>>>>>> packets with
> > >>>>>>>>>>>>>>>>>>>>>>> partial checksum offload.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver
> > >>>>>>>>>>>>>>>>>>>>>>> handles packets with
> > >>>>>>>>>>>>>>>>>>>>>>> partial checksum.
> > >>>>>>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver
> > >>>>>>>>>>>>>>>>>>>>>>> handles packets with
> > >>>>>>>>>>>>>>>>>>>>>>> partial checksum or full checksum.
> > >>>>>>>>>>>>>>>>>>>>>> So patch 2 said
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> "
> > >>>>>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver
> > >>>>>>>>>>>>>>>>>>>>>> handles packets with
> > >>>>>>>>>>>>>>>>>>>>>> full checksum.
> > >>>>>>>>>>>>>>>>>>>>>> \end{description}
> > >>>>>>>>>>>>>>>>>>>>>> "
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Is there any difference between the two "full
> > >>>>>>>>>>>>>>>>>>>>>> checksum" here?
> > >>>>>>>>>>>>>>>>>>>>> There's no difference.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM
> > >>>>>>>>>>>>>>>>>>>>> means that the driver
> > >>>>>>>>>>>>>>>>>>>>> "can
> > >>>>>>>>>>>>>>>>>>>>> only" handle packets with full checksum.
> > >>>>>>>>>>>>>>>>>>>> This seems to be odd.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Driver can always handle packet with full checksum,
> > >>>>>>>>>>>>>>>>>>>> no?
> > >>>>>>>>>>>>>>>>>>> Yes.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> I meant it
> > >>>>>>>>>>>>>>>>>>>> will be then to be functional equivalent to !
> > >>>>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
> > >>>>>>>>>>>>>>>>>>> Are you referring to
> > >>>>>>>>>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
> > >>>>>>>>>>>>>>>>>> Sorry, this is a typo. I meant
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Are you referring to
> > >>>>>>>>>>>>>>>>>> "functional equivalent to
> > >>>>>>>>>>>>>>>>>> !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> If so, I think it's no.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Maybe a description similar to the following would
> > >>>>>>>>>>>>>>>>>>> be more clearer:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver
> > >>>>>>>>>>>>>>>>>>> does not handle
> > >>>>>>>>>>>>>>>>>>> packets with partial checksum.
> > >>>>>>>>>>>>>>>>> I may miss something here, but what's the difference
> > >>>>>>>>>>>>>>>>> between
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> !VIRTIO_NET_F_GUEST_CSUM?
> > >>>>>>>>>>>>>>>>       From the device perspective:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers
> > >>>>>>>>>>>>>>>> packets with full
> > >>>>>>>>>>>>>>>> checksum to the driver,
> > >>>>>>>>>>>>>>>> but the device can not validate the checksum for these
> > >>>>>>>>>>>>>>>> packets. That is,
> > >>>>>>>>>>>>>>>> the flags in virtio-net-hdr
> > >>>>>>>>>>>>>>>> will not contain _DATA_VALID, and the driver or stack
> > >>>>>>>>>>>>>>>> needs to validate
> > >>>>>>>>>>>>>>>> these packets.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers
> > >>>>>>>>>>>>>>>> packets with full
> > >>>>>>>>>>>>>>>> checksum to the driver,
> > >>>>>>>>>>>>>>>> and the device can validate the checksum for these
> > >>>>>>>>>>>>>>>> packets. That is, the
> > >>>>>>>>>>>>>>>> flags in virtio-net-hdr
> > >>>>>>>>>>>>>>>> will contain _DATA_VALID,
> > >>>>>>>>>>>>>>> I think DATA_VALID is optional here as device can't
> > >>>>>>>>>>>>>>> recognize all type
> > >>>>>>>>>>>>>>> of protocols.
> > >>>>>>>>>>>>>> Yes, you are right, so I used "device *can*" here. Which
> > >>>>>>>>>>>>>> packet types
> > >>>>>>>>>>>>>> the device recognizes or validates
> > >>>>>>>>>>>>>> depends on the device's implementation. This is also the
> > >>>>>>>>>>>>>> current
> > >>>>>>>>>>>>>> practice of GUEST_CSUM.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> and the driver or stack does not need to
> > >>>>>>>>>>>>>>>> validate these packets.
> > >>>>>>>>>>>>>>> Ok, so I think there're something that is subtle here,
> > >>>>>>>>>>>>>> Ok, I see.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> and that's why
> > >>>>>>>>>>>>>>> I'm asking here:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> 1) "Driver does not handle packets with partial
> > >>>>>>>>>>>>>>> checksum" is not
> > >>>>>>>>>>>>>>> accurate, !GUEST_CUSM also fit for this definition.
> > >>>>>>>>>>>>>>> 2) "Driver handles packets with full checksum" is kind
> > >>>>>>>>>>>>>>> of ambiguous as
> > >>>>>>>>>>>>>>> it doesn't say whether or not the packet has been
> > >>>>>>>>>>>>>>> validated or not.
> > >>>>>>>>>>>>>> Maybe the description below would be less subtle?
> > >>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles
> > >>>>>>>>>>>>>> packets with partial
> > >>>>>>>>>>>>>> checksum or full checksum.
> > >>>>>>>>>>>>> I'd suggest to leave it as is. As I didn't find any issue
> > >>>>>>>>>>>>> since even
> > >>>>>>>>>>>>> with DATA_VALID. Did you?
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver
> > >>>>>>>>>>>>>> handles packets
> > >>>>>>>>>>>>>> with full checksum,
> > >>>>>>>>>>>>>> and the device optionally validates the packet's checksum.
> > >>>>>>>>>>>>> Or maybe something like (not a native speaker)
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> The driver handles packets with full checksum which the
> > >>>>>>>>>>>>> device has
> > >>>>>>>>>>>>> already validated.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Thanks
> > >>>>>>>>>>>> I feel we just need a proper definition of what does "full
> > >>>>>>>>>>>> checksum"
> > >>>>>>>>>>>> mean in this context. It is used but not defined.
> > >>>>>>>>>>>> Assume this feature was negotiated.
> > >>>>>>>>>>>> My understanding is that this is just like
> > >>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM
> > >>>>>>>>>>>> but certain values in the header are then disallowed? Which?
> > >>>>>>>>>>>> This should be in the spec.
> > >>>>>>>>>>> Yes, I think it is probably the headers that DATA_VALID can
> > >>>>>>>>>>> work. We
> > >>>>>>>>>>> never define it in the past.
> > >>>>>>>>>>>
> > >>>>>>>>>>> E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY,
> > >>>>>>>>>>> but it can
> > >>>>>>>>>>> only work for some specific protocols:
> > >>>>>>>>>>>
> > >>>>>>>>>>> """
> > >>>>>>>>>>>      *   %CHECKSUM_UNNECESSARY is applicable to following
> > >>>>>>>>>>> protocols:
> > >>>>>>>>>>>      *
> > >>>>>>>>>>>      *     - TCP: IPv6 and IPv4.
> > >>>>>>>>>>>      *     - UDP: IPv4 and IPv6. A device may apply
> > >>>>>>>>>>> CHECKSUM_UNNECESSARY to a
> > >>>>>>>>>>>      *       zero UDP checksum for either IPv4 or IPv6, the
> > >>>>>>>>>>> networking stack
> > >>>>>>>>>>>      *       may perform further validation in this case.
> > >>>>>>>>>>>      *     - GRE: only if the checksum is present in the
> > >>>>>>>>>>> header.
> > >>>>>>>>>>>      *     - SCTP: indicates the CRC in SCTP header has been
> > >>>>>>>>>>> validated.
> > >>>>>>>>>>>      *     - FCOE: indicates the CRC in FC frame has been
> > >>>>>>>>>>> validated.
> > >>>>>>>>>>> """
> > >>>>>>>>>>>
> > >>>>>>>>>>> I'm not sure whether it's just fine to duplicate the
> > >>>>>>>>>>> definition or
> > >>>>>>>>>>> it's too late to define any now.
> > >>>>>>>>>> I think it's mostly harmless for other protocols.
> > >>>>>>>>> I'm not sure if this should be defined by a new FULL_CSUM
> > >>>>>>>>> feature.
> > >>>>>>>>> This seems to be an issue with GUEST_CSUM.
> > >>>>>>>>>
> > >>>>>>>>> I think we should supplement these with a new patch for
> > >>>>>>>>> GUEST_CSUM?
> > >>>>>>>> Probably. My understanding is:
> > >>>>>>>>
> > >>>>>>>> You want to reuse DATA_VALID here, so we need to stick to a
> > >>>>>>>> consistent
> > >>>>>>>> semantic for GUEST_CUSM and FULL_CSUM. So we need a definition
> of
> > >>>>>>>> "full csum" or what kind of packet could DATA_VALID work here.
> > >>>>>>> I agree, we can be clear about what types of packets DATA_VALID
> > >>>>>>> might
> > >>>>>>> cover, e.g. TCP/UDP/GRE/SCTP/FoCE.
> > >>>>>>>
> > >>>>>>> But I think we also need something like
> > >>>>>>> \field{supported_validate_types} to
> > >>>>>>> indicate which packet types the device supports validating and
> > >>>>>>> setting
> > >>>>>>> DATA_VALID,
> > >>>>>>> otherwise the device driver that negotiates this feature may
> > >>>>>>> fail to live
> > >>>>>>> migration.
> > >>>>>>> Am I right?
> > >>>>>>>
> > >>>>>>> I'm not sure how GUEST_CSUM works now as it should also suffer
> > >>>>>>> from the
> > >>>>>>> above
> > >>>>>>> mentioned issues with live migration, but no devices are
> > >>>>>>> reporting this
> > >>>>>>> right now.
> > >>>>>>>
> > >>>>>>> Maybe, each device only supports checksum verification for
> > >>>>>>> TCP/UDP by
> > >>>>>>> default? I don't know.
> > >>>>>>> But I hope we can focus on this and get consensus, because our
> > >>>>>>> hw release
> > >>>>>>> date is coming soon.
> > >>>>>>>
> > >>>>>>> Thanks a lot!
> > >>>>>> First, DATA_VALID is not a thing that hardware should ever use.
> > >>>>>> It's a hack when packets are passed within host.
> > >>>>> Get here. Thanks!
> > >>>> So if I understand correctly, we need a new flag here and define the
> > >>>> supported protocols.
> > >>>
> > >>> For what, migration?
> > >> No.
> > >>
> > >> It's basically a question of whether or not we want to reuse
> > >> DATA_VALID. It has limitations that it only works for some specific
> > >> protocols.
> > >
> > > Yes, I understand what Xuan means is that we reuse DATA_VALID and
> > > advertise
> > > what specific protocols DATA_VALID covers.
> > >
> > > Back to supported_validate_types, now I think we really don't need to
> > > let the device
> > > provide this field. Why? Because asssuming the device provides it, it
> > > seems useless
> > > because the driver does not parse the protocol type for each packet
> > > and does not use this field.
> > > The driver and stack just want to know whether the packet is valid or
> > > checksum unneccessary.
> >
> > Hi Jason and Michael.
> >
> > Are we aligned on this?
>
> For supported_validate_types, I don't think we need it.
>
> But I'm not sure if we are aligned.
>
> >
> > If yes, I'll write a new version to refresh the thread and try to avoid
> > future rollbacks.
>
> Maybe you can post a new version.
>
> Thanks
>
> >
> > Thanks a lot!
> >
> > >
> > > Thanks!
> > >
> > >>
> > >> If we don't, we need a new flag.
> > >>
> > >> Thanks
> > >
> > >
> > > 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/
> >
>
>
> 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/
>
>

[-- Attachment #2: Type: text/html, Size: 32930 bytes --]

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Heng Qi]

在 2023/12/10 下午1:39, Yuri Benditovich 写道:
> If somebody explains the problem that this patch addresses it will be very,
> _very_ helpful.
> We _were_ sure that if the host suggests  VIRTIO_NET_F_GUEST_CSUM and the
> driver acks it - they both can do _more_ than without this feature.
> Specifically the driver claims that it is able to deal with additional
> types of incoming packets and such a way the device is able to provide
> _more_ types of incoming packets than if this feature is not acked..

Hi Yuir.

Why do you think this patch will change that..?
What types of packets a driver or device can handle will *not change* 
with this patch.

We only tell the device that when GUEST_FULL_CSUM is negotiated, the 
device *must not*
submit *TCP/UDP*[1] partially checksummed packets to the driver.
It would be better if the device can also help the driver verify the 
checksum (just like GUEST_CSUM).
The matter of identifying or verifying packets has never changed with 
this patch.

[1]

If the VIRTIO_NET_F_GUEST_CSUM feature has been negotiated, the device 
MAY set the VIRTIO_NET_HDR_F_NEEDS_CSUM bit inflags, if so:

 1. the device MUST validate the packet checksum at
    offsetcsum_offsetfromcsum_startas well as all preceding offsets;
 2. the device MUST set the packet checksum stored in the receive buffer
    to the *TCP/UDP* pseudo header;
 3. the device MUST setcsum_startandcsum_offsetsuch that calculating a
    ones’ complement checksum fromcsum_startup until the end of the
    packet and storing the result at offsetcsum_offsetfromcsum_startwill
    result in a fully checksummed packet;


Thanks.

> Shall we change our mind somehow?
> I believe that if due to the presence of this feature the driver is _not_
> able to do something this is a bug somewhere around the driver, isn't it?
> Thank you in advance for the clarification.
>
> On Thu, Dec 7, 2023 at 7:35 AM Jason Wang <jasowang@redhat.com> wrote:
>
>> On Thu, Dec 7, 2023 at 12:52 PM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>>
>>>
>>> 在 2023/12/6 下午5:03, Heng Qi 写道:
>>>>
>>>> 在 2023/12/6 下午4:46, Jason Wang 写道:
>>>>> On Wed, Dec 6, 2023 at 4:08 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com>
>>>>> wrote:
>>>>>> On Wed, 6 Dec 2023 12:36:53 +0800, Jason Wang <jasowang@redhat.com>
>>>>>> wrote:
>>>>>>> On Wed, Dec 6, 2023 at 10:21 AM Heng Qi <hengqi@linux.alibaba.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> 在 2023/12/5 下午10:45, Michael S. Tsirkin 写道:
>>>>>>>>> On Tue, Dec 05, 2023 at 10:18:32PM +0800, Heng Qi wrote:
>>>>>>>>>> 在 2023/12/5 上午11:52, Jason Wang 写道:
>>>>>>>>>>> On Mon, Dec 4, 2023 at 5:34 PM Heng Qi
>>>>>>>>>>> <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>>> 在 2023/12/4 下午5:05, Michael S. Tsirkin 写道:
>>>>>>>>>>>>> On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
>>>>>>>>>>>>>> On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin
>>>>>>>>>>>>>> <mst@redhat.com> wrote:
>>>>>>>>>>>>>>> On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang wrote:
>>>>>>>>>>>>>>>> On Mon, Dec 4, 2023 at 3:37 PM Heng Qi
>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>>>>>>>> 在 2023/12/4 下午3:18, Jason Wang 写道:
>>>>>>>>>>>>>>>>>> On Fri, Dec 1, 2023 at 3:16 PM Heng Qi
>>>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>>>>>>>>>> 在 2023/12/1 下午3:05, Jason Wang 写道:
>>>>>>>>>>>>>>>>>>>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi
>>>>>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>>>>>>>>>>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
>>>>>>>>>>>>>>>>>>>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
>>>>>>>>>>>>>>>>>>>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi
>>>>>>>>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi
>>>>>>>>>>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> To prevent readers from misunderstanding that
>>>>>>>>>>>>>>>>>>>>>>>>>> the driver can
>>>>>>>>>>>>>>>>>>>>>>>>>> only handles packets with partial checksum when
>>>>>>>>>>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we update
>>>>>>>>>>>>>>>>>>>>>>>>>> the description.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com
>>>>>>>>>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>>>>>>>>>> device-types/net/description.tex | 2 +-
>>>>>>>>>>>>>>>>>>>>>>>>>>           1 file changed, 1 insertion(+), 1
>>>>>>>>>>>>>>>>>>>>>>>>>> deletion(-)
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> diff --git a/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>>>>>>>> b/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>>>>>>>> index aff5e08..529f470 100644
>>>>>>>>>>>>>>>>>>>>>>>>>> --- a/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>>>>>>>> +++ b/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature
>>>>>>>>>>>>>>>>>>>>>>>>>> bits}\label{sec:Device Types
>>>>>>>>>>>>>>>>>>>>>>>>>> / Network Device / Feature bits
>>>>>>>>>>>>>>>>>>>>>>>>>> \begin{description}
>>>>>>>>>>>>>>>>>>>>>>>>>> \item[VIRTIO_NET_F_CSUM (0)] Device handles
>>>>>>>>>>>>>>>>>>>>>>>>>> packets with
>>>>>>>>>>>>>>>>>>>>>>>>>> partial checksum offload.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver
>>>>>>>>>>>>>>>>>>>>>>>>>> handles packets with
>>>>>>>>>>>>>>>>>>>>>>>>>> partial checksum.
>>>>>>>>>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver
>>>>>>>>>>>>>>>>>>>>>>>>>> handles packets with
>>>>>>>>>>>>>>>>>>>>>>>>>> partial checksum or full checksum.
>>>>>>>>>>>>>>>>>>>>>>>>> So patch 2 said
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> "
>>>>>>>>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver
>>>>>>>>>>>>>>>>>>>>>>>>> handles packets with
>>>>>>>>>>>>>>>>>>>>>>>>> full checksum.
>>>>>>>>>>>>>>>>>>>>>>>>> \end{description}
>>>>>>>>>>>>>>>>>>>>>>>>> "
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Is there any difference between the two "full
>>>>>>>>>>>>>>>>>>>>>>>>> checksum" here?
>>>>>>>>>>>>>>>>>>>>>>>> There's no difference.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM
>>>>>>>>>>>>>>>>>>>>>>>> means that the driver
>>>>>>>>>>>>>>>>>>>>>>>> "can
>>>>>>>>>>>>>>>>>>>>>>>> only" handle packets with full checksum.
>>>>>>>>>>>>>>>>>>>>>>> This seems to be odd.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Driver can always handle packet with full checksum,
>>>>>>>>>>>>>>>>>>>>>>> no?
>>>>>>>>>>>>>>>>>>>>>> Yes.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I meant it
>>>>>>>>>>>>>>>>>>>>>>> will be then to be functional equivalent to !
>>>>>>>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
>>>>>>>>>>>>>>>>>>>>>> Are you referring to
>>>>>>>>>>>>>>>>>>>>>> "functional equivalent to !VIRTIO_NET_F_GUEST_CSUM" ?
>>>>>>>>>>>>>>>>>>>>> Sorry, this is a typo. I meant
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Are you referring to
>>>>>>>>>>>>>>>>>>>>> "functional equivalent to
>>>>>>>>>>>>>>>>>>>>> !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If so, I think it's no.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Maybe a description similar to the following would
>>>>>>>>>>>>>>>>>>>>>> be more clearer:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver
>>>>>>>>>>>>>>>>>>>>>> does not handle
>>>>>>>>>>>>>>>>>>>>>> packets with partial checksum.
>>>>>>>>>>>>>>>>>>>> I may miss something here, but what's the difference
>>>>>>>>>>>>>>>>>>>> between
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> !VIRTIO_NET_F_GUEST_CSUM?
>>>>>>>>>>>>>>>>>>>        From the device perspective:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers
>>>>>>>>>>>>>>>>>>> packets with full
>>>>>>>>>>>>>>>>>>> checksum to the driver,
>>>>>>>>>>>>>>>>>>> but the device can not validate the checksum for these
>>>>>>>>>>>>>>>>>>> packets. That is,
>>>>>>>>>>>>>>>>>>> the flags in virtio-net-hdr
>>>>>>>>>>>>>>>>>>> will not contain _DATA_VALID, and the driver or stack
>>>>>>>>>>>>>>>>>>> needs to validate
>>>>>>>>>>>>>>>>>>> these packets.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers
>>>>>>>>>>>>>>>>>>> packets with full
>>>>>>>>>>>>>>>>>>> checksum to the driver,
>>>>>>>>>>>>>>>>>>> and the device can validate the checksum for these
>>>>>>>>>>>>>>>>>>> packets. That is, the
>>>>>>>>>>>>>>>>>>> flags in virtio-net-hdr
>>>>>>>>>>>>>>>>>>> will contain _DATA_VALID,
>>>>>>>>>>>>>>>>>> I think DATA_VALID is optional here as device can't
>>>>>>>>>>>>>>>>>> recognize all type
>>>>>>>>>>>>>>>>>> of protocols.
>>>>>>>>>>>>>>>>> Yes, you are right, so I used "device *can*" here. Which
>>>>>>>>>>>>>>>>> packet types
>>>>>>>>>>>>>>>>> the device recognizes or validates
>>>>>>>>>>>>>>>>> depends on the device's implementation. This is also the
>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>> practice of GUEST_CSUM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> and the driver or stack does not need to
>>>>>>>>>>>>>>>>>>> validate these packets.
>>>>>>>>>>>>>>>>>> Ok, so I think there're something that is subtle here,
>>>>>>>>>>>>>>>>> Ok, I see.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> and that's why
>>>>>>>>>>>>>>>>>> I'm asking here:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1) "Driver does not handle packets with partial
>>>>>>>>>>>>>>>>>> checksum" is not
>>>>>>>>>>>>>>>>>> accurate, !GUEST_CUSM also fit for this definition.
>>>>>>>>>>>>>>>>>> 2) "Driver handles packets with full checksum" is kind
>>>>>>>>>>>>>>>>>> of ambiguous as
>>>>>>>>>>>>>>>>>> it doesn't say whether or not the packet has been
>>>>>>>>>>>>>>>>>> validated or not.
>>>>>>>>>>>>>>>>> Maybe the description below would be less subtle?
>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles
>>>>>>>>>>>>>>>>> packets with partial
>>>>>>>>>>>>>>>>> checksum or full checksum.
>>>>>>>>>>>>>>>> I'd suggest to leave it as is. As I didn't find any issue
>>>>>>>>>>>>>>>> since even
>>>>>>>>>>>>>>>> with DATA_VALID. Did you?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver
>>>>>>>>>>>>>>>>> handles packets
>>>>>>>>>>>>>>>>> with full checksum,
>>>>>>>>>>>>>>>>> and the device optionally validates the packet's checksum.
>>>>>>>>>>>>>>>> Or maybe something like (not a native speaker)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The driver handles packets with full checksum which the
>>>>>>>>>>>>>>>> device has
>>>>>>>>>>>>>>>> already validated.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> I feel we just need a proper definition of what does "full
>>>>>>>>>>>>>>> checksum"
>>>>>>>>>>>>>>> mean in this context. It is used but not defined.
>>>>>>>>>>>>>>> Assume this feature was negotiated.
>>>>>>>>>>>>>>> My understanding is that this is just like
>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM
>>>>>>>>>>>>>>> but certain values in the header are then disallowed? Which?
>>>>>>>>>>>>>>> This should be in the spec.
>>>>>>>>>>>>>> Yes, I think it is probably the headers that DATA_VALID can
>>>>>>>>>>>>>> work. We
>>>>>>>>>>>>>> never define it in the past.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY,
>>>>>>>>>>>>>> but it can
>>>>>>>>>>>>>> only work for some specific protocols:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> """
>>>>>>>>>>>>>>       *   %CHECKSUM_UNNECESSARY is applicable to following
>>>>>>>>>>>>>> protocols:
>>>>>>>>>>>>>>       *
>>>>>>>>>>>>>>       *     - TCP: IPv6 and IPv4.
>>>>>>>>>>>>>>       *     - UDP: IPv4 and IPv6. A device may apply
>>>>>>>>>>>>>> CHECKSUM_UNNECESSARY to a
>>>>>>>>>>>>>>       *       zero UDP checksum for either IPv4 or IPv6, the
>>>>>>>>>>>>>> networking stack
>>>>>>>>>>>>>>       *       may perform further validation in this case.
>>>>>>>>>>>>>>       *     - GRE: only if the checksum is present in the
>>>>>>>>>>>>>> header.
>>>>>>>>>>>>>>       *     - SCTP: indicates the CRC in SCTP header has been
>>>>>>>>>>>>>> validated.
>>>>>>>>>>>>>>       *     - FCOE: indicates the CRC in FC frame has been
>>>>>>>>>>>>>> validated.
>>>>>>>>>>>>>> """
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm not sure whether it's just fine to duplicate the
>>>>>>>>>>>>>> definition or
>>>>>>>>>>>>>> it's too late to define any now.
>>>>>>>>>>>>> I think it's mostly harmless for other protocols.
>>>>>>>>>>>> I'm not sure if this should be defined by a new FULL_CSUM
>>>>>>>>>>>> feature.
>>>>>>>>>>>> This seems to be an issue with GUEST_CSUM.
>>>>>>>>>>>>
>>>>>>>>>>>> I think we should supplement these with a new patch for
>>>>>>>>>>>> GUEST_CSUM?
>>>>>>>>>>> Probably. My understanding is:
>>>>>>>>>>>
>>>>>>>>>>> You want to reuse DATA_VALID here, so we need to stick to a
>>>>>>>>>>> consistent
>>>>>>>>>>> semantic for GUEST_CUSM and FULL_CSUM. So we need a definition
>> of
>>>>>>>>>>> "full csum" or what kind of packet could DATA_VALID work here.
>>>>>>>>>> I agree, we can be clear about what types of packets DATA_VALID
>>>>>>>>>> might
>>>>>>>>>> cover, e.g. TCP/UDP/GRE/SCTP/FoCE.
>>>>>>>>>>
>>>>>>>>>> But I think we also need something like
>>>>>>>>>> \field{supported_validate_types} to
>>>>>>>>>> indicate which packet types the device supports validating and
>>>>>>>>>> setting
>>>>>>>>>> DATA_VALID,
>>>>>>>>>> otherwise the device driver that negotiates this feature may
>>>>>>>>>> fail to live
>>>>>>>>>> migration.
>>>>>>>>>> Am I right?
>>>>>>>>>>
>>>>>>>>>> I'm not sure how GUEST_CSUM works now as it should also suffer
>>>>>>>>>> from the
>>>>>>>>>> above
>>>>>>>>>> mentioned issues with live migration, but no devices are
>>>>>>>>>> reporting this
>>>>>>>>>> right now.
>>>>>>>>>>
>>>>>>>>>> Maybe, each device only supports checksum verification for
>>>>>>>>>> TCP/UDP by
>>>>>>>>>> default? I don't know.
>>>>>>>>>> But I hope we can focus on this and get consensus, because our
>>>>>>>>>> hw release
>>>>>>>>>> date is coming soon.
>>>>>>>>>>
>>>>>>>>>> Thanks a lot!
>>>>>>>>> First, DATA_VALID is not a thing that hardware should ever use.
>>>>>>>>> It's a hack when packets are passed within host.
>>>>>>>> Get here. Thanks!
>>>>>>> So if I understand correctly, we need a new flag here and define the
>>>>>>> supported protocols.
>>>>>> For what, migration?
>>>>> No.
>>>>>
>>>>> It's basically a question of whether or not we want to reuse
>>>>> DATA_VALID. It has limitations that it only works for some specific
>>>>> protocols.
>>>> Yes, I understand what Xuan means is that we reuse DATA_VALID and
>>>> advertise
>>>> what specific protocols DATA_VALID covers.
>>>>
>>>> Back to supported_validate_types, now I think we really don't need to
>>>> let the device
>>>> provide this field. Why? Because asssuming the device provides it, it
>>>> seems useless
>>>> because the driver does not parse the protocol type for each packet
>>>> and does not use this field.
>>>> The driver and stack just want to know whether the packet is valid or
>>>> checksum unneccessary.
>>> Hi Jason and Michael.
>>>
>>> Are we aligned on this?
>> For supported_validate_types, I don't think we need it.
>>
>> But I'm not sure if we are aligned.
>>
>>> If yes, I'll write a new version to refresh the thread and try to avoid
>>> future rollbacks.
>> Maybe you can post a new version.
>>
>> Thanks
>>
>>> Thanks a lot!
>>>
>>>> Thanks!
>>>>
>>>>> If we don't, we need a new flag.
>>>>>
>>>>> Thanks
>>>>
>>>> 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/
>>
>> 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/
>>
>>


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Heng Qi]

在 2023/12/11 上午10:17, Heng Qi 写道:
>
>
> 在 2023/12/10 下午1:39, Yuri Benditovich 写道:
>> If somebody explains the problem that this patch addresses it will be 
>> very,
>> _very_ helpful.
>> We _were_ sure that if the host suggests VIRTIO_NET_F_GUEST_CSUM and the
>> driver acks it - they both can do _more_ than without this feature.
>> Specifically the driver claims that it is able to deal with additional
>> types of incoming packets and such a way the device is able to provide
>> _more_ types of incoming packets than if this feature is not acked..
>
> Hi Yuir.

Hi Yuri.

Sorry! It's a typo.

>
> Why do you think this patch will change that..?
> What types of packets a driver or device can handle will *not change* 
> with this patch.
>
> We only tell the device that when GUEST_FULL_CSUM is negotiated, the 
> device *must not*
> submit *TCP/UDP*[1] partially checksummed packets to the driver.
> It would be better if the device can also help the driver verify the 
> checksum (just like GUEST_CSUM).
> The matter of identifying or verifying packets has never changed with 
> this patch.
>
> [1]
>
> If the VIRTIO_NET_F_GUEST_CSUM feature has been negotiated, the device 
> MAY set the VIRTIO_NET_HDR_F_NEEDS_CSUM bit inflags, if so:
>
> 1. the device MUST validate the packet checksum at
>    offsetcsum_offsetfromcsum_startas well as all preceding offsets;
> 2. the device MUST set the packet checksum stored in the receive buffer
>    to the *TCP/UDP* pseudo header;
> 3. the device MUST setcsum_startandcsum_offsetsuch that calculating a
>    ones’ complement checksum fromcsum_startup until the end of the
>    packet and storing the result at offsetcsum_offsetfromcsum_startwill
>    result in a fully checksummed packet;
>
>
> Thanks.
>
>> Shall we change our mind somehow?
>> I believe that if due to the presence of this feature the driver is 
>> _not_
>> able to do something this is a bug somewhere around the driver, isn't 
>> it?
>> Thank you in advance for the clarification.
>>
>> On Thu, Dec 7, 2023 at 7:35 AM Jason Wang <jasowang@redhat.com> wrote:
>>
>>> On Thu, Dec 7, 2023 at 12:52 PM Heng Qi <hengqi@linux.alibaba.com> 
>>> wrote:
>>>>
>>>>
>>>> 在 2023/12/6 下午5:03, Heng Qi 写道:
>>>>>
>>>>> 在 2023/12/6 下午4:46, Jason Wang 写道:
>>>>>> On Wed, Dec 6, 2023 at 4:08 PM Xuan Zhuo 
>>>>>> <xuanzhuo@linux.alibaba.com>
>>>>>> wrote:
>>>>>>> On Wed, 6 Dec 2023 12:36:53 +0800, Jason Wang <jasowang@redhat.com>
>>>>>>> wrote:
>>>>>>>> On Wed, Dec 6, 2023 at 10:21 AM Heng Qi <hengqi@linux.alibaba.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> 在 2023/12/5 下午10:45, Michael S. Tsirkin 写道:
>>>>>>>>>> On Tue, Dec 05, 2023 at 10:18:32PM +0800, Heng Qi wrote:
>>>>>>>>>>> 在 2023/12/5 上午11:52, Jason Wang 写道:
>>>>>>>>>>>> On Mon, Dec 4, 2023 at 5:34 PM Heng Qi
>>>>>>>>>>>> <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>>>> 在 2023/12/4 下午5:05, Michael S. Tsirkin 写道:
>>>>>>>>>>>>>> On Mon, Dec 04, 2023 at 04:59:49PM +0800, Jason Wang wrote:
>>>>>>>>>>>>>>> On Mon, Dec 4, 2023 at 4:53 PM Michael S. Tsirkin
>>>>>>>>>>>>>>> <mst@redhat.com> wrote:
>>>>>>>>>>>>>>>> On Mon, Dec 04, 2023 at 04:49:46PM +0800, Jason Wang 
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> On Mon, Dec 4, 2023 at 3:37 PM Heng Qi
>>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>>>>>>>>> 在 2023/12/4 下午3:18, Jason Wang 写道:
>>>>>>>>>>>>>>>>>>> On Fri, Dec 1, 2023 at 3:16 PM Heng Qi
>>>>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>>>>>>>>>>> 在 2023/12/1 下午3:05, Jason Wang 写道:
>>>>>>>>>>>>>>>>>>>>> On Fri, Dec 1, 2023 at 2:30 PM Heng Qi
>>>>>>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com> wrote:
>>>>>>>>>>>>>>>>>>>>>> 在 2023/12/1 下午2:24, Heng Qi 写道:
>>>>>>>>>>>>>>>>>>>>>>> 在 2023/12/1 下午1:18, Jason Wang 写道:
>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Nov 29, 2023 at 4:23 PM Heng Qi
>>>>>>>>>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> 在 2023/11/29 下午4:00, Jason Wang 写道:
>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Nov 28, 2023 at 4:08 PM Heng Qi
>>>>>>>>>>>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com>
>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> To prevent readers from misunderstanding that
>>>>>>>>>>>>>>>>>>>>>>>>>>> the driver can
>>>>>>>>>>>>>>>>>>>>>>>>>>> only handles packets with partial checksum when
>>>>>>>>>>>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM is negotiated, we 
>>>>>>>>>>>>>>>>>>>>>>>>>>> update
>>>>>>>>>>>>>>>>>>>>>>>>>>> the description.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Signed-off-by: Heng Qi 
>>>>>>>>>>>>>>>>>>>>>>>>>>> <hengqi@linux.alibaba.com
>>>>>>>>>>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>>>>>>>>>>> device-types/net/description.tex | 2 +-
>>>>>>>>>>>>>>>>>>>>>>>>>>>           1 file changed, 1 insertion(+), 1
>>>>>>>>>>>>>>>>>>>>>>>>>>> deletion(-)
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> diff --git a/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>>>>>>>>> b/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>>>>>>>>> index aff5e08..529f470 100644
>>>>>>>>>>>>>>>>>>>>>>>>>>> --- a/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>>>>>>>>> +++ b/device-types/net/description.tex
>>>>>>>>>>>>>>>>>>>>>>>>>>> @@ -38,7 +38,7 @@ \subsection{Feature
>>>>>>>>>>>>>>>>>>>>>>>>>>> bits}\label{sec:Device Types
>>>>>>>>>>>>>>>>>>>>>>>>>>> / Network Device / Feature bits
>>>>>>>>>>>>>>>>>>>>>>>>>>> \begin{description}
>>>>>>>>>>>>>>>>>>>>>>>>>>> \item[VIRTIO_NET_F_CSUM (0)] Device handles
>>>>>>>>>>>>>>>>>>>>>>>>>>> packets with
>>>>>>>>>>>>>>>>>>>>>>>>>>> partial checksum offload.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> -\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver
>>>>>>>>>>>>>>>>>>>>>>>>>>> handles packets with
>>>>>>>>>>>>>>>>>>>>>>>>>>> partial checksum.
>>>>>>>>>>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver
>>>>>>>>>>>>>>>>>>>>>>>>>>> handles packets with
>>>>>>>>>>>>>>>>>>>>>>>>>>> partial checksum or full checksum.
>>>>>>>>>>>>>>>>>>>>>>>>>> So patch 2 said
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> "
>>>>>>>>>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver
>>>>>>>>>>>>>>>>>>>>>>>>>> handles packets with
>>>>>>>>>>>>>>>>>>>>>>>>>> full checksum.
>>>>>>>>>>>>>>>>>>>>>>>>>> \end{description}
>>>>>>>>>>>>>>>>>>>>>>>>>> "
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Is there any difference between the two "full
>>>>>>>>>>>>>>>>>>>>>>>>>> checksum" here?
>>>>>>>>>>>>>>>>>>>>>>>>> There's no difference.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The core is that VIRTIO_NET_F_GUEST_FULL_CSUM
>>>>>>>>>>>>>>>>>>>>>>>>> means that the driver
>>>>>>>>>>>>>>>>>>>>>>>>> "can
>>>>>>>>>>>>>>>>>>>>>>>>> only" handle packets with full checksum.
>>>>>>>>>>>>>>>>>>>>>>>> This seems to be odd.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Driver can always handle packet with full 
>>>>>>>>>>>>>>>>>>>>>>>> checksum,
>>>>>>>>>>>>>>>>>>>>>>>> no?
>>>>>>>>>>>>>>>>>>>>>>> Yes.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I meant it
>>>>>>>>>>>>>>>>>>>>>>>> will be then to be functional equivalent to !
>>>>>>>>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM?
>>>>>>>>>>>>>>>>>>>>>>> Are you referring to
>>>>>>>>>>>>>>>>>>>>>>> "functional equivalent to 
>>>>>>>>>>>>>>>>>>>>>>> !VIRTIO_NET_F_GUEST_CSUM" ?
>>>>>>>>>>>>>>>>>>>>>> Sorry, this is a typo. I meant
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Are you referring to
>>>>>>>>>>>>>>>>>>>>>> "functional equivalent to
>>>>>>>>>>>>>>>>>>>>>> !VIRTIO_NET_F_GUEST_FULL_CSUM" ?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> If so, I think it's no.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Maybe a description similar to the following would
>>>>>>>>>>>>>>>>>>>>>>> be more clearer:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] Driver
>>>>>>>>>>>>>>>>>>>>>>> does not handle
>>>>>>>>>>>>>>>>>>>>>>> packets with partial checksum.
>>>>>>>>>>>>>>>>>>>>> I may miss something here, but what's the difference
>>>>>>>>>>>>>>>>>>>>> between
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_FULL_CSUM
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> !VIRTIO_NET_F_GUEST_CSUM?
>>>>>>>>>>>>>>>>>>>>        From the device perspective:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If !VIRTIO_NET_F_GUEST_CSUM, the device delivers
>>>>>>>>>>>>>>>>>>>> packets with full
>>>>>>>>>>>>>>>>>>>> checksum to the driver,
>>>>>>>>>>>>>>>>>>>> but the device can not validate the checksum for these
>>>>>>>>>>>>>>>>>>>> packets. That is,
>>>>>>>>>>>>>>>>>>>> the flags in virtio-net-hdr
>>>>>>>>>>>>>>>>>>>> will not contain _DATA_VALID, and the driver or stack
>>>>>>>>>>>>>>>>>>>> needs to validate
>>>>>>>>>>>>>>>>>>>> these packets.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If VIRTIO_NET_F_GUEST_FULL_CSUM, the device delivers
>>>>>>>>>>>>>>>>>>>> packets with full
>>>>>>>>>>>>>>>>>>>> checksum to the driver,
>>>>>>>>>>>>>>>>>>>> and the device can validate the checksum for these
>>>>>>>>>>>>>>>>>>>> packets. That is, the
>>>>>>>>>>>>>>>>>>>> flags in virtio-net-hdr
>>>>>>>>>>>>>>>>>>>> will contain _DATA_VALID,
>>>>>>>>>>>>>>>>>>> I think DATA_VALID is optional here as device can't
>>>>>>>>>>>>>>>>>>> recognize all type
>>>>>>>>>>>>>>>>>>> of protocols.
>>>>>>>>>>>>>>>>>> Yes, you are right, so I used "device *can*" here. Which
>>>>>>>>>>>>>>>>>> packet types
>>>>>>>>>>>>>>>>>> the device recognizes or validates
>>>>>>>>>>>>>>>>>> depends on the device's implementation. This is also the
>>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>> practice of GUEST_CSUM.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> and the driver or stack does not need to
>>>>>>>>>>>>>>>>>>>> validate these packets.
>>>>>>>>>>>>>>>>>>> Ok, so I think there're something that is subtle here,
>>>>>>>>>>>>>>>>>> Ok, I see.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> and that's why
>>>>>>>>>>>>>>>>>>> I'm asking here:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 1) "Driver does not handle packets with partial
>>>>>>>>>>>>>>>>>>> checksum" is not
>>>>>>>>>>>>>>>>>>> accurate, !GUEST_CUSM also fit for this definition.
>>>>>>>>>>>>>>>>>>> 2) "Driver handles packets with full checksum" is kind
>>>>>>>>>>>>>>>>>>> of ambiguous as
>>>>>>>>>>>>>>>>>>> it doesn't say whether or not the packet has been
>>>>>>>>>>>>>>>>>>> validated or not.
>>>>>>>>>>>>>>>>>> Maybe the description below would be less subtle?
>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_CSUM (1)] Driver handles
>>>>>>>>>>>>>>>>>> packets with partial
>>>>>>>>>>>>>>>>>> checksum or full checksum.
>>>>>>>>>>>>>>>>> I'd suggest to leave it as is. As I didn't find any issue
>>>>>>>>>>>>>>>>> since even
>>>>>>>>>>>>>>>>> with DATA_VALID. Did you?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> +\item[VIRTIO_NET_F_GUEST_FULL_CSUM (64)] The driver
>>>>>>>>>>>>>>>>>> handles packets
>>>>>>>>>>>>>>>>>> with full checksum,
>>>>>>>>>>>>>>>>>> and the device optionally validates the packet's 
>>>>>>>>>>>>>>>>>> checksum.
>>>>>>>>>>>>>>>>> Or maybe something like (not a native speaker)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The driver handles packets with full checksum which the
>>>>>>>>>>>>>>>>> device has
>>>>>>>>>>>>>>>>> already validated.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>> I feel we just need a proper definition of what does "full
>>>>>>>>>>>>>>>> checksum"
>>>>>>>>>>>>>>>> mean in this context. It is used but not defined.
>>>>>>>>>>>>>>>> Assume this feature was negotiated.
>>>>>>>>>>>>>>>> My understanding is that this is just like
>>>>>>>>>>>>>>>> VIRTIO_NET_F_GUEST_CSUM
>>>>>>>>>>>>>>>> but certain values in the header are then disallowed? 
>>>>>>>>>>>>>>>> Which?
>>>>>>>>>>>>>>>> This should be in the spec.
>>>>>>>>>>>>>>> Yes, I think it is probably the headers that DATA_VALID can
>>>>>>>>>>>>>>> work. We
>>>>>>>>>>>>>>> never define it in the past.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> E.g in the Linux we map DATA_VALID to CHECKSUM_UNNECESSARY,
>>>>>>>>>>>>>>> but it can
>>>>>>>>>>>>>>> only work for some specific protocols:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> """
>>>>>>>>>>>>>>>       *   %CHECKSUM_UNNECESSARY is applicable to following
>>>>>>>>>>>>>>> protocols:
>>>>>>>>>>>>>>>       *
>>>>>>>>>>>>>>>       *     - TCP: IPv6 and IPv4.
>>>>>>>>>>>>>>>       *     - UDP: IPv4 and IPv6. A device may apply
>>>>>>>>>>>>>>> CHECKSUM_UNNECESSARY to a
>>>>>>>>>>>>>>>       *       zero UDP checksum for either IPv4 or IPv6, 
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> networking stack
>>>>>>>>>>>>>>>       *       may perform further validation in this case.
>>>>>>>>>>>>>>>       *     - GRE: only if the checksum is present in the
>>>>>>>>>>>>>>> header.
>>>>>>>>>>>>>>>       *     - SCTP: indicates the CRC in SCTP header has 
>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>> validated.
>>>>>>>>>>>>>>>       *     - FCOE: indicates the CRC in FC frame has been
>>>>>>>>>>>>>>> validated.
>>>>>>>>>>>>>>> """
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm not sure whether it's just fine to duplicate the
>>>>>>>>>>>>>>> definition or
>>>>>>>>>>>>>>> it's too late to define any now.
>>>>>>>>>>>>>> I think it's mostly harmless for other protocols.
>>>>>>>>>>>>> I'm not sure if this should be defined by a new FULL_CSUM
>>>>>>>>>>>>> feature.
>>>>>>>>>>>>> This seems to be an issue with GUEST_CSUM.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think we should supplement these with a new patch for
>>>>>>>>>>>>> GUEST_CSUM?
>>>>>>>>>>>> Probably. My understanding is:
>>>>>>>>>>>>
>>>>>>>>>>>> You want to reuse DATA_VALID here, so we need to stick to a
>>>>>>>>>>>> consistent
>>>>>>>>>>>> semantic for GUEST_CUSM and FULL_CSUM. So we need a definition
>>> of
>>>>>>>>>>>> "full csum" or what kind of packet could DATA_VALID work here.
>>>>>>>>>>> I agree, we can be clear about what types of packets DATA_VALID
>>>>>>>>>>> might
>>>>>>>>>>> cover, e.g. TCP/UDP/GRE/SCTP/FoCE.
>>>>>>>>>>>
>>>>>>>>>>> But I think we also need something like
>>>>>>>>>>> \field{supported_validate_types} to
>>>>>>>>>>> indicate which packet types the device supports validating and
>>>>>>>>>>> setting
>>>>>>>>>>> DATA_VALID,
>>>>>>>>>>> otherwise the device driver that negotiates this feature may
>>>>>>>>>>> fail to live
>>>>>>>>>>> migration.
>>>>>>>>>>> Am I right?
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure how GUEST_CSUM works now as it should also suffer
>>>>>>>>>>> from the
>>>>>>>>>>> above
>>>>>>>>>>> mentioned issues with live migration, but no devices are
>>>>>>>>>>> reporting this
>>>>>>>>>>> right now.
>>>>>>>>>>>
>>>>>>>>>>> Maybe, each device only supports checksum verification for
>>>>>>>>>>> TCP/UDP by
>>>>>>>>>>> default? I don't know.
>>>>>>>>>>> But I hope we can focus on this and get consensus, because our
>>>>>>>>>>> hw release
>>>>>>>>>>> date is coming soon.
>>>>>>>>>>>
>>>>>>>>>>> Thanks a lot!
>>>>>>>>>> First, DATA_VALID is not a thing that hardware should ever use.
>>>>>>>>>> It's a hack when packets are passed within host.
>>>>>>>>> Get here. Thanks!
>>>>>>>> So if I understand correctly, we need a new flag here and 
>>>>>>>> define the
>>>>>>>> supported protocols.
>>>>>>> For what, migration?
>>>>>> No.
>>>>>>
>>>>>> It's basically a question of whether or not we want to reuse
>>>>>> DATA_VALID. It has limitations that it only works for some specific
>>>>>> protocols.
>>>>> Yes, I understand what Xuan means is that we reuse DATA_VALID and
>>>>> advertise
>>>>> what specific protocols DATA_VALID covers.
>>>>>
>>>>> Back to supported_validate_types, now I think we really don't need to
>>>>> let the device
>>>>> provide this field. Why? Because asssuming the device provides it, it
>>>>> seems useless
>>>>> because the driver does not parse the protocol type for each packet
>>>>> and does not use this field.
>>>>> The driver and stack just want to know whether the packet is valid or
>>>>> checksum unneccessary.
>>>> Hi Jason and Michael.
>>>>
>>>> Are we aligned on this?
>>> For supported_validate_types, I don't think we need it.
>>>
>>> But I'm not sure if we are aligned.
>>>
>>>> If yes, I'll write a new version to refresh the thread and try to 
>>>> avoid
>>>> future rollbacks.
>>> Maybe you can post a new version.
>>>
>>> Thanks
>>>
>>>> Thanks a lot!
>>>>
>>>>> Thanks!
>>>>>
>>>>>> If we don't, we need a new flag.
>>>>>>
>>>>>> Thanks
>>>>>
>>>>> 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/
>>>
>>> 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/
>>>
>>>
>
>
> 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/


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Jason Wang]

On Mon, Dec 11, 2023 at 10:18 AM Heng Qi <hengqi@linux.alibaba.com> wrote:
>
>
>
> 在 2023/12/10 下午1:39, Yuri Benditovich 写道:
> > If somebody explains the problem that this patch addresses it will be very,
> > _very_ helpful.
> > We _were_ sure that if the host suggests  VIRTIO_NET_F_GUEST_CSUM and the
> > driver acks it - they both can do _more_ than without this feature.
> > Specifically the driver claims that it is able to deal with additional
> > types of incoming packets and such a way the device is able to provide
> > _more_ types of incoming packets than if this feature is not acked..
>
> Hi Yuir.
>
> Why do you think this patch will change that..?
> What types of packets a driver or device can handle will *not change*
> with this patch.

Well, I think the confusion came from you wanting to modify the
definition of VIRTIO_NET_F_GUEST_CSUM.

As discussed, there's no issue with the current definition:

When VIRTIO_NET_F_GUEST_CSUM is negotiated and DATA_VALID is set, the
checksum is still partial.

Or did you see any?

Thanks


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Heng Qi]

在 2023/12/11 下午3:26, Jason Wang 写道:
> On Mon, Dec 11, 2023 at 10:18 AM Heng Qi <hengqi@linux.alibaba.com> wrote:
>>
>>
>> 在 2023/12/10 下午1:39, Yuri Benditovich 写道:
>>> If somebody explains the problem that this patch addresses it will be very,
>>> _very_ helpful.
>>> We _were_ sure that if the host suggests  VIRTIO_NET_F_GUEST_CSUM and the
>>> driver acks it - they both can do _more_ than without this feature.
>>> Specifically the driver claims that it is able to deal with additional
>>> types of incoming packets and such a way the device is able to provide
>>> _more_ types of incoming packets than if this feature is not acked..
>> Hi Yuir.
>>
>> Why do you think this patch will change that..?
>> What types of packets a driver or device can handle will *not change*
>> with this patch.
> Well, I think the confusion came from you wanting to modify the
> definition of VIRTIO_NET_F_GUEST_CSUM.

As we discussed, modifications to the GUEST_CSUM definition will be 
removed in the next version.

> As discussed, there's no issue with the current definition:
>
> When VIRTIO_NET_F_GUEST_CSUM is negotiated and DATA_VALID is set, the
> checksum is still partial.

I'm confused about this sentence.

DATA_VALID will not appear in a packet together with a partial checksum.

I think what you are saying is that partial checksum means 
CHECKSUM_UNNECESSARY.

Thanks!

>
> Or did you see any?
>
> Thanks


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/

Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM.

[Heng Qi]

Hi all.

Because there are already many V4 threads and valid opinions collected!
For the review experience of maintainers, v5 is refreshed[1], please review.

[1] 
https://lists.oasis-open.org/archives/virtio-comment/202312/msg00069.html

Thanks!


在 2023/12/11 下午3:40, Heng Qi 写道:
>
>
> 在 2023/12/11 下午3:26, Jason Wang 写道:
>> On Mon, Dec 11, 2023 at 10:18 AM Heng Qi <hengqi@linux.alibaba.com> 
>> wrote:
>>>
>>>
>>> 在 2023/12/10 下午1:39, Yuri Benditovich 写道:
>>>> If somebody explains the problem that this patch addresses it will 
>>>> be very,
>>>> _very_ helpful.
>>>> We _were_ sure that if the host suggests VIRTIO_NET_F_GUEST_CSUM 
>>>> and the
>>>> driver acks it - they both can do _more_ than without this feature.
>>>> Specifically the driver claims that it is able to deal with additional
>>>> types of incoming packets and such a way the device is able to provide
>>>> _more_ types of incoming packets than if this feature is not acked..
>>> Hi Yuir.
>>>
>>> Why do you think this patch will change that..?
>>> What types of packets a driver or device can handle will *not change*
>>> with this patch.
>> Well, I think the confusion came from you wanting to modify the
>> definition of VIRTIO_NET_F_GUEST_CSUM.
>
> As we discussed, modifications to the GUEST_CSUM definition will be 
> removed in the next version.
>
>> As discussed, there's no issue with the current definition:
>>
>> When VIRTIO_NET_F_GUEST_CSUM is negotiated and DATA_VALID is set, the
>> checksum is still partial.
>
> I'm confused about this sentence.
>
> DATA_VALID will not appear in a packet together with a partial checksum.
>
> I think what you are saying is that partial checksum means 
> CHECKSUM_UNNECESSARY.
>
> Thanks!
>
>>
>> Or did you see any?
>>
>> Thanks
>
>
> 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/


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/