All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: Cornelia Huck <cohuck@redhat.com>,
	"virtio-dev@lists.oasis-open.org"
	<virtio-dev@lists.oasis-open.org>,
	"virtio-comment@lists.oasis-open.org"
	<virtio-comment@lists.oasis-open.org>,
	Shahaf Shuler <shahafs@nvidia.com>
Subject: Re: [PATCH v3 1/2] virtio-net: Describe dev cfg fields read only
Date: Tue, 21 Feb 2023 12:52:14 -0500	[thread overview]
Message-ID: <20230221125057-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB5481AC76D8FDB8E53956EAE4DCA59@PH0PR12MB5481.namprd12.prod.outlook.com>

On Tue, Feb 21, 2023 at 05:50:09PM +0000, Parav Pandit wrote:
> 
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Tuesday, February 21, 2023 12:42 PM
> > >
> > > What does "bits (for the driver)" mean? It made sense together with
> > > "read-only", but I would drop "(for the driver)" as well.
> > 
> > Ouch Parav are you making search and replace changes without reading the
> > result? Pls don't.
> > 
> It was wrong to keep the "for the driver".
> I will fix this.
> 
> > 
> > > >  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."
> > 
> > Agree it's not a normative statement as is.
> > MUST NOT actually - they were always read only.
> > And no need to "try" just don't write period.
> > 
> Saying driver must not write it, doesn't make it read only for the device.

no but this is not what your patch said either. It's read only for the
driver.

> Hence, it should be mentioned as read-only fields, so when the driver writes something to read-only fields, it can be considered as undefined behavior on such fields.
> 

In the description not in the normative statements. normative sections
just tell driver what it must and must not do, in the standard RFC
terms.

> > > > +
> > > >  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


  reply	other threads:[~2023-02-21 17:52 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   ` [virtio-dev] " Cornelia Huck
2023-02-21 17:42     ` Michael S. Tsirkin
2023-02-21 17:50       ` Parav Pandit
2023-02-21 17:52         ` Michael S. Tsirkin [this message]
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=20230221125057-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=cohuck@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.