On Thu, Jun 29, 2023 at 12:00 AM Parav Pandit <pa...@nvidia.com> wrote:
>
>
>
> > From: Jason Wang <jasow...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
