All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Parav Pandit <parav@nvidia.com>,
	mst@redhat.com, virtio-dev@lists.oasis-open.org
Cc: virtio-comment@lists.oasis-open.org, shahafs@nvidia.com,
	Parav Pandit <parav@nvidia.com>
Subject: [virtio-dev] Re: [PATCH v3 1/2] virtio-net: Describe dev cfg fields read only
Date: Tue, 21 Feb 2023 16:37:16 +0100	[thread overview]
Message-ID: <87wn4byqqb.fsf@redhat.com> (raw)
In-Reply-To: <20230217154529.33508-2-parav@nvidia.com>

On Fri, Feb 17 2023, Parav Pandit <parav@nvidia.com> wrote:

> Device configuration fields are read only. Avoid duplicating this
> description for multiple fields.
>
> Instead describe it one time and do it in the driver requirements
> section.
>
> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/161
> Signed-off-by: Parav Pandit <parav@nvidia.com>
> ---
> changelog:
> v2->v3:
> - split as new patch
> ---
>  device-types/net/description.tex | 12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/device-types/net/description.tex b/device-types/net/description.tex
> index a197e1a..81e1135 100644
> --- a/device-types/net/description.tex
> +++ b/device-types/net/description.tex
> @@ -156,10 +156,10 @@ \subsubsection{Legacy Interface: Feature bits}\label{sec:Device Types / Network
>  \subsection{Device configuration layout}\label{sec:Device Types / Network Device / Device configuration layout}
>  \label{sec:Device Types / Block Device / Feature bits / Device configuration layout}
>  
> -Device configuration fields are listed below, they are read-only for a driver. The \field{mac} address field
> +Device configuration fields are listed below. The \field{mac} address field

I would not remove this here, as I don't think we should move a simple
statement into the conformance section (see below.) It does makes sense
to remove the duplicate read-only annotations from the individual
fields.

>  always exists (though is only valid if VIRTIO_NET_F_MAC is set), and
>  \field{status} only exists if VIRTIO_NET_F_STATUS is set. Two
> -read-only bits (for the driver) are currently defined for the status field:
> +bits (for the driver) are currently defined for the status field:

What does "bits (for the driver)" mean? It made sense together with
"read-only", but I would drop "(for the driver)" as well.

>  VIRTIO_NET_S_LINK_UP and VIRTIO_NET_S_ANNOUNCE.
>  
>  \begin{lstlisting}
> @@ -167,14 +167,14 @@ \subsection{Device configuration layout}\label{sec:Device Types / Network Device
>  #define VIRTIO_NET_S_ANNOUNCE    2
>  \end{lstlisting}
>  
> -The following driver-read-only field, \field{max_virtqueue_pairs} only exists if
> +The following field, \field{max_virtqueue_pairs} only exists if
>  VIRTIO_NET_F_MQ or VIRTIO_NET_F_RSS is set. This field specifies the maximum number
>  of each of transmit and receive virtqueues (receiveq1\ldots receiveqN
>  and transmitq1\ldots transmitqN respectively) that can be configured once at least one of these features
>  is negotiated.
>  
> -The following driver-read-only field, \field{mtu} only exists if
> -VIRTIO_NET_F_MTU is set. This field specifies the maximum MTU for the driver to
> +The following field, \field{mtu} only exists if VIRTIO_NET_F_MTU
> +is set. This field specifies the maximum MTU for the driver to
>  use.
>  
>  The following two fields, \field{speed} and \field{duplex}, only
> @@ -261,6 +261,8 @@ \subsection{Device configuration layout}\label{sec:Device Types / Network Device
>  
>  \drivernormative{\subsubsection}{Device configuration layout}{Device Types / Network Device / Device configuration layout}
>  
> +All the device configuration fields are read-only for the driver.

Not sure if this makes a good normative clause, I would rather give the
driver something actionable:

"A driver SHOULD NOT try to write to any of the device configuration
fields."

> +
>  A driver SHOULD negotiate VIRTIO_NET_F_MAC if the device offers it.
>  If the driver negotiates the VIRTIO_NET_F_MAC feature, the driver MUST set
>  the physical address of the NIC to \field{mac}.  Otherwise, it SHOULD


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


  parent reply	other threads:[~2023-02-21 15:37 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-17 15:45 [virtio-comment] [PATCH v3 0/2] virtio-net: Improve dev config layout Parav Pandit
2023-02-17 15:45 ` [PATCH v3 1/2] virtio-net: Describe dev cfg fields read only Parav Pandit
2023-02-20 14:46   ` [virtio-dev] " David Edmondson
2023-02-21 15:37   ` Cornelia Huck [this message]
2023-02-21 17:42     ` Michael S. Tsirkin
2023-02-21 17:50       ` Parav Pandit
2023-02-21 17:52         ` Michael S. Tsirkin
2023-02-21 17:59           ` Parav Pandit
2023-02-21 18:08             ` Michael S. Tsirkin
2023-02-22  9:01               ` [virtio-dev] " Cornelia Huck
2023-02-22 11:50                 ` Michael S. Tsirkin
2023-02-22 12:07                   ` [virtio-comment] " Cornelia Huck
2023-02-22 12:55                     ` Michael S. Tsirkin
2023-02-22 13:26                       ` [virtio-comment] " Cornelia Huck
2023-02-23  5:50                         ` Parav Pandit
2023-02-17 15:45 ` [PATCH v3 2/2] virtio-net: Define cfg fields before description Parav Pandit
2023-02-20 14:42   ` [virtio-comment] " David Edmondson
2023-02-21 13:30 ` [PATCH v3 0/2] virtio-net: Improve dev config layout Parav Pandit
     [not found]   ` <875ybej6hb.fsf@redhat.com>
2023-03-07 17:25     ` [virtio-comment] " Parav Pandit
2023-03-07 17:25       ` [virtio-dev] " Parav Pandit
2023-03-08 10:07       ` [virtio-comment] " Cornelia Huck
2023-03-08 10:07         ` [virtio-dev] " Cornelia Huck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wn4byqqb.fsf@redhat.com \
    --to=cohuck@redhat.com \
    --cc=mst@redhat.com \
    --cc=parav@nvidia.com \
    --cc=shahafs@nvidia.com \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=virtio-dev@lists.oasis-open.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.