Re: [virtio-dev] Re: [virtio-comment] RE: [PATCH v19] virtio-net: support inner header hash

[Heng Qi <hengqi@linux.alibaba.com>]

å 2023/6/29 äå7:48, Michael S. Tsirkin åé:
> On Thu, Jun 29, 2023 at 10:05:09AM +0800, Heng Qi wrote:
> > å 2023/6/29 äå9:56, Parav Pandit åé:
> > > > From: Michael S. Tsirkin <mst@redhat.com>
> > > > Sent: Wednesday, June 28, 2023 3:45 PM
> > > > > > 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.
> > > RECOMMENDED and SHOULD forces the device to support MMIO, which is not good.
> > > So rather a good design is device tells the starting offset for the extended config space.
> > > And extended config space MUST be accessed using a DMA.
> > > With this sw can have infinite size MMIO and hw device forces DMA based on its implementation of where to start DMA from.
> > > This also gives the ability to maintain current config as MMIO for backward compatibility.
> > > > > > 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.
> > > There are too many queues whose debugging is needed and MMIO likely not the way to debug.
> > > > 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.
> > >   From implementation POV it is certainly critical and good step forward to optimize virtio interface.
> > > > 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.
> > > For hash and rss config, debugging is missing. :)
> > > Yes, we can drop the GET after switching supported_tunnels to struct virtio_net_hash_config.
> > Great! Glad to hear this!
> >
> > > > 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.
> > > struct virtio_net_hash_config reserved is fine.
> > +1.
> >
> > Inner header hash is orthogonal to RSS, and it's fine to have its own
> > structure and commands.
> > There is no need to send additional RSS fields when we configure inner
> > header hash.
> >
> > Thanks.
> Not RSS, hash calculations. It's not critical, but I note that
> practically you said you will enable this with symmetric hash
> so it makes sense to me to send this in the same command

This works for me.

Thanks.

> with the key.
>
> Not critical though if there's opposition.