* [virtio-comment] [PATCH v4 0/2] virtio-net: support distinguishing between partial and full checksum @ 2023-11-28 8:07 Heng Qi 2023-11-28 8:07 ` [virtio-comment] [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM Heng Qi 2023-11-28 8:07 ` [virtio-comment] [PATCH v4 2/2] virtio-net: support distinguishing between partial and full checksum Heng Qi 0 siblings, 2 replies; 39+ messages in thread From: Heng Qi @ 2023-11-28 8:07 UTC (permalink / raw) To: virtio-comment; +Cc: Jason Wang, Michael S . Tsirkin, Xuan Zhuo 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* [virtio-comment] [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-11-28 8:07 [virtio-comment] [PATCH v4 0/2] virtio-net: support distinguishing between partial and full checksum Heng Qi @ 2023-11-28 8:07 ` Heng Qi 2023-11-29 8:00 ` [virtio-comment] " Jason Wang 2023-11-28 8:07 ` [virtio-comment] [PATCH v4 2/2] virtio-net: support distinguishing between partial and full checksum Heng Qi 1 sibling, 1 reply; 39+ messages in thread From: Heng Qi @ 2023-11-28 8:07 UTC (permalink / raw) To: virtio-comment; +Cc: Jason Wang, Michael S . Tsirkin, Xuan Zhuo 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/ ^ permalink raw reply related [flat|nested] 39+ messages in thread
* [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-11-28 8:07 ` [virtio-comment] [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM Heng Qi @ 2023-11-29 8:00 ` Jason Wang 2023-11-29 8:23 ` Heng Qi 0 siblings, 1 reply; 39+ messages in thread From: Jason Wang @ 2023-11-29 8:00 UTC (permalink / raw) To: Heng Qi; +Cc: virtio-comment, Michael S . Tsirkin, Xuan Zhuo 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-11-29 8:00 ` [virtio-comment] " Jason Wang @ 2023-11-29 8:23 ` Heng Qi 2023-12-01 5:18 ` Jason Wang 0 siblings, 1 reply; 39+ messages in thread From: Heng Qi @ 2023-11-29 8:23 UTC (permalink / raw) To: Jason Wang; +Cc: virtio-comment, Michael S . Tsirkin, Xuan Zhuo 在 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-11-29 8:23 ` Heng Qi @ 2023-12-01 5:18 ` Jason Wang 2023-12-01 6:24 ` Heng Qi 0 siblings, 1 reply; 39+ messages in thread From: Jason Wang @ 2023-12-01 5:18 UTC (permalink / raw) To: Heng Qi; +Cc: virtio-comment, Michael S . Tsirkin, Xuan Zhuo 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-01 5:18 ` Jason Wang @ 2023-12-01 6:24 ` Heng Qi 2023-12-01 6:29 ` Heng Qi 0 siblings, 1 reply; 39+ messages in thread From: Heng Qi @ 2023-12-01 6:24 UTC (permalink / raw) To: Jason Wang; +Cc: virtio-comment, Michael S . Tsirkin, Xuan Zhuo 在 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-01 6:24 ` Heng Qi @ 2023-12-01 6:29 ` Heng Qi 2023-12-01 7:05 ` Jason Wang 0 siblings, 1 reply; 39+ messages in thread From: Heng Qi @ 2023-12-01 6:29 UTC (permalink / raw) To: Jason Wang; +Cc: virtio-comment, Michael S . Tsirkin, Xuan Zhuo 在 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-01 6:29 ` Heng Qi @ 2023-12-01 7:05 ` Jason Wang 2023-12-01 7:15 ` Heng Qi 0 siblings, 1 reply; 39+ messages in thread From: Jason Wang @ 2023-12-01 7:05 UTC (permalink / raw) To: Heng Qi; +Cc: virtio-comment, Michael S . Tsirkin, Xuan Zhuo 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-01 7:05 ` Jason Wang @ 2023-12-01 7:15 ` Heng Qi 2023-12-04 7:18 ` Jason Wang 0 siblings, 1 reply; 39+ messages in thread From: Heng Qi @ 2023-12-01 7:15 UTC (permalink / raw) To: Jason Wang; +Cc: virtio-comment, Michael S . Tsirkin, Xuan Zhuo 在 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-01 7:15 ` Heng Qi @ 2023-12-04 7:18 ` Jason Wang 2023-12-04 7:37 ` Heng Qi 0 siblings, 1 reply; 39+ messages in thread From: Jason Wang @ 2023-12-04 7:18 UTC (permalink / raw) To: Heng Qi; +Cc: virtio-comment, Michael S . Tsirkin, Xuan Zhuo 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-04 7:18 ` Jason Wang @ 2023-12-04 7:37 ` Heng Qi 2023-12-04 8:49 ` Jason Wang 0 siblings, 1 reply; 39+ messages in thread From: Heng Qi @ 2023-12-04 7:37 UTC (permalink / raw) To: Jason Wang; +Cc: virtio-comment, Michael S . Tsirkin, Xuan Zhuo 在 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-04 7:37 ` Heng Qi @ 2023-12-04 8:49 ` Jason Wang 2023-12-04 8:53 ` Michael S. Tsirkin 2023-12-04 9:06 ` Heng Qi 0 siblings, 2 replies; 39+ messages in thread From: Jason Wang @ 2023-12-04 8:49 UTC (permalink / raw) To: Heng Qi; +Cc: virtio-comment, Michael S . Tsirkin, Xuan Zhuo 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-04 8:49 ` Jason Wang @ 2023-12-04 8:53 ` Michael S. Tsirkin 2023-12-04 8:59 ` Jason Wang 2023-12-04 9:06 ` Heng Qi 1 sibling, 1 reply; 39+ messages in thread From: Michael S. Tsirkin @ 2023-12-04 8:53 UTC (permalink / raw) To: Jason Wang; +Cc: Heng Qi, virtio-comment, Xuan Zhuo 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-04 8:53 ` Michael S. Tsirkin @ 2023-12-04 8:59 ` Jason Wang 2023-12-04 9:05 ` Michael S. Tsirkin 0 siblings, 1 reply; 39+ messages in thread From: Jason Wang @ 2023-12-04 8:59 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: Heng Qi, virtio-comment, Xuan Zhuo 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-04 8:59 ` Jason Wang @ 2023-12-04 9:05 ` Michael S. Tsirkin 2023-12-04 9:34 ` Heng Qi 0 siblings, 1 reply; 39+ messages in thread From: Michael S. Tsirkin @ 2023-12-04 9:05 UTC (permalink / raw) To: Jason Wang; +Cc: Heng Qi, virtio-comment, Xuan Zhuo 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-04 9:05 ` Michael S. Tsirkin @ 2023-12-04 9:34 ` Heng Qi 2023-12-05 3:52 ` Jason Wang 0 siblings, 1 reply; 39+ messages in thread From: Heng Qi @ 2023-12-04 9:34 UTC (permalink / raw) To: Michael S. Tsirkin, Jason Wang; +Cc: virtio-comment, Xuan Zhuo 在 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-04 9:34 ` Heng Qi @ 2023-12-05 3:52 ` Jason Wang 2023-12-05 14:18 ` Heng Qi 0 siblings, 1 reply; 39+ messages in thread From: Jason Wang @ 2023-12-05 3:52 UTC (permalink / raw) To: Heng Qi; +Cc: Michael S. Tsirkin, virtio-comment, Xuan Zhuo 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-05 3:52 ` Jason Wang @ 2023-12-05 14:18 ` Heng Qi 2023-12-05 14:45 ` Michael S. Tsirkin 2023-12-06 4:35 ` Jason Wang 0 siblings, 2 replies; 39+ messages in thread From: Heng Qi @ 2023-12-05 14:18 UTC (permalink / raw) To: Jason Wang, Michael S. Tsirkin; +Cc: virtio-comment, Xuan Zhuo 在 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-05 14:18 ` Heng Qi @ 2023-12-05 14:45 ` Michael S. Tsirkin 2023-12-06 2:21 ` Heng Qi 2023-12-06 4:35 ` Jason Wang 1 sibling, 1 reply; 39+ messages in thread From: Michael S. Tsirkin @ 2023-12-05 14:45 UTC (permalink / raw) To: Heng Qi; +Cc: Jason Wang, virtio-comment, Xuan Zhuo 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-05 14:45 ` Michael S. Tsirkin @ 2023-12-06 2:21 ` Heng Qi 2023-12-06 4:36 ` Jason Wang 0 siblings, 1 reply; 39+ messages in thread From: Heng Qi @ 2023-12-06 2:21 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: Jason Wang, virtio-comment, Xuan Zhuo 在 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-06 2:21 ` Heng Qi @ 2023-12-06 4:36 ` Jason Wang 2023-12-06 4:51 ` Heng Qi 2023-12-06 7:57 ` Xuan Zhuo 0 siblings, 2 replies; 39+ messages in thread From: Jason Wang @ 2023-12-06 4:36 UTC (permalink / raw) To: Heng Qi; +Cc: Michael S. Tsirkin, virtio-comment, Xuan Zhuo 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-06 4:36 ` Jason Wang @ 2023-12-06 4:51 ` Heng Qi 2023-12-06 6:51 ` Michael S. Tsirkin 2023-12-06 7:57 ` Xuan Zhuo 1 sibling, 1 reply; 39+ messages in thread From: Heng Qi @ 2023-12-06 4:51 UTC (permalink / raw) To: Jason Wang; +Cc: Michael S. Tsirkin, virtio-comment, Xuan Zhuo 在 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-06 4:51 ` Heng Qi @ 2023-12-06 6:51 ` Michael S. Tsirkin 2023-12-06 7:54 ` Xuan Zhuo 0 siblings, 1 reply; 39+ messages in thread From: Michael S. Tsirkin @ 2023-12-06 6:51 UTC (permalink / raw) To: Heng Qi; +Cc: Jason Wang, virtio-comment, Xuan Zhuo 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-06 6:51 ` Michael S. Tsirkin @ 2023-12-06 7:54 ` Xuan Zhuo 0 siblings, 0 replies; 39+ messages in thread From: Xuan Zhuo @ 2023-12-06 7:54 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: Jason Wang, virtio-comment, Heng Qi 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-06 4:36 ` Jason Wang 2023-12-06 4:51 ` Heng Qi @ 2023-12-06 7:57 ` Xuan Zhuo 2023-12-06 8:46 ` Jason Wang 1 sibling, 1 reply; 39+ messages in thread From: Xuan Zhuo @ 2023-12-06 7:57 UTC (permalink / raw) To: Jason Wang; +Cc: Michael S. Tsirkin, virtio-comment, Heng Qi 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-06 7:57 ` Xuan Zhuo @ 2023-12-06 8:46 ` Jason Wang 2023-12-06 9:03 ` Heng Qi 0 siblings, 1 reply; 39+ messages in thread From: Jason Wang @ 2023-12-06 8:46 UTC (permalink / raw) To: Xuan Zhuo; +Cc: Michael S. Tsirkin, virtio-comment, Heng Qi 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-06 8:46 ` Jason Wang @ 2023-12-06 9:03 ` Heng Qi 2023-12-07 4:52 ` Heng Qi 0 siblings, 1 reply; 39+ messages in thread From: Heng Qi @ 2023-12-06 9:03 UTC (permalink / raw) To: Jason Wang, Xuan Zhuo; +Cc: Michael S. Tsirkin, virtio-comment 在 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-06 9:03 ` Heng Qi @ 2023-12-07 4:52 ` Heng Qi 2023-12-07 5:34 ` Jason Wang 0 siblings, 1 reply; 39+ messages in thread From: Heng Qi @ 2023-12-07 4:52 UTC (permalink / raw) To: Jason Wang, Michael S. Tsirkin; +Cc: virtio-comment, Xuan Zhuo 在 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-07 4:52 ` Heng Qi @ 2023-12-07 5:34 ` Jason Wang 2023-12-10 5:39 ` Yuri Benditovich 0 siblings, 1 reply; 39+ messages in thread From: Jason Wang @ 2023-12-07 5:34 UTC (permalink / raw) To: Heng Qi; +Cc: Michael S. Tsirkin, virtio-comment, Xuan Zhuo 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-07 5:34 ` Jason Wang @ 2023-12-10 5:39 ` Yuri Benditovich 2023-12-11 2:17 ` Heng Qi 0 siblings, 1 reply; 39+ messages in thread From: Yuri Benditovich @ 2023-12-10 5:39 UTC (permalink / raw) To: Jason Wang; +Cc: Heng Qi, Michael S. Tsirkin, virtio-comment, Xuan Zhuo [-- 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 --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-10 5:39 ` Yuri Benditovich @ 2023-12-11 2:17 ` Heng Qi 2023-12-11 3:47 ` Heng Qi 2023-12-11 7:26 ` Jason Wang 0 siblings, 2 replies; 39+ messages in thread From: Heng Qi @ 2023-12-11 2:17 UTC (permalink / raw) To: Yuri Benditovich, Jason Wang Cc: Michael S. Tsirkin, virtio-comment, Xuan Zhuo 在 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-11 2:17 ` Heng Qi @ 2023-12-11 3:47 ` Heng Qi 2023-12-11 7:26 ` Jason Wang 1 sibling, 0 replies; 39+ messages in thread From: Heng Qi @ 2023-12-11 3:47 UTC (permalink / raw) To: Yuri Benditovich, Jason Wang Cc: Michael S. Tsirkin, virtio-comment, Xuan Zhuo 在 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-11 2:17 ` Heng Qi 2023-12-11 3:47 ` Heng Qi @ 2023-12-11 7:26 ` Jason Wang 2023-12-11 7:40 ` Heng Qi 1 sibling, 1 reply; 39+ messages in thread From: Jason Wang @ 2023-12-11 7:26 UTC (permalink / raw) To: Heng Qi; +Cc: Yuri Benditovich, Michael S. Tsirkin, virtio-comment, Xuan Zhuo 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-11 7:26 ` Jason Wang @ 2023-12-11 7:40 ` Heng Qi 2023-12-11 9:17 ` Heng Qi 0 siblings, 1 reply; 39+ messages in thread From: Heng Qi @ 2023-12-11 7:40 UTC (permalink / raw) To: Jason Wang Cc: Yuri Benditovich, Michael S. Tsirkin, virtio-comment, Xuan Zhuo 在 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-11 7:40 ` Heng Qi @ 2023-12-11 9:17 ` Heng Qi 0 siblings, 0 replies; 39+ messages in thread From: Heng Qi @ 2023-12-11 9:17 UTC (permalink / raw) To: Jason Wang, Yuri Benditovich Cc: Michael S. Tsirkin, Xuan Zhuo, virtio-comment@lists.oasis-open.org 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-05 14:18 ` Heng Qi 2023-12-05 14:45 ` Michael S. Tsirkin @ 2023-12-06 4:35 ` Jason Wang 1 sibling, 0 replies; 39+ messages in thread From: Jason Wang @ 2023-12-06 4:35 UTC (permalink / raw) To: Heng Qi; +Cc: Michael S. Tsirkin, virtio-comment, Xuan Zhuo 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-04 8:49 ` Jason Wang 2023-12-04 8:53 ` Michael S. Tsirkin @ 2023-12-04 9:06 ` Heng Qi 2023-12-04 9:08 ` Jason Wang 1 sibling, 1 reply; 39+ messages in thread From: Heng Qi @ 2023-12-04 9:06 UTC (permalink / raw) To: Jason Wang; +Cc: virtio-comment, Michael S . Tsirkin, Xuan Zhuo 在 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [virtio-comment] Re: [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM. 2023-12-04 9:06 ` Heng Qi @ 2023-12-04 9:08 ` Jason Wang 0 siblings, 0 replies; 39+ messages in thread From: Jason Wang @ 2023-12-04 9:08 UTC (permalink / raw) To: Heng Qi; +Cc: virtio-comment, Michael S . Tsirkin, Xuan Zhuo 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/ ^ permalink raw reply [flat|nested] 39+ messages in thread
* [virtio-comment] [PATCH v4 2/2] virtio-net: support distinguishing between partial and full checksum 2023-11-28 8:07 [virtio-comment] [PATCH v4 0/2] virtio-net: support distinguishing between partial and full checksum Heng Qi 2023-11-28 8:07 ` [virtio-comment] [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM Heng Qi @ 2023-11-28 8:07 ` Heng Qi 1 sibling, 0 replies; 39+ messages in thread From: Heng Qi @ 2023-11-28 8:07 UTC (permalink / raw) To: virtio-comment; +Cc: Jason Wang, Michael S . Tsirkin, Xuan Zhuo 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/ ^ permalink raw reply related [flat|nested] 39+ messages in thread
end of thread, other threads:[~2023-12-11 9:18 UTC | newest] Thread overview: 39+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-11-28 8:07 [virtio-comment] [PATCH v4 0/2] virtio-net: support distinguishing between partial and full checksum Heng Qi 2023-11-28 8:07 ` [virtio-comment] [PATCH v4 1/2] virtio-net: update description for VIRTIO_NET_F_GUEST_CSUM Heng Qi 2023-11-29 8:00 ` [virtio-comment] " Jason Wang 2023-11-29 8:23 ` Heng Qi 2023-12-01 5:18 ` Jason Wang 2023-12-01 6:24 ` Heng Qi 2023-12-01 6:29 ` Heng Qi 2023-12-01 7:05 ` Jason Wang 2023-12-01 7:15 ` Heng Qi 2023-12-04 7:18 ` Jason Wang 2023-12-04 7:37 ` Heng Qi 2023-12-04 8:49 ` Jason Wang 2023-12-04 8:53 ` Michael S. Tsirkin 2023-12-04 8:59 ` Jason Wang 2023-12-04 9:05 ` Michael S. Tsirkin 2023-12-04 9:34 ` Heng Qi 2023-12-05 3:52 ` Jason Wang 2023-12-05 14:18 ` Heng Qi 2023-12-05 14:45 ` Michael S. Tsirkin 2023-12-06 2:21 ` Heng Qi 2023-12-06 4:36 ` Jason Wang 2023-12-06 4:51 ` Heng Qi 2023-12-06 6:51 ` Michael S. Tsirkin 2023-12-06 7:54 ` Xuan Zhuo 2023-12-06 7:57 ` Xuan Zhuo 2023-12-06 8:46 ` Jason Wang 2023-12-06 9:03 ` Heng Qi 2023-12-07 4:52 ` Heng Qi 2023-12-07 5:34 ` Jason Wang 2023-12-10 5:39 ` Yuri Benditovich 2023-12-11 2:17 ` Heng Qi 2023-12-11 3:47 ` Heng Qi 2023-12-11 7:26 ` Jason Wang 2023-12-11 7:40 ` Heng Qi 2023-12-11 9:17 ` Heng Qi 2023-12-06 4:35 ` Jason Wang 2023-12-04 9:06 ` Heng Qi 2023-12-04 9:08 ` Jason Wang 2023-11-28 8:07 ` [virtio-comment] [PATCH v4 2/2] virtio-net: support distinguishing between partial and full checksum Heng Qi
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.