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

[Parav Pandit <parav@nvidia.com>]

> From: virtio-dev@lists.oasis-open.org <virtio-dev@lists.oasis-open.org> On
> Behalf Of Jason Wang
> Sent: Wednesday, June 28, 2023 11:18 PM
> 
> It's not the fault of config space itself, but the way to access the config space,
> more below.
>
Sure and it is linked to old and new entries into it. I explained in this thread with discussion with Michael.
Please refer it.
 
> >
> > > struct virtio_net_config {
> > >         u8 mac[6];
> > >         le16 status;
> > >         le16 max_virtqueue_pairs;
> > >         le16 mtu;
> > >         le32 speed;
> > >         u8 duplex;
> > >         u8 rss_max_key_size;
> > >         le16 rss_max_indirection_table_length;
> > >         le32 supported_hash_types;
> > > };
> > >
> > > Which of the above do you think can be accessed frequently and which
> > > part of the spec says it must be stored in the onchip area?
> > >
> > Most are not accessed frequently.
> > The fact that they are in MMIO a device needs to place in a memory with tight
> latency budget.
> 
> This really depends on the implementation and vendor architectures.
> For example,
> 
> 1) MSI BAR might require much more resources than a simple device
> configuration space
Sure, that is also getting solved in parallel outside of virtio spec.
So MSI BAR saving is not replacement, it is different area that is getting optimized.

> 2) I was told my some vendors that the virtqueue is much more valuable than
> MMIO
Not sure I understand "valuable".

> 3) We can introduce new ways to access the device configuration space
>
Yes, new way for existing config space and extended (new fields) of config space.
I explained the reason to differentiate this few times in thread to Michael, so I will omit repeating here.
 
> > Spec is not going to talk on onchip area, it is the reflection of spec that forces
> certain inefficient implementation .
> 
> Exactly, it's implementation specific, so config space is fine, we just need to
> invent new methods to access them that fit for your hardware.

Yes. Lets work on it in the new thread.