Re: [virtio-comment] Re: [PATCH v18] virtio-net: support inner header hash

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Jun 22, 2023 at 02:27:31PM +0000, Parav Pandit wrote:
> 
> 
> > From: Heng Qi <hengqi@linux.alibaba.com>
> > Sent: Thursday, June 22, 2023 9:43 AM
> > 
> > Yes, I think we also have to consider upcoming
> >  ÂÂÂ 1. device counters (e.g. supported_device_counter),
> >  ÂÂÂ 2. receive flow filters (e.g. supported_flow_types, supported_max_entries),
> >  ÂÂÂ 3. header splits (e.g. supported_split_types) etc.
> > Continuous expansion of the configuration space needs to be careful.
> > 
> > >
> > > Instead of decision point being RO vs RW, any new fields via cmdvq and
> > > existing fields stays in cfg space, give predictable behavior to size the member
> > devices in the system.
> > > Once the cmdvq is available, we can get rid of GET command used in this
> > version for new future features.
> > > Till that arrives, GET command is the efficient way.
> > 
> > Yes, I agree.
> > 
> > Thanks.
> 
> Right. So, Miachel main concern was two vs one struct.
> And given the GET and SET works on different fields, having two structure is just fine.
> The code is fairly small.
> I donât see any real issue here with v18.
> 

The hardware footprint of keeping this in memory is also fairly small :)
I care about a messy interface because this mess builds up over time.

And I am worried about capabilities really. My bad that I missed this
change in v13. I only can say in my defence that I already had
to rewrite huge chunks of this proposal to make it readable
so one can't say I'm only delaying things, I also made an effort
to help this progress faster :)

I feel we need a single place where device capabilities can live. So far
they were in config space.  It's consistent, yes I get this has hardware
costs *if* there's a huge number of VFs and *if* there's a way to
provision each VF with a different configuration.  And yes querying VFs
over MMIO is kind of ugly. But it does at least work, and works fine
while VF is assigned.  So we can build migration around that *today*.

But querying over cvq while VF is assigned clearly *doesn't* work.

So what is the solution proposed for this?

Yes the current migration is broken in many ways but that's what we
have. Let's build something better sure but that is not 1.3 material.

-- 
MST