public inbox for virtio-dev@lists.linux.dev
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: Jason Wang <jasowang@redhat.com>,
	Heng Qi <hengqi@linux.alibaba.com>,
	"virtio-comment@lists.oasis-open.org"
	<virtio-comment@lists.oasis-open.org>,
	"virtio-dev@lists.oasis-open.org"
	<virtio-dev@lists.oasis-open.org>,
	Yuri Benditovich <yuri.benditovich@daynix.com>,
	Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Subject: [virtio-dev] Re: [virtio-comment] RE: [PATCH v19] virtio-net: support inner header hash
Date: Wed, 28 Jun 2023 15:44:31 -0400	[thread overview]
Message-ID: <20230628152125-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB54814D42786A6981467D3FADDC24A@PH0PR12MB5481.namprd12.prod.outlook.com>

On Wed, Jun 28, 2023 at 05:38:29PM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Wednesday, June 28, 2023 1:24 PM
> 
> 
> > > Because when device has two ways to access config space, it always have to
> > account and build the interface that, hey some driver will not use DMA.
> > > Hence have it always in the MMIO accessible area.
> > 
> > Maybe I get it. You want to use the new features as a carrot to force drivers to
> > implement DMA? You suspect they will ignore the spec requirement just
> > because things seem to work?
> >
> Right because it is not a must normative.

Well SHOULD also does not mean "ok to just ignore".

	This word, or the adjective "RECOMMENDED", mean that there
	   may exist valid reasons in particular circumstances to ignore a
	   particular item, but the full implications must be understood and
	   carefully weighed before choosing a different course.



> > There's some logic here, for sure. you just might be right.
> > 
> > However, surely we can discuss this small tweak in 1.4 timeframe?
> 
> Sure, if we prefer the DMA approach I don't have a problem in adding temporary one field to config space.
> 
> I propose to add a line to the spec " Device Configuration Space" section, something like,
> 
> Note: Any new device configuration space fields additional MUST consider accessing such fields via a DMA interface.
> 
> And this will guide the new patches of what to do instead of last moment rush.

Yea, except again I'd probably make it a SHOULD: e.g. I can see how
switching to MMIO might be an option for qemu helping us debug DMA
issues.

The time to discuss this detail would be around when proposal for the DMA
access to config space is on list though: I feel this SHOULD vs MUST
is a small enough detail.

Going back to inner hash. If we move supported_tunnels back to config space,
do you feel we still need GET or just drop it? I note we do not
have GET for either hash or rss config.

And if we no longer have GET is there still a reason for a separate
command as opposed to a field in virtio_net_hash_config?
I know this was done in v11 but there it was misaligned.
We went with a command because we needed it for supported_tunnels
but now that is no longer the case and
there are reserved words in virtio_net_hash_config ...

Let me know how you feel it about that, not critical for me.


-- 
MST


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


  reply	other threads:[~2023-06-28 19:44 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-27 16:35 [virtio-dev] [PATCH v19] virtio-net: support inner header hash Heng Qi
2023-06-28  3:46 ` [virtio-dev] " Jason Wang
2023-06-28  4:23   ` [virtio-dev] " Parav Pandit
2023-06-28  5:37     ` [virtio-dev] " Jason Wang
2023-06-28 15:59       ` [virtio-dev] " Parav Pandit
2023-06-29  3:17         ` [virtio-dev] " Jason Wang
2023-06-30 11:42           ` Parav Pandit
2023-06-28 10:27     ` [virtio-dev] Re: [virtio-comment] " Michael S. Tsirkin
2023-06-28 16:18       ` [virtio-dev] " Parav Pandit
2023-06-28 16:45         ` [virtio-dev] " Michael S. Tsirkin
2023-06-28 17:06           ` [virtio-dev] " Parav Pandit
2023-06-28 17:16             ` [virtio-dev] " Michael S. Tsirkin
2023-06-28 17:28               ` [virtio-dev] " Parav Pandit
2023-06-28 17:23             ` [virtio-dev] " Michael S. Tsirkin
2023-06-28 17:38               ` [virtio-dev] " Parav Pandit
2023-06-28 19:44                 ` Michael S. Tsirkin [this message]
2023-06-29  1:56                   ` Parav Pandit
2023-06-29  2:05                     ` [virtio-dev] " Heng Qi
2023-06-29 11:48                       ` Michael S. Tsirkin
2023-06-29 13:08                         ` Heng Qi
2023-06-29 16:59                         ` [virtio-dev] " Parav Pandit
2023-06-30  0:54                           ` Heng Qi
2023-06-30  1:36                             ` Parav Pandit
2023-06-30  1:55                               ` Heng Qi
2023-06-30  5:59                                 ` [virtio-dev] Re: [virtio-comment] " Michael S. Tsirkin
2023-06-30  6:15                                   ` Heng Qi
2023-06-30  8:17                                     ` Michael S. Tsirkin
2023-06-30 14:04                                       ` [virtio-dev] Re: [virtio-comment] " Heng Qi
2023-06-30 14:52                                         ` Michael S. Tsirkin
2023-06-30 16:09                                           ` Heng Qi
2023-06-30 16:56                                             ` Michael S. Tsirkin
2023-06-30 17:33                                               ` Heng Qi
2023-06-29  6:03                     ` [virtio-dev] " Michael S. Tsirkin
2023-06-29  6:40                     ` Heng Qi
2023-06-29 11:38                       ` [virtio-dev] " Parav Pandit
2023-06-29 11:46                       ` [virtio-dev] " Michael S. Tsirkin
2023-06-29 12:01                         ` [virtio-dev] " Parav Pandit
2023-06-29  7:07                     ` [virtio-dev] " Michael S. Tsirkin
2023-06-30 11:38                       ` Parav Pandit
2023-06-30 15:30                         ` Michael S. Tsirkin
2023-06-28 10:10   ` [virtio-dev] " Michael S. Tsirkin
2023-06-29  3:31     ` Jason Wang
2023-06-29 11:54       ` [virtio-dev] Re: [virtio-comment] " Michael S. Tsirkin
2023-06-29 11:55         ` Michael S. Tsirkin

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=20230628152125-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=hengqi@linux.alibaba.com \
    --cc=jasowang@redhat.com \
    --cc=parav@nvidia.com \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=xuanzhuo@linux.alibaba.com \
    --cc=yuri.benditovich@daynix.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox