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

[Jason Wang <jasowang@redhat.com>]

On Thu, Jun 29, 2023 at 12:00âAM Parav Pandit <parav@nvidia.com> wrote:
>
>
>
> > From: Jason Wang <jasowang@redhat.com>
> > Sent: Wednesday, June 28, 2023 1:38 AM
>
> [..]
> > > Provisioning is far simpler thing to do in device specific way than asking device
> > to store this value in onchip area which is rarely accessed.
> >
> > Are you suggesting to not place any new fields in the config space?
> >
> Yes.

It's not the fault of config space itself, but the way to access the
config space, more below.

>
> > 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
2) I was told my some vendors that the virtqueue is much more valuable than MMIO
3) We can introduce new ways to access the device configuration space

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

Thanks