[virtio-comment] [PATCH 0/4] Short document fixes to inner hash feature

[virtio-comment] [PATCH 0/4] Short document fixes to inner hash feature

[Parav Pandit]

This short patches fixes the editing errors that stops the pdf and html
generation.

These 3 fixes are for the patch [1] for the github issue [2].

[1] https://lists.oasis-open.org/archives/virtio-comment/202307/msg00024.html
[2] https://github.com/oasis-tcs/virtio-spec/issues/173

Patch summary:
patch-1 place C code under listing
patch-2 avoid hyphen and extra braces
patch-3 use table as hyperlink do not work well in C code listing
patch-4 refer 'advice' as 'note'

Patch 1 to 3 appears to be must in the testing.
Patch 4 is not a fix and can be done later if it requires discussion.

Parav Pandit (4):
  virtio-net: Place C code under listing
  virtio-net: Avoid hyphen and extra braces
  virtio-net: Use table to describe inner hash to rfc mapping
  virtio-net: Use note instead of advice

 device-types/net/description.tex | 45 ++++++++++++++++++++++----------
 introduction.tex                 | 15 +++++------
 2 files changed, 38 insertions(+), 22 deletions(-)

-- 
2.26.2


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

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

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

[virtio-dev] [PATCH 0/4] Short document fixes to inner hash feature

[Parav Pandit]

This short patches fixes the editing errors that stops the pdf and html
generation.

These 3 fixes are for the patch [1] for the github issue [2].

[1] https://lists.oasis-open.org/archives/virtio-comment/202307/msg00024.html
[2] https://github.com/oasis-tcs/virtio-spec/issues/173

Patch summary:
patch-1 place C code under listing
patch-2 avoid hyphen and extra braces
patch-3 use table as hyperlink do not work well in C code listing
patch-4 refer 'advice' as 'note'

Patch 1 to 3 appears to be must in the testing.
Patch 4 is not a fix and can be done later if it requires discussion.

Parav Pandit (4):
  virtio-net: Place C code under listing
  virtio-net: Avoid hyphen and extra braces
  virtio-net: Use table to describe inner hash to rfc mapping
  virtio-net: Use note instead of advice

 device-types/net/description.tex | 45 ++++++++++++++++++++++----------
 introduction.tex                 | 15 +++++------
 2 files changed, 38 insertions(+), 22 deletions(-)

-- 
2.26.2


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

[virtio-comment] [PATCH 1/4] virtio-net: Place C code under listing

[Parav Pandit]

With extra white space for the define, pdf generation fails.
Also place the C code under listing.

Signed-off-by: Parav Pandit <parav@nvidia.com>
---
 device-types/net/description.tex | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/device-types/net/description.tex b/device-types/net/description.tex
index 206020d..6fd4a20 100644
--- a/device-types/net/description.tex
+++ b/device-types/net/description.tex
@@ -1024,12 +1024,14 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
 If VIRTIO_NET_F_HASH_TUNNEL has been negotiated, the driver can send the command
 VIRTIO_NET_CTRL_HASH_TUNNEL_SET to configure the calculation of the inner header hash.
 
+\begin{lstlisting}
 struct virtnet_hash_tunnel {
     le32 enabled_tunnel_types;
 };
 
 #define VIRTIO_NET_CTRL_HASH_TUNNEL 7
- #define VIRTIO_NET_CTRL_HASH_TUNNEL_SET 0
+#define VIRTIO_NET_CTRL_HASH_TUNNEL_SET 0
+\end{lstlisting}
 
 Field \field{enabled_tunnel_types} contains the bitmask of encapsulation types enabled for inner header hash.
 See \ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets /
-- 
2.26.2


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

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

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

[virtio-dev] [PATCH 1/4] virtio-net: Place C code under listing

[Parav Pandit]

With extra white space for the define, pdf generation fails.
Also place the C code under listing.

Signed-off-by: Parav Pandit <parav@nvidia.com>
---
 device-types/net/description.tex | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/device-types/net/description.tex b/device-types/net/description.tex
index 206020d..6fd4a20 100644
--- a/device-types/net/description.tex
+++ b/device-types/net/description.tex
@@ -1024,12 +1024,14 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
 If VIRTIO_NET_F_HASH_TUNNEL has been negotiated, the driver can send the command
 VIRTIO_NET_CTRL_HASH_TUNNEL_SET to configure the calculation of the inner header hash.
 
+\begin{lstlisting}
 struct virtnet_hash_tunnel {
     le32 enabled_tunnel_types;
 };
 
 #define VIRTIO_NET_CTRL_HASH_TUNNEL 7
- #define VIRTIO_NET_CTRL_HASH_TUNNEL_SET 0
+#define VIRTIO_NET_CTRL_HASH_TUNNEL_SET 0
+\end{lstlisting}
 
 Field \field{enabled_tunnel_types} contains the bitmask of encapsulation types enabled for inner header hash.
 See \ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets /
-- 
2.26.2


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

Re: [virtio-comment] [PATCH 1/4] virtio-net: Place C code under listing

[Cornelia Huck]

On Thu, Jul 13 2023, Parav Pandit <parav@nvidia.com> wrote:

> With extra white space for the define, pdf generation fails.
> Also place the C code under listing.
>
> Signed-off-by: Parav Pandit <parav@nvidia.com>
> ---
>  device-types/net/description.tex | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/device-types/net/description.tex b/device-types/net/description.tex
> index 206020d..6fd4a20 100644
> --- a/device-types/net/description.tex
> +++ b/device-types/net/description.tex
> @@ -1024,12 +1024,14 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
>  If VIRTIO_NET_F_HASH_TUNNEL has been negotiated, the driver can send the command
>  VIRTIO_NET_CTRL_HASH_TUNNEL_SET to configure the calculation of the inner header hash.
>  
> +\begin{lstlisting}
>  struct virtnet_hash_tunnel {
>      le32 enabled_tunnel_types;
>  };
>  
>  #define VIRTIO_NET_CTRL_HASH_TUNNEL 7
> - #define VIRTIO_NET_CTRL_HASH_TUNNEL_SET 0
> +#define VIRTIO_NET_CTRL_HASH_TUNNEL_SET 0

I think the indentation here is intentional (as in other, similare
sections.)

> +\end{lstlisting}
>  
>  Field \field{enabled_tunnel_types} contains the bitmask of encapsulation types enabled for inner header hash.
>  See \ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets /


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

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

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

[virtio-dev] Re: [virtio-comment] [PATCH 1/4] virtio-net: Place C code under listing

[Cornelia Huck]

On Thu, Jul 13 2023, Parav Pandit <parav@nvidia.com> wrote:

> With extra white space for the define, pdf generation fails.
> Also place the C code under listing.
>
> Signed-off-by: Parav Pandit <parav@nvidia.com>
> ---
>  device-types/net/description.tex | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/device-types/net/description.tex b/device-types/net/description.tex
> index 206020d..6fd4a20 100644
> --- a/device-types/net/description.tex
> +++ b/device-types/net/description.tex
> @@ -1024,12 +1024,14 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
>  If VIRTIO_NET_F_HASH_TUNNEL has been negotiated, the driver can send the command
>  VIRTIO_NET_CTRL_HASH_TUNNEL_SET to configure the calculation of the inner header hash.
>  
> +\begin{lstlisting}
>  struct virtnet_hash_tunnel {
>      le32 enabled_tunnel_types;
>  };
>  
>  #define VIRTIO_NET_CTRL_HASH_TUNNEL 7
> - #define VIRTIO_NET_CTRL_HASH_TUNNEL_SET 0
> +#define VIRTIO_NET_CTRL_HASH_TUNNEL_SET 0

I think the indentation here is intentional (as in other, similare
sections.)

> +\end{lstlisting}
>  
>  Field \field{enabled_tunnel_types} contains the bitmask of encapsulation types enabled for inner header hash.
>  See \ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets /


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

RE: [virtio-comment] [PATCH 1/4] virtio-net: Place C code under listing

[Parav Pandit]

> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Thursday, July 13, 2023 5:13 AM
> To: Parav Pandit <parav@nvidia.com>; virtio-comment@lists.oasis-open.org;
> mst@redhat.com
> On Thu, Jul 13 2023, Parav Pandit <parav@nvidia.com> wrote:
> 
> > With extra white space for the define, pdf generation fails.
> > Also place the C code under listing.
> >
> > Signed-off-by: Parav Pandit <parav@nvidia.com>
> > ---
> >  device-types/net/description.tex | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/device-types/net/description.tex
> > b/device-types/net/description.tex
> > index 206020d..6fd4a20 100644
> > --- a/device-types/net/description.tex
> > +++ b/device-types/net/description.tex
> > @@ -1024,12 +1024,14 @@ \subsubsection{Processing of Incoming
> > Packets}\label{sec:Device Types / Network  If VIRTIO_NET_F_HASH_TUNNEL
> > has been negotiated, the driver can send the command
> VIRTIO_NET_CTRL_HASH_TUNNEL_SET to configure the calculation of the inner
> header hash.
> >
> > +\begin{lstlisting}
> >  struct virtnet_hash_tunnel {
> >      le32 enabled_tunnel_types;
> >  };
> >
> >  #define VIRTIO_NET_CTRL_HASH_TUNNEL 7
> > - #define VIRTIO_NET_CTRL_HASH_TUNNEL_SET 0
> > +#define VIRTIO_NET_CTRL_HASH_TUNNEL_SET 0
> 
> I think the indentation here is intentional (as in other, similare
> sections.)
> 
Oh right. It is the command part.

> > +\end{lstlisting}
> >
> >  Field \field{enabled_tunnel_types} contains the bitmask of encapsulation
> types enabled for inner header hash.
> >  See \ref{sec:Device Types / Network Device / Device Operation /
> > Processing of Incoming Packets /


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

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

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

[virtio-dev] RE: [virtio-comment] [PATCH 1/4] virtio-net: Place C code under listing

[Parav Pandit]

> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Thursday, July 13, 2023 5:13 AM
> To: Parav Pandit <parav@nvidia.com>; virtio-comment@lists.oasis-open.org;
> mst@redhat.com
> On Thu, Jul 13 2023, Parav Pandit <parav@nvidia.com> wrote:
> 
> > With extra white space for the define, pdf generation fails.
> > Also place the C code under listing.
> >
> > Signed-off-by: Parav Pandit <parav@nvidia.com>
> > ---
> >  device-types/net/description.tex | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/device-types/net/description.tex
> > b/device-types/net/description.tex
> > index 206020d..6fd4a20 100644
> > --- a/device-types/net/description.tex
> > +++ b/device-types/net/description.tex
> > @@ -1024,12 +1024,14 @@ \subsubsection{Processing of Incoming
> > Packets}\label{sec:Device Types / Network  If VIRTIO_NET_F_HASH_TUNNEL
> > has been negotiated, the driver can send the command
> VIRTIO_NET_CTRL_HASH_TUNNEL_SET to configure the calculation of the inner
> header hash.
> >
> > +\begin{lstlisting}
> >  struct virtnet_hash_tunnel {
> >      le32 enabled_tunnel_types;
> >  };
> >
> >  #define VIRTIO_NET_CTRL_HASH_TUNNEL 7
> > - #define VIRTIO_NET_CTRL_HASH_TUNNEL_SET 0
> > +#define VIRTIO_NET_CTRL_HASH_TUNNEL_SET 0
> 
> I think the indentation here is intentional (as in other, similare
> sections.)
> 
Oh right. It is the command part.

> > +\end{lstlisting}
> >
> >  Field \field{enabled_tunnel_types} contains the bitmask of encapsulation
> types enabled for inner header hash.
> >  See \ref{sec:Device Types / Network Device / Device Operation /
> > Processing of Incoming Packets /


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

[virtio-comment] [PATCH 2/4] virtio-net: Avoid hyphen and extra braces

[Parav Pandit]

Avoid hyphen and replace it with white space like rest of the entries.
Also avoid unnecessary braces.
Name RFC as just RFC without special prefix about it.

This likely resolves the html generation errors.

Signed-off-by: Parav Pandit <parav@nvidia.com>
---
 device-types/net/description.tex |  2 +-
 introduction.tex                 | 15 +++++++--------
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/device-types/net/description.tex b/device-types/net/description.tex
index 6fd4a20..53c811f 100644
--- a/device-types/net/description.tex
+++ b/device-types/net/description.tex
@@ -904,7 +904,7 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
 \end{itemize}
 
 The per-packet hash calculation can depend on the IP packet type. See
-\hyperref[intro:IP]{[IP]}, \hyperref[intro:UDP]{[UDP]} and \hyperref[intro:TCP]{[TCP]}.
+\hyperref[intro:IP]{IP}, \hyperref[intro:UDP]{UDP} and \hyperref[intro:TCP]{TCP}.
 
 \subparagraph{Supported/enabled hash types}
 \label{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets / Hash calculation for incoming packets / Supported/enabled hash types}
diff --git a/introduction.tex b/introduction.tex
index 81f07a4..028ec17 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -101,26 +101,25 @@ \section{Normative References}\label{sec:Normative References}
 	\phantomsection\label{intro:SEC1}\textbf{[SEC1]} &
     Standards for Efficient Cryptography Group(SECG), ``SEC1: Elliptic Cureve Cryptography'', Version 1.0, September 2000.
 	\newline\url{https://www.secg.org/sec1-v2.pdf}\\
-
-	\phantomsection\label{intro:gre_rfc2784}\textbf{[GRE_rfc2784]} &
+	\phantomsection\label{intro:rfc2784}\textbf{[RFC2784]} &
     Generic Routing Encapsulation. This protocol is only specified for IPv4 and used as either the payload or delivery protocol.
 	\newline\url{https://datatracker.ietf.org/doc/rfc2784/}\\
-	\phantomsection\label{intro:gre_rfc2890}\textbf{[GRE_rfc2890]} &
-    Key and Sequence Number Extensions to GRE \ref{intro:gre_rfc2784}. This protocol describes extensions by which two fields, Key and
-    Sequence Number, can be optionally carried in the GRE Header \ref{intro:gre_rfc2784}.
+	\phantomsection\label{intro:rfc2890}\textbf{[RFC2890]} &
+    Key and Sequence Number Extensions to GRE \ref{intro:rfc2784}. This protocol describes extensions by which two fields, Key and
+    Sequence Number, can be optionally carried in the GRE Header \ref{intro:rfc2784}.
 	\newline\url{https://www.rfc-editor.org/rfc/rfc2890}\\
-	\phantomsection\label{intro:gre_rfc7676}\textbf{[GRE_rfc7676]} &
+	\phantomsection\label{intro:rfc7676}\textbf{[RFC7676]} &
     IPv6 Support for Generic Routing Encapsulation (GRE). This protocol is specified for IPv6 and used as either the payload or
     delivery protocol. Note that this does not change the GRE header format or any behaviors specified by RFC 2784 or RFC 2890.
 	\newline\url{https://datatracker.ietf.org/doc/rfc7676/}\\
-	\phantomsection\label{intro:gre_in_udp_rfc8086}\textbf{[GRE-in-UDP]} &
+	\phantomsection\label{intro:rfc8086}\textbf{[GRE in UDP]} &
     GRE-in-UDP Encapsulation. This specifies a method of encapsulating network protocol packets within GRE and UDP headers.
     This protocol is specified for IPv4 and IPv6, and used as either the payload or delivery protocol.
 	\newline\url{https://www.rfc-editor.org/rfc/rfc8086}\\
 	\phantomsection\label{intro:vxlan}\textbf{[VXLAN]} &
     Virtual eXtensible Local Area Network.
 	\newline\url{https://datatracker.ietf.org/doc/rfc7348/}\\
-	\phantomsection\label{intro:vxlan-gpe}\textbf{[VXLAN-GPE]} &
+	\phantomsection\label{intro:vxlan gpe}\textbf{[VXLAN GPE]} &
     Generic Protocol Extension for VXLAN. This protocol describes extending Virtual eXtensible Local Area Network (VXLAN) via changes to the VXLAN header.
 	\newline\url{https://www.ietf.org/archive/id/draft-ietf-nvo3-vxlan-gpe-12.txt}\\
 	\phantomsection\label{intro:geneve}\textbf{[GENEVE]} &
-- 
2.26.2


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

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

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

[virtio-dev] [PATCH 2/4] virtio-net: Avoid hyphen and extra braces

[Parav Pandit]

Avoid hyphen and replace it with white space like rest of the entries.
Also avoid unnecessary braces.
Name RFC as just RFC without special prefix about it.

This likely resolves the html generation errors.

Signed-off-by: Parav Pandit <parav@nvidia.com>
---
 device-types/net/description.tex |  2 +-
 introduction.tex                 | 15 +++++++--------
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/device-types/net/description.tex b/device-types/net/description.tex
index 6fd4a20..53c811f 100644
--- a/device-types/net/description.tex
+++ b/device-types/net/description.tex
@@ -904,7 +904,7 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
 \end{itemize}
 
 The per-packet hash calculation can depend on the IP packet type. See
-\hyperref[intro:IP]{[IP]}, \hyperref[intro:UDP]{[UDP]} and \hyperref[intro:TCP]{[TCP]}.
+\hyperref[intro:IP]{IP}, \hyperref[intro:UDP]{UDP} and \hyperref[intro:TCP]{TCP}.
 
 \subparagraph{Supported/enabled hash types}
 \label{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets / Hash calculation for incoming packets / Supported/enabled hash types}
diff --git a/introduction.tex b/introduction.tex
index 81f07a4..028ec17 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -101,26 +101,25 @@ \section{Normative References}\label{sec:Normative References}
 	\phantomsection\label{intro:SEC1}\textbf{[SEC1]} &
     Standards for Efficient Cryptography Group(SECG), ``SEC1: Elliptic Cureve Cryptography'', Version 1.0, September 2000.
 	\newline\url{https://www.secg.org/sec1-v2.pdf}\\
-
-	\phantomsection\label{intro:gre_rfc2784}\textbf{[GRE_rfc2784]} &
+	\phantomsection\label{intro:rfc2784}\textbf{[RFC2784]} &
     Generic Routing Encapsulation. This protocol is only specified for IPv4 and used as either the payload or delivery protocol.
 	\newline\url{https://datatracker.ietf.org/doc/rfc2784/}\\
-	\phantomsection\label{intro:gre_rfc2890}\textbf{[GRE_rfc2890]} &
-    Key and Sequence Number Extensions to GRE \ref{intro:gre_rfc2784}. This protocol describes extensions by which two fields, Key and
-    Sequence Number, can be optionally carried in the GRE Header \ref{intro:gre_rfc2784}.
+	\phantomsection\label{intro:rfc2890}\textbf{[RFC2890]} &
+    Key and Sequence Number Extensions to GRE \ref{intro:rfc2784}. This protocol describes extensions by which two fields, Key and
+    Sequence Number, can be optionally carried in the GRE Header \ref{intro:rfc2784}.
 	\newline\url{https://www.rfc-editor.org/rfc/rfc2890}\\
-	\phantomsection\label{intro:gre_rfc7676}\textbf{[GRE_rfc7676]} &
+	\phantomsection\label{intro:rfc7676}\textbf{[RFC7676]} &
     IPv6 Support for Generic Routing Encapsulation (GRE). This protocol is specified for IPv6 and used as either the payload or
     delivery protocol. Note that this does not change the GRE header format or any behaviors specified by RFC 2784 or RFC 2890.
 	\newline\url{https://datatracker.ietf.org/doc/rfc7676/}\\
-	\phantomsection\label{intro:gre_in_udp_rfc8086}\textbf{[GRE-in-UDP]} &
+	\phantomsection\label{intro:rfc8086}\textbf{[GRE in UDP]} &
     GRE-in-UDP Encapsulation. This specifies a method of encapsulating network protocol packets within GRE and UDP headers.
     This protocol is specified for IPv4 and IPv6, and used as either the payload or delivery protocol.
 	\newline\url{https://www.rfc-editor.org/rfc/rfc8086}\\
 	\phantomsection\label{intro:vxlan}\textbf{[VXLAN]} &
     Virtual eXtensible Local Area Network.
 	\newline\url{https://datatracker.ietf.org/doc/rfc7348/}\\
-	\phantomsection\label{intro:vxlan-gpe}\textbf{[VXLAN-GPE]} &
+	\phantomsection\label{intro:vxlan gpe}\textbf{[VXLAN GPE]} &
     Generic Protocol Extension for VXLAN. This protocol describes extending Virtual eXtensible Local Area Network (VXLAN) via changes to the VXLAN header.
 	\newline\url{https://www.ietf.org/archive/id/draft-ietf-nvo3-vxlan-gpe-12.txt}\\
 	\phantomsection\label{intro:geneve}\textbf{[GENEVE]} &
-- 
2.26.2


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

[virtio-comment] Re: [PATCH 2/4] virtio-net: Avoid hyphen and extra braces

[Cornelia Huck]

On Thu, Jul 13 2023, Parav Pandit <parav@nvidia.com> wrote:

> Avoid hyphen and replace it with white space like rest of the entries.
> Also avoid unnecessary braces.
> Name RFC as just RFC without special prefix about it.
>
> This likely resolves the html generation errors.
>
> Signed-off-by: Parav Pandit <parav@nvidia.com>
> ---
>  device-types/net/description.tex |  2 +-
>  introduction.tex                 | 15 +++++++--------
>  2 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/device-types/net/description.tex b/device-types/net/description.tex
> index 6fd4a20..53c811f 100644
> --- a/device-types/net/description.tex
> +++ b/device-types/net/description.tex
> @@ -904,7 +904,7 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
>  \end{itemize}
>  
>  The per-packet hash calculation can depend on the IP packet type. See
> -\hyperref[intro:IP]{[IP]}, \hyperref[intro:UDP]{[UDP]} and \hyperref[intro:TCP]{[TCP]}.
> +\hyperref[intro:IP]{IP}, \hyperref[intro:UDP]{UDP} and \hyperref[intro:TCP]{TCP}.

I'd keep that as-is (I think it looks nicer with the brackets).

>  
>  \subparagraph{Supported/enabled hash types}
>  \label{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets / Hash calculation for incoming packets / Supported/enabled hash types}
> diff --git a/introduction.tex b/introduction.tex
> index 81f07a4..028ec17 100644
> --- a/introduction.tex
> +++ b/introduction.tex
> @@ -101,26 +101,25 @@ \section{Normative References}\label{sec:Normative References}
>  	\phantomsection\label{intro:SEC1}\textbf{[SEC1]} &
>      Standards for Efficient Cryptography Group(SECG), ``SEC1: Elliptic Cureve Cryptography'', Version 1.0, September 2000.
>  	\newline\url{https://www.secg.org/sec1-v2.pdf}\\
> -
> -	\phantomsection\label{intro:gre_rfc2784}\textbf{[GRE_rfc2784]} &
> +	\phantomsection\label{intro:rfc2784}\textbf{[RFC2784]} &
>      Generic Routing Encapsulation. This protocol is only specified for IPv4 and used as either the payload or delivery protocol.
>  	\newline\url{https://datatracker.ietf.org/doc/rfc2784/}\\
> -	\phantomsection\label{intro:gre_rfc2890}\textbf{[GRE_rfc2890]} &
> -    Key and Sequence Number Extensions to GRE \ref{intro:gre_rfc2784}. This protocol describes extensions by which two fields, Key and
> -    Sequence Number, can be optionally carried in the GRE Header \ref{intro:gre_rfc2784}.
> +	\phantomsection\label{intro:rfc2890}\textbf{[RFC2890]} &
> +    Key and Sequence Number Extensions to GRE \ref{intro:rfc2784}. This protocol describes extensions by which two fields, Key and
> +    Sequence Number, can be optionally carried in the GRE Header \ref{intro:rfc2784}.
>  	\newline\url{https://www.rfc-editor.org/rfc/rfc2890}\\
> -	\phantomsection\label{intro:gre_rfc7676}\textbf{[GRE_rfc7676]} &
> +	\phantomsection\label{intro:rfc7676}\textbf{[RFC7676]} &
>      IPv6 Support for Generic Routing Encapsulation (GRE). This protocol is specified for IPv6 and used as either the payload or
>      delivery protocol. Note that this does not change the GRE header format or any behaviors specified by RFC 2784 or RFC 2890.
>  	\newline\url{https://datatracker.ietf.org/doc/rfc7676/}\\
> -	\phantomsection\label{intro:gre_in_udp_rfc8086}\textbf{[GRE-in-UDP]} &
> +	\phantomsection\label{intro:rfc8086}\textbf{[GRE in UDP]} &

Hyphens are ok, I'd keep it.

>      GRE-in-UDP Encapsulation. This specifies a method of encapsulating network protocol packets within GRE and UDP headers.
>      This protocol is specified for IPv4 and IPv6, and used as either the payload or delivery protocol.
>  	\newline\url{https://www.rfc-editor.org/rfc/rfc8086}\\
>  	\phantomsection\label{intro:vxlan}\textbf{[VXLAN]} &
>      Virtual eXtensible Local Area Network.
>  	\newline\url{https://datatracker.ietf.org/doc/rfc7348/}\\
> -	\phantomsection\label{intro:vxlan-gpe}\textbf{[VXLAN-GPE]} &
> +	\phantomsection\label{intro:vxlan gpe}\textbf{[VXLAN GPE]} &
>      Generic Protocol Extension for VXLAN. This protocol describes extending Virtual eXtensible Local Area Network (VXLAN) via changes to the VXLAN header.
>  	\newline\url{https://www.ietf.org/archive/id/draft-ietf-nvo3-vxlan-gpe-12.txt}\\
>  	\phantomsection\label{intro:geneve}\textbf{[GENEVE]} &


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

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

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

[virtio-dev] Re: [PATCH 2/4] virtio-net: Avoid hyphen and extra braces

[Cornelia Huck]

On Thu, Jul 13 2023, Parav Pandit <parav@nvidia.com> wrote:

> Avoid hyphen and replace it with white space like rest of the entries.
> Also avoid unnecessary braces.
> Name RFC as just RFC without special prefix about it.
>
> This likely resolves the html generation errors.
>
> Signed-off-by: Parav Pandit <parav@nvidia.com>
> ---
>  device-types/net/description.tex |  2 +-
>  introduction.tex                 | 15 +++++++--------
>  2 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/device-types/net/description.tex b/device-types/net/description.tex
> index 6fd4a20..53c811f 100644
> --- a/device-types/net/description.tex
> +++ b/device-types/net/description.tex
> @@ -904,7 +904,7 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
>  \end{itemize}
>  
>  The per-packet hash calculation can depend on the IP packet type. See
> -\hyperref[intro:IP]{[IP]}, \hyperref[intro:UDP]{[UDP]} and \hyperref[intro:TCP]{[TCP]}.
> +\hyperref[intro:IP]{IP}, \hyperref[intro:UDP]{UDP} and \hyperref[intro:TCP]{TCP}.

I'd keep that as-is (I think it looks nicer with the brackets).

>  
>  \subparagraph{Supported/enabled hash types}
>  \label{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets / Hash calculation for incoming packets / Supported/enabled hash types}
> diff --git a/introduction.tex b/introduction.tex
> index 81f07a4..028ec17 100644
> --- a/introduction.tex
> +++ b/introduction.tex
> @@ -101,26 +101,25 @@ \section{Normative References}\label{sec:Normative References}
>  	\phantomsection\label{intro:SEC1}\textbf{[SEC1]} &
>      Standards for Efficient Cryptography Group(SECG), ``SEC1: Elliptic Cureve Cryptography'', Version 1.0, September 2000.
>  	\newline\url{https://www.secg.org/sec1-v2.pdf}\\
> -
> -	\phantomsection\label{intro:gre_rfc2784}\textbf{[GRE_rfc2784]} &
> +	\phantomsection\label{intro:rfc2784}\textbf{[RFC2784]} &
>      Generic Routing Encapsulation. This protocol is only specified for IPv4 and used as either the payload or delivery protocol.
>  	\newline\url{https://datatracker.ietf.org/doc/rfc2784/}\\
> -	\phantomsection\label{intro:gre_rfc2890}\textbf{[GRE_rfc2890]} &
> -    Key and Sequence Number Extensions to GRE \ref{intro:gre_rfc2784}. This protocol describes extensions by which two fields, Key and
> -    Sequence Number, can be optionally carried in the GRE Header \ref{intro:gre_rfc2784}.
> +	\phantomsection\label{intro:rfc2890}\textbf{[RFC2890]} &
> +    Key and Sequence Number Extensions to GRE \ref{intro:rfc2784}. This protocol describes extensions by which two fields, Key and
> +    Sequence Number, can be optionally carried in the GRE Header \ref{intro:rfc2784}.
>  	\newline\url{https://www.rfc-editor.org/rfc/rfc2890}\\
> -	\phantomsection\label{intro:gre_rfc7676}\textbf{[GRE_rfc7676]} &
> +	\phantomsection\label{intro:rfc7676}\textbf{[RFC7676]} &
>      IPv6 Support for Generic Routing Encapsulation (GRE). This protocol is specified for IPv6 and used as either the payload or
>      delivery protocol. Note that this does not change the GRE header format or any behaviors specified by RFC 2784 or RFC 2890.
>  	\newline\url{https://datatracker.ietf.org/doc/rfc7676/}\\
> -	\phantomsection\label{intro:gre_in_udp_rfc8086}\textbf{[GRE-in-UDP]} &
> +	\phantomsection\label{intro:rfc8086}\textbf{[GRE in UDP]} &

Hyphens are ok, I'd keep it.

>      GRE-in-UDP Encapsulation. This specifies a method of encapsulating network protocol packets within GRE and UDP headers.
>      This protocol is specified for IPv4 and IPv6, and used as either the payload or delivery protocol.
>  	\newline\url{https://www.rfc-editor.org/rfc/rfc8086}\\
>  	\phantomsection\label{intro:vxlan}\textbf{[VXLAN]} &
>      Virtual eXtensible Local Area Network.
>  	\newline\url{https://datatracker.ietf.org/doc/rfc7348/}\\
> -	\phantomsection\label{intro:vxlan-gpe}\textbf{[VXLAN-GPE]} &
> +	\phantomsection\label{intro:vxlan gpe}\textbf{[VXLAN GPE]} &
>      Generic Protocol Extension for VXLAN. This protocol describes extending Virtual eXtensible Local Area Network (VXLAN) via changes to the VXLAN header.
>  	\newline\url{https://www.ietf.org/archive/id/draft-ietf-nvo3-vxlan-gpe-12.txt}\\
>  	\phantomsection\label{intro:geneve}\textbf{[GENEVE]} &


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

[virtio-comment] [PATCH 3/4] virtio-net: Use table to describe inner hash to rfc mapping

[Parav Pandit]

hyperlinks inside the C comments do not work well.
Until we find out a way to represent it, lets present this in table
form.

Signed-off-by: Parav Pandit <parav@nvidia.com>
---
 device-types/net/description.tex | 35 ++++++++++++++++++++++----------
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/device-types/net/description.tex b/device-types/net/description.tex
index 53c811f..68311ab 100644
--- a/device-types/net/description.tex
+++ b/device-types/net/description.tex
@@ -1065,17 +1065,30 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
 Hash calculation for incoming packets / Encapsulation types supported/enabled for inner header hash}
 
 Encapsulation types applicable for inner header hash:
-\begin{lstlisting}
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784    (1 << 0) /* \hyperref[intro:gre_rfc2784]{[GRE_rfc2784]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890    (1 << 1) /* \hyperref[intro:gre_rfc2890]{[GRE_rfc2890]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676    (1 << 2) /* \hyperref[intro:gre_rfc7676]{[GRE_rfc7676]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP     (1 << 3) /* \hyperref[intro:gre_in_udp_rfc8086]{[GRE-in-UDP]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN       (1 << 4) /* \hyperref[intro:vxlan]{[VXLAN]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE   (1 << 5) /* \hyperref[intro:vxlan_gpe]{[VXLAN-GPE]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE      (1 << 6) /* \hyperref[intro:geneve]{[GENEVE]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP        (1 << 7) /* \hyperref[intro:ipip]{[IPIP]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE       (1 << 8) /* \hyperref[intro:nvgre]{[NVGRE]} */
-\end{lstlisting}
+
+\begin{tabular}{|l|l|l|}
+\hline
+Inner header hash type & Value & Reference \\
+\hline \hline
+VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784 & (1 << 0) & \hyperref[intro:rfc2784]{RFC2784} \\
+\hline
+VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890 & (1 << 1) & \hyperref[intro:rfc2784]{RFC2784} \\
+\hline
+VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676  & (1 << 2) & \hyperref[intro:rfc7676]{RFC7676} \\
+\hline
+VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP   & (1 << 3) & \hyperref[intro:rfc8086]{GRE in UDP} \\
+\hline
+VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN     & (1 << 4) & \hyperref[intro:vxlan]{VXLAN} \\
+\hline
+VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE & (1 << 5) & \hyperref[intro:vxlan gpe]{VXLAN GPE} \\
+\hline
+VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE    & (1 << 6) & \hyperref[intro:geneve]{GENEVE} \\
+\hline
+VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP      & (1 << 7) & \hyperref[intro:ipip]{IPIP} \\
+\hline
+VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE     & (1 << 8) & \hyperref[intro:nvgre]{NVGRE} \\
+\hline
+\end{tabular}
 
 \subparagraph{Advice}
 Example uses of the inner header hash:
-- 
2.26.2


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

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

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

[virtio-dev] [PATCH 3/4] virtio-net: Use table to describe inner hash to rfc mapping

[Parav Pandit]

hyperlinks inside the C comments do not work well.
Until we find out a way to represent it, lets present this in table
form.

Signed-off-by: Parav Pandit <parav@nvidia.com>
---
 device-types/net/description.tex | 35 ++++++++++++++++++++++----------
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/device-types/net/description.tex b/device-types/net/description.tex
index 53c811f..68311ab 100644
--- a/device-types/net/description.tex
+++ b/device-types/net/description.tex
@@ -1065,17 +1065,30 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
 Hash calculation for incoming packets / Encapsulation types supported/enabled for inner header hash}
 
 Encapsulation types applicable for inner header hash:
-\begin{lstlisting}
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784    (1 << 0) /* \hyperref[intro:gre_rfc2784]{[GRE_rfc2784]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890    (1 << 1) /* \hyperref[intro:gre_rfc2890]{[GRE_rfc2890]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676    (1 << 2) /* \hyperref[intro:gre_rfc7676]{[GRE_rfc7676]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP     (1 << 3) /* \hyperref[intro:gre_in_udp_rfc8086]{[GRE-in-UDP]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN       (1 << 4) /* \hyperref[intro:vxlan]{[VXLAN]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE   (1 << 5) /* \hyperref[intro:vxlan_gpe]{[VXLAN-GPE]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE      (1 << 6) /* \hyperref[intro:geneve]{[GENEVE]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP        (1 << 7) /* \hyperref[intro:ipip]{[IPIP]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE       (1 << 8) /* \hyperref[intro:nvgre]{[NVGRE]} */
-\end{lstlisting}
+
+\begin{tabular}{|l|l|l|}
+\hline
+Inner header hash type & Value & Reference \\
+\hline \hline
+VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784 & (1 << 0) & \hyperref[intro:rfc2784]{RFC2784} \\
+\hline
+VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890 & (1 << 1) & \hyperref[intro:rfc2784]{RFC2784} \\
+\hline
+VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676  & (1 << 2) & \hyperref[intro:rfc7676]{RFC7676} \\
+\hline
+VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP   & (1 << 3) & \hyperref[intro:rfc8086]{GRE in UDP} \\
+\hline
+VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN     & (1 << 4) & \hyperref[intro:vxlan]{VXLAN} \\
+\hline
+VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE & (1 << 5) & \hyperref[intro:vxlan gpe]{VXLAN GPE} \\
+\hline
+VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE    & (1 << 6) & \hyperref[intro:geneve]{GENEVE} \\
+\hline
+VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP      & (1 << 7) & \hyperref[intro:ipip]{IPIP} \\
+\hline
+VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE     & (1 << 8) & \hyperref[intro:nvgre]{NVGRE} \\
+\hline
+\end{tabular}
 
 \subparagraph{Advice}
 Example uses of the inner header hash:
-- 
2.26.2


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

[virtio-comment] Re: [PATCH 3/4] virtio-net: Use table to describe inner hash to rfc mapping

[Michael S. Tsirkin]

On Thu, Jul 13, 2023 at 01:24:04AM +0300, Parav Pandit wrote:
> hyperlinks inside the C comments do not work well.
> Until we find out a way to represent it, lets present this in table
> form.
> 
> Signed-off-by: Parav Pandit <parav@nvidia.com>
> ---
>  device-types/net/description.tex | 35 ++++++++++++++++++++++----------
>  1 file changed, 24 insertions(+), 11 deletions(-)
> 
> diff --git a/device-types/net/description.tex b/device-types/net/description.tex
> index 53c811f..68311ab 100644
> --- a/device-types/net/description.tex
> +++ b/device-types/net/description.tex
> @@ -1065,17 +1065,30 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
>  Hash calculation for incoming packets / Encapsulation types supported/enabled for inner header hash}
>  
>  Encapsulation types applicable for inner header hash:
> -\begin{lstlisting}
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784    (1 << 0) /* \hyperref[intro:gre_rfc2784]{[GRE_rfc2784]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890    (1 << 1) /* \hyperref[intro:gre_rfc2890]{[GRE_rfc2890]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676    (1 << 2) /* \hyperref[intro:gre_rfc7676]{[GRE_rfc7676]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP     (1 << 3) /* \hyperref[intro:gre_in_udp_rfc8086]{[GRE-in-UDP]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN       (1 << 4) /* \hyperref[intro:vxlan]{[VXLAN]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE   (1 << 5) /* \hyperref[intro:vxlan_gpe]{[VXLAN-GPE]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE      (1 << 6) /* \hyperref[intro:geneve]{[GENEVE]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP        (1 << 7) /* \hyperref[intro:ipip]{[IPIP]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE       (1 << 8) /* \hyperref[intro:nvgre]{[NVGRE]} */
> -\end{lstlisting}

Hmm. escapechar did not work then?

> +
> +\begin{tabular}{|l|l|l|}
> +\hline
> +Inner header hash type & Value & Reference \\
> +\hline \hline
> +VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784 & (1 << 0) & \hyperref[intro:rfc2784]{RFC2784} \\
> +\hline
> +VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890 & (1 << 1) & \hyperref[intro:rfc2784]{RFC2784} \\
> +\hline
> +VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676  & (1 << 2) & \hyperref[intro:rfc7676]{RFC7676} \\
> +\hline
> +VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP   & (1 << 3) & \hyperref[intro:rfc8086]{GRE in UDP} \\
> +\hline
> +VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN     & (1 << 4) & \hyperref[intro:vxlan]{VXLAN} \\
> +\hline
> +VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE & (1 << 5) & \hyperref[intro:vxlan gpe]{VXLAN GPE} \\
> +\hline
> +VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE    & (1 << 6) & \hyperref[intro:geneve]{GENEVE} \\
> +\hline
> +VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP      & (1 << 7) & \hyperref[intro:ipip]{IPIP} \\
> +\hline
> +VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE     & (1 << 8) & \hyperref[intro:nvgre]{NVGRE} \\
> +\hline
> +\end{tabular}
>  
>  \subparagraph{Advice}
>  Example uses of the inner header hash:
> -- 
> 2.26.2


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

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

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

[virtio-dev] Re: [PATCH 3/4] virtio-net: Use table to describe inner hash to rfc mapping

[Michael S. Tsirkin]

On Thu, Jul 13, 2023 at 01:24:04AM +0300, Parav Pandit wrote:
> hyperlinks inside the C comments do not work well.
> Until we find out a way to represent it, lets present this in table
> form.
> 
> Signed-off-by: Parav Pandit <parav@nvidia.com>
> ---
>  device-types/net/description.tex | 35 ++++++++++++++++++++++----------
>  1 file changed, 24 insertions(+), 11 deletions(-)
> 
> diff --git a/device-types/net/description.tex b/device-types/net/description.tex
> index 53c811f..68311ab 100644
> --- a/device-types/net/description.tex
> +++ b/device-types/net/description.tex
> @@ -1065,17 +1065,30 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
>  Hash calculation for incoming packets / Encapsulation types supported/enabled for inner header hash}
>  
>  Encapsulation types applicable for inner header hash:
> -\begin{lstlisting}
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784    (1 << 0) /* \hyperref[intro:gre_rfc2784]{[GRE_rfc2784]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890    (1 << 1) /* \hyperref[intro:gre_rfc2890]{[GRE_rfc2890]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676    (1 << 2) /* \hyperref[intro:gre_rfc7676]{[GRE_rfc7676]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP     (1 << 3) /* \hyperref[intro:gre_in_udp_rfc8086]{[GRE-in-UDP]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN       (1 << 4) /* \hyperref[intro:vxlan]{[VXLAN]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE   (1 << 5) /* \hyperref[intro:vxlan_gpe]{[VXLAN-GPE]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE      (1 << 6) /* \hyperref[intro:geneve]{[GENEVE]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP        (1 << 7) /* \hyperref[intro:ipip]{[IPIP]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE       (1 << 8) /* \hyperref[intro:nvgre]{[NVGRE]} */
> -\end{lstlisting}

Hmm. escapechar did not work then?

> +
> +\begin{tabular}{|l|l|l|}
> +\hline
> +Inner header hash type & Value & Reference \\
> +\hline \hline
> +VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784 & (1 << 0) & \hyperref[intro:rfc2784]{RFC2784} \\
> +\hline
> +VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890 & (1 << 1) & \hyperref[intro:rfc2784]{RFC2784} \\
> +\hline
> +VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676  & (1 << 2) & \hyperref[intro:rfc7676]{RFC7676} \\
> +\hline
> +VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP   & (1 << 3) & \hyperref[intro:rfc8086]{GRE in UDP} \\
> +\hline
> +VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN     & (1 << 4) & \hyperref[intro:vxlan]{VXLAN} \\
> +\hline
> +VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE & (1 << 5) & \hyperref[intro:vxlan gpe]{VXLAN GPE} \\
> +\hline
> +VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE    & (1 << 6) & \hyperref[intro:geneve]{GENEVE} \\
> +\hline
> +VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP      & (1 << 7) & \hyperref[intro:ipip]{IPIP} \\
> +\hline
> +VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE     & (1 << 8) & \hyperref[intro:nvgre]{NVGRE} \\
> +\hline
> +\end{tabular}
>  
>  \subparagraph{Advice}
>  Example uses of the inner header hash:
> -- 
> 2.26.2


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

[virtio-comment] RE: [PATCH 3/4] virtio-net: Use table to describe inner hash to rfc mapping

[Parav Pandit]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Wednesday, July 12, 2023 6:41 PM
> Hmm. escapechar did not work then?

 Forgot to mention, I tried it, it didn't work.

> 
> > +
> > +\begin{tabular}{|l|l|l|}
> > +\hline
> > +Inner header hash type & Value & Reference \\ \hline \hline
> > +VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784 & (1 << 0) &
> > +\hyperref[intro:rfc2784]{RFC2784} \\ \hline
> > +VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890 & (1 << 1) &
> > +\hyperref[intro:rfc2784]{RFC2784} \\ \hline
> > +VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676  & (1 << 2) &
> > +\hyperref[intro:rfc7676]{RFC7676} \\ \hline
> > +VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP   & (1 << 3) &
> \hyperref[intro:rfc8086]{GRE in UDP} \\
> > +\hline
> > +VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN     & (1 << 4) &
> \hyperref[intro:vxlan]{VXLAN} \\
> > +\hline
> > +VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE & (1 << 5) &
> > +\hyperref[intro:vxlan gpe]{VXLAN GPE} \\ \hline
> > +VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE    & (1 << 6) &
> \hyperref[intro:geneve]{GENEVE} \\
> > +\hline
> > +VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP      & (1 << 7) &
> \hyperref[intro:ipip]{IPIP} \\
> > +\hline
> > +VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE     & (1 << 8) &
> \hyperref[intro:nvgre]{NVGRE} \\
> > +\hline
> > +\end{tabular}
> >
> >  \subparagraph{Advice}
> >  Example uses of the inner header hash:
> > --
> > 2.26.2


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

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

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

[virtio-dev] RE: [PATCH 3/4] virtio-net: Use table to describe inner hash to rfc mapping

[Parav Pandit]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Wednesday, July 12, 2023 6:41 PM
> Hmm. escapechar did not work then?

 Forgot to mention, I tried it, it didn't work.

> 
> > +
> > +\begin{tabular}{|l|l|l|}
> > +\hline
> > +Inner header hash type & Value & Reference \\ \hline \hline
> > +VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784 & (1 << 0) &
> > +\hyperref[intro:rfc2784]{RFC2784} \\ \hline
> > +VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890 & (1 << 1) &
> > +\hyperref[intro:rfc2784]{RFC2784} \\ \hline
> > +VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676  & (1 << 2) &
> > +\hyperref[intro:rfc7676]{RFC7676} \\ \hline
> > +VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP   & (1 << 3) &
> \hyperref[intro:rfc8086]{GRE in UDP} \\
> > +\hline
> > +VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN     & (1 << 4) &
> \hyperref[intro:vxlan]{VXLAN} \\
> > +\hline
> > +VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE & (1 << 5) &
> > +\hyperref[intro:vxlan gpe]{VXLAN GPE} \\ \hline
> > +VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE    & (1 << 6) &
> \hyperref[intro:geneve]{GENEVE} \\
> > +\hline
> > +VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP      & (1 << 7) &
> \hyperref[intro:ipip]{IPIP} \\
> > +\hline
> > +VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE     & (1 << 8) &
> \hyperref[intro:nvgre]{NVGRE} \\
> > +\hline
> > +\end{tabular}
> >
> >  \subparagraph{Advice}
> >  Example uses of the inner header hash:
> > --
> > 2.26.2


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

[virtio-comment] RE: [PATCH 3/4] virtio-net: Use table to describe inner hash to rfc mapping

[Cornelia Huck]

On Wed, Jul 12 2023, Parav Pandit <parav@nvidia.com> wrote:

>> From: Michael S. Tsirkin <mst@redhat.com>
>> Sent: Wednesday, July 12, 2023 6:41 PM
>> Hmm. escapechar did not work then?
>
>  Forgot to mention, I tried it, it didn't work.

It seemed to work for me (at least in the pdf) -- I'd prefer that one as
a minimal change.


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

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

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

[virtio-dev] RE: [PATCH 3/4] virtio-net: Use table to describe inner hash to rfc mapping

[Cornelia Huck]

On Wed, Jul 12 2023, Parav Pandit <parav@nvidia.com> wrote:

>> From: Michael S. Tsirkin <mst@redhat.com>
>> Sent: Wednesday, July 12, 2023 6:41 PM
>> Hmm. escapechar did not work then?
>
>  Forgot to mention, I tried it, it didn't work.

It seemed to work for me (at least in the pdf) -- I'd prefer that one as
a minimal change.


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

[virtio-comment] Re: [PATCH 3/4] virtio-net: Use table to describe inner hash to rfc mapping

[Michael S. Tsirkin]

On Thu, Jul 13, 2023 at 10:09:47AM +0200, Cornelia Huck wrote:
> On Wed, Jul 12 2023, Parav Pandit <parav@nvidia.com> wrote:
> 
> >> From: Michael S. Tsirkin <mst@redhat.com>
> >> Sent: Wednesday, July 12, 2023 6:41 PM
> >> Hmm. escapechar did not work then?
> >
> >  Forgot to mention, I tried it, it didn't work.
> 
> It seemed to work for me (at least in the pdf) -- I'd prefer that one as
> a minimal change.

Yes it really should.  Could you post yours please?


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

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

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

[virtio-dev] Re: [PATCH 3/4] virtio-net: Use table to describe inner hash to rfc mapping

[Michael S. Tsirkin]

On Thu, Jul 13, 2023 at 10:09:47AM +0200, Cornelia Huck wrote:
> On Wed, Jul 12 2023, Parav Pandit <parav@nvidia.com> wrote:
> 
> >> From: Michael S. Tsirkin <mst@redhat.com>
> >> Sent: Wednesday, July 12, 2023 6:41 PM
> >> Hmm. escapechar did not work then?
> >
> >  Forgot to mention, I tried it, it didn't work.
> 
> It seemed to work for me (at least in the pdf) -- I'd prefer that one as
> a minimal change.

Yes it really should.  Could you post yours please?


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

[virtio-comment] [PATCH 4/4] virtio-net: Use note instead of advice

[Parav Pandit]

Section like "Advice" is not the current practice. Lets capture such
advice as notes.

Signed-off-by: Parav Pandit <parav@nvidia.com>
---
 device-types/net/description.tex | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/device-types/net/description.tex b/device-types/net/description.tex
index 68311ab..a8dff97 100644
--- a/device-types/net/description.tex
+++ b/device-types/net/description.tex
@@ -1090,7 +1090,7 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
 \hline
 \end{tabular}
 
-\subparagraph{Advice}
+\begin{note}
 Example uses of the inner header hash:
 \begin{itemize}
 \item Legacy tunneling protocols, lacking the outer header entropy, can use RSS with the inner header hash to
@@ -1105,6 +1105,8 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
 Besides disabling the inner header hash, mitigations would depend on how the hash is used. When the hash
 use is limited to the RSS queue selection, the inner header hash may have quality of service (QoS) limitations.
 
+\end{note}
+
 \devicenormative{\subparagraph}{Inner Header Hash}{Device Types / Network Device / Device Operation / Control Virtqueue / Inner Header Hash}
 
 If the (outer) header of the received packet does not match any encapsulation types enabled
-- 
2.26.2


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

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

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

[virtio-dev] [PATCH 4/4] virtio-net: Use note instead of advice

[Parav Pandit]

Section like "Advice" is not the current practice. Lets capture such
advice as notes.

Signed-off-by: Parav Pandit <parav@nvidia.com>
---
 device-types/net/description.tex | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/device-types/net/description.tex b/device-types/net/description.tex
index 68311ab..a8dff97 100644
--- a/device-types/net/description.tex
+++ b/device-types/net/description.tex
@@ -1090,7 +1090,7 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
 \hline
 \end{tabular}
 
-\subparagraph{Advice}
+\begin{note}
 Example uses of the inner header hash:
 \begin{itemize}
 \item Legacy tunneling protocols, lacking the outer header entropy, can use RSS with the inner header hash to
@@ -1105,6 +1105,8 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
 Besides disabling the inner header hash, mitigations would depend on how the hash is used. When the hash
 use is limited to the RSS queue selection, the inner header hash may have quality of service (QoS) limitations.
 
+\end{note}
+
 \devicenormative{\subparagraph}{Inner Header Hash}{Device Types / Network Device / Device Operation / Control Virtqueue / Inner Header Hash}
 
 If the (outer) header of the received packet does not match any encapsulation types enabled
-- 
2.26.2


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

[virtio-comment] Re: [PATCH 0/4] Short document fixes to inner hash feature

[Cornelia Huck]

On Thu, Jul 13 2023, Parav Pandit <parav@nvidia.com> wrote:

> This short patches fixes the editing errors that stops the pdf and html
> generation.
>
> These 3 fixes are for the patch [1] for the github issue [2].
>
> [1] https://lists.oasis-open.org/archives/virtio-comment/202307/msg00024.html
> [2] https://github.com/oasis-tcs/virtio-spec/issues/173
>
> Patch summary:
> patch-1 place C code under listing
> patch-2 avoid hyphen and extra braces
> patch-3 use table as hyperlink do not work well in C code listing
> patch-4 refer 'advice' as 'note'
>
> Patch 1 to 3 appears to be must in the testing.
> Patch 4 is not a fix and can be done later if it requires discussion.
>
> Parav Pandit (4):
>   virtio-net: Place C code under listing
>   virtio-net: Avoid hyphen and extra braces
>   virtio-net: Use table to describe inner hash to rfc mapping
>   virtio-net: Use note instead of advice
>
>  device-types/net/description.tex | 45 ++++++++++++++++++++++----------
>  introduction.tex                 | 15 +++++------
>  2 files changed, 38 insertions(+), 22 deletions(-)
>

FTR, this is the diff I have locally (I had missed one underscore in the
references yesterday...); maybe we can make the intra-reference links in
introdcution.tex a bit nicer, but otherwise, this should be the minimal
change to make this build:

diff --git a/device-types/net/description.tex b/device-types/net/description.tex
index 206020de567d..76585b0dd6d3 100644
--- a/device-types/net/description.tex
+++ b/device-types/net/description.tex
@@ -1024,12 +1024,14 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
 If VIRTIO_NET_F_HASH_TUNNEL has been negotiated, the driver can send the command
 VIRTIO_NET_CTRL_HASH_TUNNEL_SET to configure the calculation of the inner header hash.
 
+\begin{lstlisting}
 struct virtnet_hash_tunnel {
     le32 enabled_tunnel_types;
 };
 
 #define VIRTIO_NET_CTRL_HASH_TUNNEL 7
  #define VIRTIO_NET_CTRL_HASH_TUNNEL_SET 0
+\end{lstlisting}
 
 Field \field{enabled_tunnel_types} contains the bitmask of encapsulation types enabled for inner header hash.
 See \ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets /
@@ -1063,16 +1065,16 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
 Hash calculation for incoming packets / Encapsulation types supported/enabled for inner header hash}
 
 Encapsulation types applicable for inner header hash:
-\begin{lstlisting}
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784    (1 << 0) /* \hyperref[intro:gre_rfc2784]{[GRE_rfc2784]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890    (1 << 1) /* \hyperref[intro:gre_rfc2890]{[GRE_rfc2890]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676    (1 << 2) /* \hyperref[intro:gre_rfc7676]{[GRE_rfc7676]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP     (1 << 3) /* \hyperref[intro:gre_in_udp_rfc8086]{[GRE-in-UDP]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN       (1 << 4) /* \hyperref[intro:vxlan]{[VXLAN]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE   (1 << 5) /* \hyperref[intro:vxlan_gpe]{[VXLAN-GPE]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE      (1 << 6) /* \hyperref[intro:geneve]{[GENEVE]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP        (1 << 7) /* \hyperref[intro:ipip]{[IPIP]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE       (1 << 8) /* \hyperref[intro:nvgre]{[NVGRE]} */
+\begin{lstlisting}[escapechar=|]
+#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784    (1 << 0) /* |\hyperref[intro:rfc2784]{[RFC2784]}| */
+#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890    (1 << 1) /* |\hyperref[intro:rfc2890]{[RFC2890]}| */
+#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676    (1 << 2) /* |\hyperref[intro:rfc7676]{[RFC7676]}| */
+#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP     (1 << 3) /* |\hyperref[intro:rfc8086]{[GRE-in-UDP]}| */
+#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN       (1 << 4) /* |\hyperref[intro:vxlan]{[VXLAN]}| */
+#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE   (1 << 5) /* |\hyperref[intro:vxlan-gpe]{[VXLAN-GPE]}| */
+#define VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE      (1 << 6) /* |\hyperref[intro:geneve]{[GENEVE]}| */
+#define VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP        (1 << 7) /* |\hyperref[intro:ipip]{[IPIP]}| */
+#define VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE       (1 << 8) /* |\hyperref[intro:nvgre]{[NVGRE]}| */
 \end{lstlisting}
 
 \subparagraph{Advice}
diff --git a/introduction.tex b/introduction.tex
index 81f07a4fee19..6f10a94b6fde 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -102,18 +102,18 @@ \section{Normative References}\label{sec:Normative References}
     Standards for Efficient Cryptography Group(SECG), ``SEC1: Elliptic Cureve Cryptography'', Version 1.0, September 2000.
 	\newline\url{https://www.secg.org/sec1-v2.pdf}\\
 
-	\phantomsection\label{intro:gre_rfc2784}\textbf{[GRE_rfc2784]} &
+	\phantomsection\label{intro:rfc2784}\textbf{[RFC2784]} &
     Generic Routing Encapsulation. This protocol is only specified for IPv4 and used as either the payload or delivery protocol.
 	\newline\url{https://datatracker.ietf.org/doc/rfc2784/}\\
-	\phantomsection\label{intro:gre_rfc2890}\textbf{[GRE_rfc2890]} &
-    Key and Sequence Number Extensions to GRE \ref{intro:gre_rfc2784}. This protocol describes extensions by which two fields, Key and
-    Sequence Number, can be optionally carried in the GRE Header \ref{intro:gre_rfc2784}.
+	\phantomsection\label{intro:rfc2890}\textbf{[RFC2890]} &
+    Key and Sequence Number Extensions to GRE \ref{intro:rfc2784}. This protocol describes extensions by which two fields, Key and
+    Sequence Number, can be optionally carried in the GRE Header \ref{intro:rfc2784}.
 	\newline\url{https://www.rfc-editor.org/rfc/rfc2890}\\
-	\phantomsection\label{intro:gre_rfc7676}\textbf{[GRE_rfc7676]} &
+	\phantomsection\label{intro:rfc7676}\textbf{[RFC7676]} &
     IPv6 Support for Generic Routing Encapsulation (GRE). This protocol is specified for IPv6 and used as either the payload or
     delivery protocol. Note that this does not change the GRE header format or any behaviors specified by RFC 2784 or RFC 2890.
 	\newline\url{https://datatracker.ietf.org/doc/rfc7676/}\\
-	\phantomsection\label{intro:gre_in_udp_rfc8086}\textbf{[GRE-in-UDP]} &
+	\phantomsection\label{intro:rfc8086}\textbf{[GRE-in-UDP]} &
     GRE-in-UDP Encapsulation. This specifies a method of encapsulating network protocol packets within GRE and UDP headers.
     This protocol is specified for IPv4 and IPv6, and used as either the payload or delivery protocol.
 	\newline\url{https://www.rfc-editor.org/rfc/rfc8086}\\


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

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

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

[virtio-dev] Re: [PATCH 0/4] Short document fixes to inner hash feature

[Cornelia Huck]

On Thu, Jul 13 2023, Parav Pandit <parav@nvidia.com> wrote:

> This short patches fixes the editing errors that stops the pdf and html
> generation.
>
> These 3 fixes are for the patch [1] for the github issue [2].
>
> [1] https://lists.oasis-open.org/archives/virtio-comment/202307/msg00024.html
> [2] https://github.com/oasis-tcs/virtio-spec/issues/173
>
> Patch summary:
> patch-1 place C code under listing
> patch-2 avoid hyphen and extra braces
> patch-3 use table as hyperlink do not work well in C code listing
> patch-4 refer 'advice' as 'note'
>
> Patch 1 to 3 appears to be must in the testing.
> Patch 4 is not a fix and can be done later if it requires discussion.
>
> Parav Pandit (4):
>   virtio-net: Place C code under listing
>   virtio-net: Avoid hyphen and extra braces
>   virtio-net: Use table to describe inner hash to rfc mapping
>   virtio-net: Use note instead of advice
>
>  device-types/net/description.tex | 45 ++++++++++++++++++++++----------
>  introduction.tex                 | 15 +++++------
>  2 files changed, 38 insertions(+), 22 deletions(-)
>

FTR, this is the diff I have locally (I had missed one underscore in the
references yesterday...); maybe we can make the intra-reference links in
introdcution.tex a bit nicer, but otherwise, this should be the minimal
change to make this build:

diff --git a/device-types/net/description.tex b/device-types/net/description.tex
index 206020de567d..76585b0dd6d3 100644
--- a/device-types/net/description.tex
+++ b/device-types/net/description.tex
@@ -1024,12 +1024,14 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
 If VIRTIO_NET_F_HASH_TUNNEL has been negotiated, the driver can send the command
 VIRTIO_NET_CTRL_HASH_TUNNEL_SET to configure the calculation of the inner header hash.
 
+\begin{lstlisting}
 struct virtnet_hash_tunnel {
     le32 enabled_tunnel_types;
 };
 
 #define VIRTIO_NET_CTRL_HASH_TUNNEL 7
  #define VIRTIO_NET_CTRL_HASH_TUNNEL_SET 0
+\end{lstlisting}
 
 Field \field{enabled_tunnel_types} contains the bitmask of encapsulation types enabled for inner header hash.
 See \ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets /
@@ -1063,16 +1065,16 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
 Hash calculation for incoming packets / Encapsulation types supported/enabled for inner header hash}
 
 Encapsulation types applicable for inner header hash:
-\begin{lstlisting}
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784    (1 << 0) /* \hyperref[intro:gre_rfc2784]{[GRE_rfc2784]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890    (1 << 1) /* \hyperref[intro:gre_rfc2890]{[GRE_rfc2890]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676    (1 << 2) /* \hyperref[intro:gre_rfc7676]{[GRE_rfc7676]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP     (1 << 3) /* \hyperref[intro:gre_in_udp_rfc8086]{[GRE-in-UDP]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN       (1 << 4) /* \hyperref[intro:vxlan]{[VXLAN]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE   (1 << 5) /* \hyperref[intro:vxlan_gpe]{[VXLAN-GPE]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE      (1 << 6) /* \hyperref[intro:geneve]{[GENEVE]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP        (1 << 7) /* \hyperref[intro:ipip]{[IPIP]} */
-#define VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE       (1 << 8) /* \hyperref[intro:nvgre]{[NVGRE]} */
+\begin{lstlisting}[escapechar=|]
+#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784    (1 << 0) /* |\hyperref[intro:rfc2784]{[RFC2784]}| */
+#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890    (1 << 1) /* |\hyperref[intro:rfc2890]{[RFC2890]}| */
+#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676    (1 << 2) /* |\hyperref[intro:rfc7676]{[RFC7676]}| */
+#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP     (1 << 3) /* |\hyperref[intro:rfc8086]{[GRE-in-UDP]}| */
+#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN       (1 << 4) /* |\hyperref[intro:vxlan]{[VXLAN]}| */
+#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE   (1 << 5) /* |\hyperref[intro:vxlan-gpe]{[VXLAN-GPE]}| */
+#define VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE      (1 << 6) /* |\hyperref[intro:geneve]{[GENEVE]}| */
+#define VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP        (1 << 7) /* |\hyperref[intro:ipip]{[IPIP]}| */
+#define VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE       (1 << 8) /* |\hyperref[intro:nvgre]{[NVGRE]}| */
 \end{lstlisting}
 
 \subparagraph{Advice}
diff --git a/introduction.tex b/introduction.tex
index 81f07a4fee19..6f10a94b6fde 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -102,18 +102,18 @@ \section{Normative References}\label{sec:Normative References}
     Standards for Efficient Cryptography Group(SECG), ``SEC1: Elliptic Cureve Cryptography'', Version 1.0, September 2000.
 	\newline\url{https://www.secg.org/sec1-v2.pdf}\\
 
-	\phantomsection\label{intro:gre_rfc2784}\textbf{[GRE_rfc2784]} &
+	\phantomsection\label{intro:rfc2784}\textbf{[RFC2784]} &
     Generic Routing Encapsulation. This protocol is only specified for IPv4 and used as either the payload or delivery protocol.
 	\newline\url{https://datatracker.ietf.org/doc/rfc2784/}\\
-	\phantomsection\label{intro:gre_rfc2890}\textbf{[GRE_rfc2890]} &
-    Key and Sequence Number Extensions to GRE \ref{intro:gre_rfc2784}. This protocol describes extensions by which two fields, Key and
-    Sequence Number, can be optionally carried in the GRE Header \ref{intro:gre_rfc2784}.
+	\phantomsection\label{intro:rfc2890}\textbf{[RFC2890]} &
+    Key and Sequence Number Extensions to GRE \ref{intro:rfc2784}. This protocol describes extensions by which two fields, Key and
+    Sequence Number, can be optionally carried in the GRE Header \ref{intro:rfc2784}.
 	\newline\url{https://www.rfc-editor.org/rfc/rfc2890}\\
-	\phantomsection\label{intro:gre_rfc7676}\textbf{[GRE_rfc7676]} &
+	\phantomsection\label{intro:rfc7676}\textbf{[RFC7676]} &
     IPv6 Support for Generic Routing Encapsulation (GRE). This protocol is specified for IPv6 and used as either the payload or
     delivery protocol. Note that this does not change the GRE header format or any behaviors specified by RFC 2784 or RFC 2890.
 	\newline\url{https://datatracker.ietf.org/doc/rfc7676/}\\
-	\phantomsection\label{intro:gre_in_udp_rfc8086}\textbf{[GRE-in-UDP]} &
+	\phantomsection\label{intro:rfc8086}\textbf{[GRE-in-UDP]} &
     GRE-in-UDP Encapsulation. This specifies a method of encapsulating network protocol packets within GRE and UDP headers.
     This protocol is specified for IPv4 and IPv6, and used as either the payload or delivery protocol.
 	\newline\url{https://www.rfc-editor.org/rfc/rfc8086}\\


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

Re: [virtio-comment] Re: [PATCH 0/4] Short document fixes to inner hash feature

[Cornelia Huck]

On Thu, Jul 13 2023, Cornelia Huck <cohuck@redhat.com> wrote:

> On Thu, Jul 13 2023, Parav Pandit <parav@nvidia.com> wrote:
>
>> This short patches fixes the editing errors that stops the pdf and html
>> generation.
>>
>> These 3 fixes are for the patch [1] for the github issue [2].
>>
>> [1] https://lists.oasis-open.org/archives/virtio-comment/202307/msg00024.html
>> [2] https://github.com/oasis-tcs/virtio-spec/issues/173
>>
>> Patch summary:
>> patch-1 place C code under listing
>> patch-2 avoid hyphen and extra braces
>> patch-3 use table as hyperlink do not work well in C code listing
>> patch-4 refer 'advice' as 'note'
>>
>> Patch 1 to 3 appears to be must in the testing.
>> Patch 4 is not a fix and can be done later if it requires discussion.
>>
>> Parav Pandit (4):
>>   virtio-net: Place C code under listing
>>   virtio-net: Avoid hyphen and extra braces
>>   virtio-net: Use table to describe inner hash to rfc mapping
>>   virtio-net: Use note instead of advice
>>
>>  device-types/net/description.tex | 45 ++++++++++++++++++++++----------
>>  introduction.tex                 | 15 +++++------
>>  2 files changed, 38 insertions(+), 22 deletions(-)
>>
>
> FTR, this is the diff I have locally (I had missed one underscore in the
> references yesterday...); maybe we can make the intra-reference links in
> introdcution.tex a bit nicer, but otherwise, this should be the minimal
> change to make this build:

For the "make it look nicer" part, I think this one would get the job
done; opinions?

diff --git a/introduction.tex b/introduction.tex
index 6f10a94b6fde..1e39a4b2c529 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -106,8 +106,8 @@ \section{Normative References}\label{sec:Normative References}
     Generic Routing Encapsulation. This protocol is only specified for IPv4 and used as either the payload or delivery protocol.
 	\newline\url{https://datatracker.ietf.org/doc/rfc2784/}\\
 	\phantomsection\label{intro:rfc2890}\textbf{[RFC2890]} &
-    Key and Sequence Number Extensions to GRE \ref{intro:rfc2784}. This protocol describes extensions by which two fields, Key and
-    Sequence Number, can be optionally carried in the GRE Header \ref{intro:rfc2784}.
+    Key and Sequence Number Extensions to \hyperref[intro:rfc2784]{GRE}. This protocol describes extensions by which two fields, Key and
+    Sequence Number, can be optionally carried in the \hyperref[intro:rfc2784]{GRE} Header.
 	\newline\url{https://www.rfc-editor.org/rfc/rfc2890}\\
 	\phantomsection\label{intro:rfc7676}\textbf{[RFC7676]} &
     IPv6 Support for Generic Routing Encapsulation (GRE). This protocol is specified for IPv6 and used as either the payload or


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

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

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

[virtio-dev] Re: [virtio-comment] Re: [PATCH 0/4] Short document fixes to inner hash feature

[Cornelia Huck]

On Thu, Jul 13 2023, Cornelia Huck <cohuck@redhat.com> wrote:

> On Thu, Jul 13 2023, Parav Pandit <parav@nvidia.com> wrote:
>
>> This short patches fixes the editing errors that stops the pdf and html
>> generation.
>>
>> These 3 fixes are for the patch [1] for the github issue [2].
>>
>> [1] https://lists.oasis-open.org/archives/virtio-comment/202307/msg00024.html
>> [2] https://github.com/oasis-tcs/virtio-spec/issues/173
>>
>> Patch summary:
>> patch-1 place C code under listing
>> patch-2 avoid hyphen and extra braces
>> patch-3 use table as hyperlink do not work well in C code listing
>> patch-4 refer 'advice' as 'note'
>>
>> Patch 1 to 3 appears to be must in the testing.
>> Patch 4 is not a fix and can be done later if it requires discussion.
>>
>> Parav Pandit (4):
>>   virtio-net: Place C code under listing
>>   virtio-net: Avoid hyphen and extra braces
>>   virtio-net: Use table to describe inner hash to rfc mapping
>>   virtio-net: Use note instead of advice
>>
>>  device-types/net/description.tex | 45 ++++++++++++++++++++++----------
>>  introduction.tex                 | 15 +++++------
>>  2 files changed, 38 insertions(+), 22 deletions(-)
>>
>
> FTR, this is the diff I have locally (I had missed one underscore in the
> references yesterday...); maybe we can make the intra-reference links in
> introdcution.tex a bit nicer, but otherwise, this should be the minimal
> change to make this build:

For the "make it look nicer" part, I think this one would get the job
done; opinions?

diff --git a/introduction.tex b/introduction.tex
index 6f10a94b6fde..1e39a4b2c529 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -106,8 +106,8 @@ \section{Normative References}\label{sec:Normative References}
     Generic Routing Encapsulation. This protocol is only specified for IPv4 and used as either the payload or delivery protocol.
 	\newline\url{https://datatracker.ietf.org/doc/rfc2784/}\\
 	\phantomsection\label{intro:rfc2890}\textbf{[RFC2890]} &
-    Key and Sequence Number Extensions to GRE \ref{intro:rfc2784}. This protocol describes extensions by which two fields, Key and
-    Sequence Number, can be optionally carried in the GRE Header \ref{intro:rfc2784}.
+    Key and Sequence Number Extensions to \hyperref[intro:rfc2784]{GRE}. This protocol describes extensions by which two fields, Key and
+    Sequence Number, can be optionally carried in the \hyperref[intro:rfc2784]{GRE} Header.
 	\newline\url{https://www.rfc-editor.org/rfc/rfc2890}\\
 	\phantomsection\label{intro:rfc7676}\textbf{[RFC7676]} &
     IPv6 Support for Generic Routing Encapsulation (GRE). This protocol is specified for IPv6 and used as either the payload or


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

Re: [virtio-comment] Re: [PATCH 0/4] Short document fixes to inner hash feature

[Michael S. Tsirkin]

On Thu, Jul 13, 2023 at 11:32:32AM +0200, Cornelia Huck wrote:
> On Thu, Jul 13 2023, Cornelia Huck <cohuck@redhat.com> wrote:
> 
> > On Thu, Jul 13 2023, Parav Pandit <parav@nvidia.com> wrote:
> >
> >> This short patches fixes the editing errors that stops the pdf and html
> >> generation.
> >>
> >> These 3 fixes are for the patch [1] for the github issue [2].
> >>
> >> [1] https://lists.oasis-open.org/archives/virtio-comment/202307/msg00024.html
> >> [2] https://github.com/oasis-tcs/virtio-spec/issues/173
> >>
> >> Patch summary:
> >> patch-1 place C code under listing
> >> patch-2 avoid hyphen and extra braces
> >> patch-3 use table as hyperlink do not work well in C code listing
> >> patch-4 refer 'advice' as 'note'
> >>
> >> Patch 1 to 3 appears to be must in the testing.
> >> Patch 4 is not a fix and can be done later if it requires discussion.
> >>
> >> Parav Pandit (4):
> >>   virtio-net: Place C code under listing
> >>   virtio-net: Avoid hyphen and extra braces
> >>   virtio-net: Use table to describe inner hash to rfc mapping
> >>   virtio-net: Use note instead of advice
> >>
> >>  device-types/net/description.tex | 45 ++++++++++++++++++++++----------
> >>  introduction.tex                 | 15 +++++------
> >>  2 files changed, 38 insertions(+), 22 deletions(-)
> >>
> >
> > FTR, this is the diff I have locally (I had missed one underscore in the
> > references yesterday...); maybe we can make the intra-reference links in
> > introdcution.tex a bit nicer, but otherwise, this should be the minimal
> > change to make this build:
> 
> For the "make it look nicer" part, I think this one would get the job
> done; opinions?
> 
> diff --git a/introduction.tex b/introduction.tex
> index 6f10a94b6fde..1e39a4b2c529 100644
> --- a/introduction.tex
> +++ b/introduction.tex
> @@ -106,8 +106,8 @@ \section{Normative References}\label{sec:Normative References}
>      Generic Routing Encapsulation. This protocol is only specified for IPv4 and used as either the payload or delivery protocol.
>  	\newline\url{https://datatracker.ietf.org/doc/rfc2784/}\\
>  	\phantomsection\label{intro:rfc2890}\textbf{[RFC2890]} &
> -    Key and Sequence Number Extensions to GRE \ref{intro:rfc2784}. This protocol describes extensions by which two fields, Key and
> -    Sequence Number, can be optionally carried in the GRE Header \ref{intro:rfc2784}.
> +    Key and Sequence Number Extensions to \hyperref[intro:rfc2784]{GRE}. This protocol describes extensions by which two fields, Key and
> +    Sequence Number, can be optionally carried in the \hyperref[intro:rfc2784]{GRE} Header.

This does look nicer.

>  	\newline\url{https://www.rfc-editor.org/rfc/rfc2890}\\
>  	\phantomsection\label{intro:rfc7676}\textbf{[RFC7676]} &
>      IPv6 Support for Generic Routing Encapsulation (GRE). This protocol is specified for IPv6 and used as either the payload or


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

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

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

[virtio-dev] Re: [virtio-comment] Re: [PATCH 0/4] Short document fixes to inner hash feature

[Michael S. Tsirkin]

On Thu, Jul 13, 2023 at 11:32:32AM +0200, Cornelia Huck wrote:
> On Thu, Jul 13 2023, Cornelia Huck <cohuck@redhat.com> wrote:
> 
> > On Thu, Jul 13 2023, Parav Pandit <parav@nvidia.com> wrote:
> >
> >> This short patches fixes the editing errors that stops the pdf and html
> >> generation.
> >>
> >> These 3 fixes are for the patch [1] for the github issue [2].
> >>
> >> [1] https://lists.oasis-open.org/archives/virtio-comment/202307/msg00024.html
> >> [2] https://github.com/oasis-tcs/virtio-spec/issues/173
> >>
> >> Patch summary:
> >> patch-1 place C code under listing
> >> patch-2 avoid hyphen and extra braces
> >> patch-3 use table as hyperlink do not work well in C code listing
> >> patch-4 refer 'advice' as 'note'
> >>
> >> Patch 1 to 3 appears to be must in the testing.
> >> Patch 4 is not a fix and can be done later if it requires discussion.
> >>
> >> Parav Pandit (4):
> >>   virtio-net: Place C code under listing
> >>   virtio-net: Avoid hyphen and extra braces
> >>   virtio-net: Use table to describe inner hash to rfc mapping
> >>   virtio-net: Use note instead of advice
> >>
> >>  device-types/net/description.tex | 45 ++++++++++++++++++++++----------
> >>  introduction.tex                 | 15 +++++------
> >>  2 files changed, 38 insertions(+), 22 deletions(-)
> >>
> >
> > FTR, this is the diff I have locally (I had missed one underscore in the
> > references yesterday...); maybe we can make the intra-reference links in
> > introdcution.tex a bit nicer, but otherwise, this should be the minimal
> > change to make this build:
> 
> For the "make it look nicer" part, I think this one would get the job
> done; opinions?
> 
> diff --git a/introduction.tex b/introduction.tex
> index 6f10a94b6fde..1e39a4b2c529 100644
> --- a/introduction.tex
> +++ b/introduction.tex
> @@ -106,8 +106,8 @@ \section{Normative References}\label{sec:Normative References}
>      Generic Routing Encapsulation. This protocol is only specified for IPv4 and used as either the payload or delivery protocol.
>  	\newline\url{https://datatracker.ietf.org/doc/rfc2784/}\\
>  	\phantomsection\label{intro:rfc2890}\textbf{[RFC2890]} &
> -    Key and Sequence Number Extensions to GRE \ref{intro:rfc2784}. This protocol describes extensions by which two fields, Key and
> -    Sequence Number, can be optionally carried in the GRE Header \ref{intro:rfc2784}.
> +    Key and Sequence Number Extensions to \hyperref[intro:rfc2784]{GRE}. This protocol describes extensions by which two fields, Key and
> +    Sequence Number, can be optionally carried in the \hyperref[intro:rfc2784]{GRE} Header.

This does look nicer.

>  	\newline\url{https://www.rfc-editor.org/rfc/rfc2890}\\
>  	\phantomsection\label{intro:rfc7676}\textbf{[RFC7676]} &
>      IPv6 Support for Generic Routing Encapsulation (GRE). This protocol is specified for IPv6 and used as either the payload or


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

[virtio-comment] Re: [PATCH 0/4] Short document fixes to inner hash feature

[Michael S. Tsirkin]

On Thu, Jul 13, 2023 at 11:12:13AM +0200, Cornelia Huck wrote:
> On Thu, Jul 13 2023, Parav Pandit <parav@nvidia.com> wrote:
> 
> > This short patches fixes the editing errors that stops the pdf and html
> > generation.
> >
> > These 3 fixes are for the patch [1] for the github issue [2].
> >
> > [1] https://lists.oasis-open.org/archives/virtio-comment/202307/msg00024.html
> > [2] https://github.com/oasis-tcs/virtio-spec/issues/173
> >
> > Patch summary:
> > patch-1 place C code under listing
> > patch-2 avoid hyphen and extra braces
> > patch-3 use table as hyperlink do not work well in C code listing
> > patch-4 refer 'advice' as 'note'
> >
> > Patch 1 to 3 appears to be must in the testing.
> > Patch 4 is not a fix and can be done later if it requires discussion.
> >
> > Parav Pandit (4):
> >   virtio-net: Place C code under listing
> >   virtio-net: Avoid hyphen and extra braces
> >   virtio-net: Use table to describe inner hash to rfc mapping
> >   virtio-net: Use note instead of advice
> >
> >  device-types/net/description.tex | 45 ++++++++++++++++++++++----------
> >  introduction.tex                 | 15 +++++------
> >  2 files changed, 38 insertions(+), 22 deletions(-)
> >
> 
> FTR, this is the diff I have locally (I had missed one underscore in the
> references yesterday...); maybe we can make the intra-reference links in
> introdcution.tex a bit nicer, but otherwise, this should be the minimal
> change to make this build:

Perfect. Seems like clearly an editorial fix.

Heng Qi, in the future I'd like to ask you to please build the
spec and review the resulting PDF and HTML, before posting.



> diff --git a/device-types/net/description.tex b/device-types/net/description.tex
> index 206020de567d..76585b0dd6d3 100644
> --- a/device-types/net/description.tex
> +++ b/device-types/net/description.tex
> @@ -1024,12 +1024,14 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
>  If VIRTIO_NET_F_HASH_TUNNEL has been negotiated, the driver can send the command
>  VIRTIO_NET_CTRL_HASH_TUNNEL_SET to configure the calculation of the inner header hash.
>  
> +\begin{lstlisting}
>  struct virtnet_hash_tunnel {
>      le32 enabled_tunnel_types;
>  };
>  
>  #define VIRTIO_NET_CTRL_HASH_TUNNEL 7
>   #define VIRTIO_NET_CTRL_HASH_TUNNEL_SET 0
> +\end{lstlisting}
>  
>  Field \field{enabled_tunnel_types} contains the bitmask of encapsulation types enabled for inner header hash.
>  See \ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets /
> @@ -1063,16 +1065,16 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
>  Hash calculation for incoming packets / Encapsulation types supported/enabled for inner header hash}
>  
>  Encapsulation types applicable for inner header hash:
> -\begin{lstlisting}
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784    (1 << 0) /* \hyperref[intro:gre_rfc2784]{[GRE_rfc2784]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890    (1 << 1) /* \hyperref[intro:gre_rfc2890]{[GRE_rfc2890]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676    (1 << 2) /* \hyperref[intro:gre_rfc7676]{[GRE_rfc7676]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP     (1 << 3) /* \hyperref[intro:gre_in_udp_rfc8086]{[GRE-in-UDP]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN       (1 << 4) /* \hyperref[intro:vxlan]{[VXLAN]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE   (1 << 5) /* \hyperref[intro:vxlan_gpe]{[VXLAN-GPE]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE      (1 << 6) /* \hyperref[intro:geneve]{[GENEVE]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP        (1 << 7) /* \hyperref[intro:ipip]{[IPIP]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE       (1 << 8) /* \hyperref[intro:nvgre]{[NVGRE]} */
> +\begin{lstlisting}[escapechar=|]
> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784    (1 << 0) /* |\hyperref[intro:rfc2784]{[RFC2784]}| */
> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890    (1 << 1) /* |\hyperref[intro:rfc2890]{[RFC2890]}| */
> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676    (1 << 2) /* |\hyperref[intro:rfc7676]{[RFC7676]}| */
> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP     (1 << 3) /* |\hyperref[intro:rfc8086]{[GRE-in-UDP]}| */
> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN       (1 << 4) /* |\hyperref[intro:vxlan]{[VXLAN]}| */
> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE   (1 << 5) /* |\hyperref[intro:vxlan-gpe]{[VXLAN-GPE]}| */
> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE      (1 << 6) /* |\hyperref[intro:geneve]{[GENEVE]}| */
> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP        (1 << 7) /* |\hyperref[intro:ipip]{[IPIP]}| */
> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE       (1 << 8) /* |\hyperref[intro:nvgre]{[NVGRE]}| */
>  \end{lstlisting}
>  
>  \subparagraph{Advice}
> diff --git a/introduction.tex b/introduction.tex
> index 81f07a4fee19..6f10a94b6fde 100644
> --- a/introduction.tex
> +++ b/introduction.tex
> @@ -102,18 +102,18 @@ \section{Normative References}\label{sec:Normative References}
>      Standards for Efficient Cryptography Group(SECG), ``SEC1: Elliptic Cureve Cryptography'', Version 1.0, September 2000.
>  	\newline\url{https://www.secg.org/sec1-v2.pdf}\\
>  
> -	\phantomsection\label{intro:gre_rfc2784}\textbf{[GRE_rfc2784]} &
> +	\phantomsection\label{intro:rfc2784}\textbf{[RFC2784]} &
>      Generic Routing Encapsulation. This protocol is only specified for IPv4 and used as either the payload or delivery protocol.
>  	\newline\url{https://datatracker.ietf.org/doc/rfc2784/}\\
> -	\phantomsection\label{intro:gre_rfc2890}\textbf{[GRE_rfc2890]} &
> -    Key and Sequence Number Extensions to GRE \ref{intro:gre_rfc2784}. This protocol describes extensions by which two fields, Key and
> -    Sequence Number, can be optionally carried in the GRE Header \ref{intro:gre_rfc2784}.
> +	\phantomsection\label{intro:rfc2890}\textbf{[RFC2890]} &
> +    Key and Sequence Number Extensions to GRE \ref{intro:rfc2784}. This protocol describes extensions by which two fields, Key and
> +    Sequence Number, can be optionally carried in the GRE Header \ref{intro:rfc2784}.
>  	\newline\url{https://www.rfc-editor.org/rfc/rfc2890}\\
> -	\phantomsection\label{intro:gre_rfc7676}\textbf{[GRE_rfc7676]} &
> +	\phantomsection\label{intro:rfc7676}\textbf{[RFC7676]} &
>      IPv6 Support for Generic Routing Encapsulation (GRE). This protocol is specified for IPv6 and used as either the payload or
>      delivery protocol. Note that this does not change the GRE header format or any behaviors specified by RFC 2784 or RFC 2890.
>  	\newline\url{https://datatracker.ietf.org/doc/rfc7676/}\\
> -	\phantomsection\label{intro:gre_in_udp_rfc8086}\textbf{[GRE-in-UDP]} &
> +	\phantomsection\label{intro:rfc8086}\textbf{[GRE-in-UDP]} &
>      GRE-in-UDP Encapsulation. This specifies a method of encapsulating network protocol packets within GRE and UDP headers.
>      This protocol is specified for IPv4 and IPv6, and used as either the payload or delivery protocol.
>  	\newline\url{https://www.rfc-editor.org/rfc/rfc8086}\\


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

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

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

[virtio-dev] Re: [PATCH 0/4] Short document fixes to inner hash feature

[Michael S. Tsirkin]

On Thu, Jul 13, 2023 at 11:12:13AM +0200, Cornelia Huck wrote:
> On Thu, Jul 13 2023, Parav Pandit <parav@nvidia.com> wrote:
> 
> > This short patches fixes the editing errors that stops the pdf and html
> > generation.
> >
> > These 3 fixes are for the patch [1] for the github issue [2].
> >
> > [1] https://lists.oasis-open.org/archives/virtio-comment/202307/msg00024.html
> > [2] https://github.com/oasis-tcs/virtio-spec/issues/173
> >
> > Patch summary:
> > patch-1 place C code under listing
> > patch-2 avoid hyphen and extra braces
> > patch-3 use table as hyperlink do not work well in C code listing
> > patch-4 refer 'advice' as 'note'
> >
> > Patch 1 to 3 appears to be must in the testing.
> > Patch 4 is not a fix and can be done later if it requires discussion.
> >
> > Parav Pandit (4):
> >   virtio-net: Place C code under listing
> >   virtio-net: Avoid hyphen and extra braces
> >   virtio-net: Use table to describe inner hash to rfc mapping
> >   virtio-net: Use note instead of advice
> >
> >  device-types/net/description.tex | 45 ++++++++++++++++++++++----------
> >  introduction.tex                 | 15 +++++------
> >  2 files changed, 38 insertions(+), 22 deletions(-)
> >
> 
> FTR, this is the diff I have locally (I had missed one underscore in the
> references yesterday...); maybe we can make the intra-reference links in
> introdcution.tex a bit nicer, but otherwise, this should be the minimal
> change to make this build:

Perfect. Seems like clearly an editorial fix.

Heng Qi, in the future I'd like to ask you to please build the
spec and review the resulting PDF and HTML, before posting.



> diff --git a/device-types/net/description.tex b/device-types/net/description.tex
> index 206020de567d..76585b0dd6d3 100644
> --- a/device-types/net/description.tex
> +++ b/device-types/net/description.tex
> @@ -1024,12 +1024,14 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
>  If VIRTIO_NET_F_HASH_TUNNEL has been negotiated, the driver can send the command
>  VIRTIO_NET_CTRL_HASH_TUNNEL_SET to configure the calculation of the inner header hash.
>  
> +\begin{lstlisting}
>  struct virtnet_hash_tunnel {
>      le32 enabled_tunnel_types;
>  };
>  
>  #define VIRTIO_NET_CTRL_HASH_TUNNEL 7
>   #define VIRTIO_NET_CTRL_HASH_TUNNEL_SET 0
> +\end{lstlisting}
>  
>  Field \field{enabled_tunnel_types} contains the bitmask of encapsulation types enabled for inner header hash.
>  See \ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets /
> @@ -1063,16 +1065,16 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
>  Hash calculation for incoming packets / Encapsulation types supported/enabled for inner header hash}
>  
>  Encapsulation types applicable for inner header hash:
> -\begin{lstlisting}
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784    (1 << 0) /* \hyperref[intro:gre_rfc2784]{[GRE_rfc2784]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890    (1 << 1) /* \hyperref[intro:gre_rfc2890]{[GRE_rfc2890]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676    (1 << 2) /* \hyperref[intro:gre_rfc7676]{[GRE_rfc7676]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP     (1 << 3) /* \hyperref[intro:gre_in_udp_rfc8086]{[GRE-in-UDP]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN       (1 << 4) /* \hyperref[intro:vxlan]{[VXLAN]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE   (1 << 5) /* \hyperref[intro:vxlan_gpe]{[VXLAN-GPE]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE      (1 << 6) /* \hyperref[intro:geneve]{[GENEVE]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP        (1 << 7) /* \hyperref[intro:ipip]{[IPIP]} */
> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE       (1 << 8) /* \hyperref[intro:nvgre]{[NVGRE]} */
> +\begin{lstlisting}[escapechar=|]
> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784    (1 << 0) /* |\hyperref[intro:rfc2784]{[RFC2784]}| */
> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890    (1 << 1) /* |\hyperref[intro:rfc2890]{[RFC2890]}| */
> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676    (1 << 2) /* |\hyperref[intro:rfc7676]{[RFC7676]}| */
> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP     (1 << 3) /* |\hyperref[intro:rfc8086]{[GRE-in-UDP]}| */
> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN       (1 << 4) /* |\hyperref[intro:vxlan]{[VXLAN]}| */
> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE   (1 << 5) /* |\hyperref[intro:vxlan-gpe]{[VXLAN-GPE]}| */
> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE      (1 << 6) /* |\hyperref[intro:geneve]{[GENEVE]}| */
> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP        (1 << 7) /* |\hyperref[intro:ipip]{[IPIP]}| */
> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE       (1 << 8) /* |\hyperref[intro:nvgre]{[NVGRE]}| */
>  \end{lstlisting}
>  
>  \subparagraph{Advice}
> diff --git a/introduction.tex b/introduction.tex
> index 81f07a4fee19..6f10a94b6fde 100644
> --- a/introduction.tex
> +++ b/introduction.tex
> @@ -102,18 +102,18 @@ \section{Normative References}\label{sec:Normative References}
>      Standards for Efficient Cryptography Group(SECG), ``SEC1: Elliptic Cureve Cryptography'', Version 1.0, September 2000.
>  	\newline\url{https://www.secg.org/sec1-v2.pdf}\\
>  
> -	\phantomsection\label{intro:gre_rfc2784}\textbf{[GRE_rfc2784]} &
> +	\phantomsection\label{intro:rfc2784}\textbf{[RFC2784]} &
>      Generic Routing Encapsulation. This protocol is only specified for IPv4 and used as either the payload or delivery protocol.
>  	\newline\url{https://datatracker.ietf.org/doc/rfc2784/}\\
> -	\phantomsection\label{intro:gre_rfc2890}\textbf{[GRE_rfc2890]} &
> -    Key and Sequence Number Extensions to GRE \ref{intro:gre_rfc2784}. This protocol describes extensions by which two fields, Key and
> -    Sequence Number, can be optionally carried in the GRE Header \ref{intro:gre_rfc2784}.
> +	\phantomsection\label{intro:rfc2890}\textbf{[RFC2890]} &
> +    Key and Sequence Number Extensions to GRE \ref{intro:rfc2784}. This protocol describes extensions by which two fields, Key and
> +    Sequence Number, can be optionally carried in the GRE Header \ref{intro:rfc2784}.
>  	\newline\url{https://www.rfc-editor.org/rfc/rfc2890}\\
> -	\phantomsection\label{intro:gre_rfc7676}\textbf{[GRE_rfc7676]} &
> +	\phantomsection\label{intro:rfc7676}\textbf{[RFC7676]} &
>      IPv6 Support for Generic Routing Encapsulation (GRE). This protocol is specified for IPv6 and used as either the payload or
>      delivery protocol. Note that this does not change the GRE header format or any behaviors specified by RFC 2784 or RFC 2890.
>  	\newline\url{https://datatracker.ietf.org/doc/rfc7676/}\\
> -	\phantomsection\label{intro:gre_in_udp_rfc8086}\textbf{[GRE-in-UDP]} &
> +	\phantomsection\label{intro:rfc8086}\textbf{[GRE-in-UDP]} &
>      GRE-in-UDP Encapsulation. This specifies a method of encapsulating network protocol packets within GRE and UDP headers.
>      This protocol is specified for IPv4 and IPv6, and used as either the payload or delivery protocol.
>  	\newline\url{https://www.rfc-editor.org/rfc/rfc8086}\\


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

[virtio-comment] Re: [PATCH 0/4] Short document fixes to inner hash feature

[Heng Qi]

在 2023/7/13 下午7:33, Michael S. Tsirkin 写道:
> On Thu, Jul 13, 2023 at 11:12:13AM +0200, Cornelia Huck wrote:
>> On Thu, Jul 13 2023, Parav Pandit <parav@nvidia.com> wrote:
>>
>>> This short patches fixes the editing errors that stops the pdf and html
>>> generation.
>>>
>>> These 3 fixes are for the patch [1] for the github issue [2].
>>>
>>> [1] https://lists.oasis-open.org/archives/virtio-comment/202307/msg00024.html
>>> [2] https://github.com/oasis-tcs/virtio-spec/issues/173
>>>
>>> Patch summary:
>>> patch-1 place C code under listing
>>> patch-2 avoid hyphen and extra braces
>>> patch-3 use table as hyperlink do not work well in C code listing
>>> patch-4 refer 'advice' as 'note'
>>>
>>> Patch 1 to 3 appears to be must in the testing.
>>> Patch 4 is not a fix and can be done later if it requires discussion.
>>>
>>> Parav Pandit (4):
>>>    virtio-net: Place C code under listing
>>>    virtio-net: Avoid hyphen and extra braces
>>>    virtio-net: Use table to describe inner hash to rfc mapping
>>>    virtio-net: Use note instead of advice
>>>
>>>   device-types/net/description.tex | 45 ++++++++++++++++++++++----------
>>>   introduction.tex                 | 15 +++++------
>>>   2 files changed, 38 insertions(+), 22 deletions(-)
>>>
>> FTR, this is the diff I have locally (I had missed one underscore in the
>> references yesterday...); maybe we can make the intra-reference links in
>> introdcution.tex a bit nicer, but otherwise, this should be the minimal
>> change to make this build:
> Perfect. Seems like clearly an editorial fix.
>
> Heng Qi, in the future I'd like to ask you to please build the
> spec and review the resulting PDF and HTML, before posting.

Yes, I will!

>
>
>
>> diff --git a/device-types/net/description.tex b/device-types/net/description.tex
>> index 206020de567d..76585b0dd6d3 100644
>> --- a/device-types/net/description.tex
>> +++ b/device-types/net/description.tex
>> @@ -1024,12 +1024,14 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
>>   If VIRTIO_NET_F_HASH_TUNNEL has been negotiated, the driver can send the command
>>   VIRTIO_NET_CTRL_HASH_TUNNEL_SET to configure the calculation of the inner header hash.
>>   
>> +\begin{lstlisting}
>>   struct virtnet_hash_tunnel {
>>       le32 enabled_tunnel_types;
>>   };
>>   
>>   #define VIRTIO_NET_CTRL_HASH_TUNNEL 7
>>    #define VIRTIO_NET_CTRL_HASH_TUNNEL_SET 0
>> +\end{lstlisting}
>>   
>>   Field \field{enabled_tunnel_types} contains the bitmask of encapsulation types enabled for inner header hash.
>>   See \ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets /
>> @@ -1063,16 +1065,16 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
>>   Hash calculation for incoming packets / Encapsulation types supported/enabled for inner header hash}
>>   
>>   Encapsulation types applicable for inner header hash:
>> -\begin{lstlisting}
>> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784    (1 << 0) /* \hyperref[intro:gre_rfc2784]{[GRE_rfc2784]} */
>> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890    (1 << 1) /* \hyperref[intro:gre_rfc2890]{[GRE_rfc2890]} */
>> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676    (1 << 2) /* \hyperref[intro:gre_rfc7676]{[GRE_rfc7676]} */
>> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP     (1 << 3) /* \hyperref[intro:gre_in_udp_rfc8086]{[GRE-in-UDP]} */
>> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN       (1 << 4) /* \hyperref[intro:vxlan]{[VXLAN]} */
>> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE   (1 << 5) /* \hyperref[intro:vxlan_gpe]{[VXLAN-GPE]} */
>> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE      (1 << 6) /* \hyperref[intro:geneve]{[GENEVE]} */
>> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP        (1 << 7) /* \hyperref[intro:ipip]{[IPIP]} */
>> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE       (1 << 8) /* \hyperref[intro:nvgre]{[NVGRE]} */
>> +\begin{lstlisting}[escapechar=|]
>> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784    (1 << 0) /* |\hyperref[intro:rfc2784]{[RFC2784]}| */
>> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890    (1 << 1) /* |\hyperref[intro:rfc2890]{[RFC2890]}| */
>> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676    (1 << 2) /* |\hyperref[intro:rfc7676]{[RFC7676]}| */
>> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP     (1 << 3) /* |\hyperref[intro:rfc8086]{[GRE-in-UDP]}| */
>> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN       (1 << 4) /* |\hyperref[intro:vxlan]{[VXLAN]}| */
>> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE   (1 << 5) /* |\hyperref[intro:vxlan-gpe]{[VXLAN-GPE]}| */
>> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE      (1 << 6) /* |\hyperref[intro:geneve]{[GENEVE]}| */
>> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP        (1 << 7) /* |\hyperref[intro:ipip]{[IPIP]}| */
>> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE       (1 << 8) /* |\hyperref[intro:nvgre]{[NVGRE]}| */
>>   \end{lstlisting}
>>   
>>   \subparagraph{Advice}
>> diff --git a/introduction.tex b/introduction.tex
>> index 81f07a4fee19..6f10a94b6fde 100644
>> --- a/introduction.tex
>> +++ b/introduction.tex
>> @@ -102,18 +102,18 @@ \section{Normative References}\label{sec:Normative References}
>>       Standards for Efficient Cryptography Group(SECG), ``SEC1: Elliptic Cureve Cryptography'', Version 1.0, September 2000.
>>   	\newline\url{https://www.secg.org/sec1-v2.pdf}\\
>>   
>> -	\phantomsection\label{intro:gre_rfc2784}\textbf{[GRE_rfc2784]} &
>> +	\phantomsection\label{intro:rfc2784}\textbf{[RFC2784]} &
>>       Generic Routing Encapsulation. This protocol is only specified for IPv4 and used as either the payload or delivery protocol.
>>   	\newline\url{https://datatracker.ietf.org/doc/rfc2784/}\\
>> -	\phantomsection\label{intro:gre_rfc2890}\textbf{[GRE_rfc2890]} &
>> -    Key and Sequence Number Extensions to GRE \ref{intro:gre_rfc2784}. This protocol describes extensions by which two fields, Key and
>> -    Sequence Number, can be optionally carried in the GRE Header \ref{intro:gre_rfc2784}.
>> +	\phantomsection\label{intro:rfc2890}\textbf{[RFC2890]} &
>> +    Key and Sequence Number Extensions to GRE \ref{intro:rfc2784}. This protocol describes extensions by which two fields, Key and
>> +    Sequence Number, can be optionally carried in the GRE Header \ref{intro:rfc2784}.
>>   	\newline\url{https://www.rfc-editor.org/rfc/rfc2890}\\
>> -	\phantomsection\label{intro:gre_rfc7676}\textbf{[GRE_rfc7676]} &
>> +	\phantomsection\label{intro:rfc7676}\textbf{[RFC7676]} &
>>       IPv6 Support for Generic Routing Encapsulation (GRE). This protocol is specified for IPv6 and used as either the payload or
>>       delivery protocol. Note that this does not change the GRE header format or any behaviors specified by RFC 2784 or RFC 2890.
>>   	\newline\url{https://datatracker.ietf.org/doc/rfc7676/}\\
>> -	\phantomsection\label{intro:gre_in_udp_rfc8086}\textbf{[GRE-in-UDP]} &
>> +	\phantomsection\label{intro:rfc8086}\textbf{[GRE-in-UDP]} &
>>       GRE-in-UDP Encapsulation. This specifies a method of encapsulating network protocol packets within GRE and UDP headers.
>>       This protocol is specified for IPv4 and IPv6, and used as either the payload or delivery protocol.
>>   	\newline\url{https://www.rfc-editor.org/rfc/rfc8086}\\


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

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

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

[virtio-dev] Re: [PATCH 0/4] Short document fixes to inner hash feature

[Heng Qi]

在 2023/7/13 下午7:33, Michael S. Tsirkin 写道:
> On Thu, Jul 13, 2023 at 11:12:13AM +0200, Cornelia Huck wrote:
>> On Thu, Jul 13 2023, Parav Pandit <parav@nvidia.com> wrote:
>>
>>> This short patches fixes the editing errors that stops the pdf and html
>>> generation.
>>>
>>> These 3 fixes are for the patch [1] for the github issue [2].
>>>
>>> [1] https://lists.oasis-open.org/archives/virtio-comment/202307/msg00024.html
>>> [2] https://github.com/oasis-tcs/virtio-spec/issues/173
>>>
>>> Patch summary:
>>> patch-1 place C code under listing
>>> patch-2 avoid hyphen and extra braces
>>> patch-3 use table as hyperlink do not work well in C code listing
>>> patch-4 refer 'advice' as 'note'
>>>
>>> Patch 1 to 3 appears to be must in the testing.
>>> Patch 4 is not a fix and can be done later if it requires discussion.
>>>
>>> Parav Pandit (4):
>>>    virtio-net: Place C code under listing
>>>    virtio-net: Avoid hyphen and extra braces
>>>    virtio-net: Use table to describe inner hash to rfc mapping
>>>    virtio-net: Use note instead of advice
>>>
>>>   device-types/net/description.tex | 45 ++++++++++++++++++++++----------
>>>   introduction.tex                 | 15 +++++------
>>>   2 files changed, 38 insertions(+), 22 deletions(-)
>>>
>> FTR, this is the diff I have locally (I had missed one underscore in the
>> references yesterday...); maybe we can make the intra-reference links in
>> introdcution.tex a bit nicer, but otherwise, this should be the minimal
>> change to make this build:
> Perfect. Seems like clearly an editorial fix.
>
> Heng Qi, in the future I'd like to ask you to please build the
> spec and review the resulting PDF and HTML, before posting.

Yes, I will!

>
>
>
>> diff --git a/device-types/net/description.tex b/device-types/net/description.tex
>> index 206020de567d..76585b0dd6d3 100644
>> --- a/device-types/net/description.tex
>> +++ b/device-types/net/description.tex
>> @@ -1024,12 +1024,14 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
>>   If VIRTIO_NET_F_HASH_TUNNEL has been negotiated, the driver can send the command
>>   VIRTIO_NET_CTRL_HASH_TUNNEL_SET to configure the calculation of the inner header hash.
>>   
>> +\begin{lstlisting}
>>   struct virtnet_hash_tunnel {
>>       le32 enabled_tunnel_types;
>>   };
>>   
>>   #define VIRTIO_NET_CTRL_HASH_TUNNEL 7
>>    #define VIRTIO_NET_CTRL_HASH_TUNNEL_SET 0
>> +\end{lstlisting}
>>   
>>   Field \field{enabled_tunnel_types} contains the bitmask of encapsulation types enabled for inner header hash.
>>   See \ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets /
>> @@ -1063,16 +1065,16 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
>>   Hash calculation for incoming packets / Encapsulation types supported/enabled for inner header hash}
>>   
>>   Encapsulation types applicable for inner header hash:
>> -\begin{lstlisting}
>> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784    (1 << 0) /* \hyperref[intro:gre_rfc2784]{[GRE_rfc2784]} */
>> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890    (1 << 1) /* \hyperref[intro:gre_rfc2890]{[GRE_rfc2890]} */
>> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676    (1 << 2) /* \hyperref[intro:gre_rfc7676]{[GRE_rfc7676]} */
>> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP     (1 << 3) /* \hyperref[intro:gre_in_udp_rfc8086]{[GRE-in-UDP]} */
>> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN       (1 << 4) /* \hyperref[intro:vxlan]{[VXLAN]} */
>> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE   (1 << 5) /* \hyperref[intro:vxlan_gpe]{[VXLAN-GPE]} */
>> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE      (1 << 6) /* \hyperref[intro:geneve]{[GENEVE]} */
>> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP        (1 << 7) /* \hyperref[intro:ipip]{[IPIP]} */
>> -#define VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE       (1 << 8) /* \hyperref[intro:nvgre]{[NVGRE]} */
>> +\begin{lstlisting}[escapechar=|]
>> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2784    (1 << 0) /* |\hyperref[intro:rfc2784]{[RFC2784]}| */
>> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_2890    (1 << 1) /* |\hyperref[intro:rfc2890]{[RFC2890]}| */
>> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_7676    (1 << 2) /* |\hyperref[intro:rfc7676]{[RFC7676]}| */
>> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE_UDP     (1 << 3) /* |\hyperref[intro:rfc8086]{[GRE-in-UDP]}| */
>> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN       (1 << 4) /* |\hyperref[intro:vxlan]{[VXLAN]}| */
>> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN_GPE   (1 << 5) /* |\hyperref[intro:vxlan-gpe]{[VXLAN-GPE]}| */
>> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE      (1 << 6) /* |\hyperref[intro:geneve]{[GENEVE]}| */
>> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP        (1 << 7) /* |\hyperref[intro:ipip]{[IPIP]}| */
>> +#define VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE       (1 << 8) /* |\hyperref[intro:nvgre]{[NVGRE]}| */
>>   \end{lstlisting}
>>   
>>   \subparagraph{Advice}
>> diff --git a/introduction.tex b/introduction.tex
>> index 81f07a4fee19..6f10a94b6fde 100644
>> --- a/introduction.tex
>> +++ b/introduction.tex
>> @@ -102,18 +102,18 @@ \section{Normative References}\label{sec:Normative References}
>>       Standards for Efficient Cryptography Group(SECG), ``SEC1: Elliptic Cureve Cryptography'', Version 1.0, September 2000.
>>   	\newline\url{https://www.secg.org/sec1-v2.pdf}\\
>>   
>> -	\phantomsection\label{intro:gre_rfc2784}\textbf{[GRE_rfc2784]} &
>> +	\phantomsection\label{intro:rfc2784}\textbf{[RFC2784]} &
>>       Generic Routing Encapsulation. This protocol is only specified for IPv4 and used as either the payload or delivery protocol.
>>   	\newline\url{https://datatracker.ietf.org/doc/rfc2784/}\\
>> -	\phantomsection\label{intro:gre_rfc2890}\textbf{[GRE_rfc2890]} &
>> -    Key and Sequence Number Extensions to GRE \ref{intro:gre_rfc2784}. This protocol describes extensions by which two fields, Key and
>> -    Sequence Number, can be optionally carried in the GRE Header \ref{intro:gre_rfc2784}.
>> +	\phantomsection\label{intro:rfc2890}\textbf{[RFC2890]} &
>> +    Key and Sequence Number Extensions to GRE \ref{intro:rfc2784}. This protocol describes extensions by which two fields, Key and
>> +    Sequence Number, can be optionally carried in the GRE Header \ref{intro:rfc2784}.
>>   	\newline\url{https://www.rfc-editor.org/rfc/rfc2890}\\
>> -	\phantomsection\label{intro:gre_rfc7676}\textbf{[GRE_rfc7676]} &
>> +	\phantomsection\label{intro:rfc7676}\textbf{[RFC7676]} &
>>       IPv6 Support for Generic Routing Encapsulation (GRE). This protocol is specified for IPv6 and used as either the payload or
>>       delivery protocol. Note that this does not change the GRE header format or any behaviors specified by RFC 2784 or RFC 2890.
>>   	\newline\url{https://datatracker.ietf.org/doc/rfc7676/}\\
>> -	\phantomsection\label{intro:gre_in_udp_rfc8086}\textbf{[GRE-in-UDP]} &
>> +	\phantomsection\label{intro:rfc8086}\textbf{[GRE-in-UDP]} &
>>       GRE-in-UDP Encapsulation. This specifies a method of encapsulating network protocol packets within GRE and UDP headers.
>>       This protocol is specified for IPv4 and IPv6, and used as either the payload or delivery protocol.
>>   	\newline\url{https://www.rfc-editor.org/rfc/rfc8086}\\


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