在 2023/6/22 上午4:52, Parav Pandit 写道:
From: Michael S. Tsirkin <m...@redhat.com>
Sent: Wednesday, June 21, 2023 4:38 PM
And the field is RO so no memory cost to exposing it in all VFs.
Two structures do not bring the asymmetry.
Accessing current and enabled fields via two different mechanism is bringing
the asymmetry.
I guess it's a matter of taste, but it is clearly more consistent with other
hash
things, to which it's very similar.
This is consistent with new commands we define including notification
coalescing whose GET is not coming config space.
Yes.
Nah, config space is too convenient when we can live with its limitations. I
don't
thin kwe prefer not to keep growing it.
For some things such as this one it's perfect.
Fields are different between different devices.
For example, for migration driver might want to validate that two devices have
same capability. doing it without dma is nicer.
A migration driver for real world scenario, will almost have to use the dma for
amount of data it needs to exchange.
Another example, future admin transport will have ability to provision devices
by supplying their config space.
This will include this capability automatically, if instead we hide it in a
command
we need to do extra custom work.
So we do not prefer to keep growing the config space anymore, hence
GET is the right approach to me.
Heh I know you hate config space. Let it go, stop wasting time arguing about the
same thing on every turn and instead help define admin transport to solve it
This was discussed many times, a driver to have a direct (non-intercepted by
owner device) channel to device.
If you mean this non-intercepted channel as admin transport, fine.
If you mean this is intercepted and it is going over admin cmd, then it is of
no use for all future interfaces.
We discussed this in thread with you and Jason.
I provided concrete example with size and device provisioning math too and
other example of multi-physical address VQ.
So transporting register by register over some admin transport is sub-optimal.
Parav, your implementation prefers two separate struct versions and
doesn't let supported_hash_tunnel_types expand in configuration space. I
remember this.
I agree that we don't want to jump back and forth, especially as there
are practical reasons and 5 version jumps to get
supported_hash_tunnel_types back into the config space.
The original intention of Michael's proposal to merge structures in v18
should be that two separate structures will cause asynchrony.
I don't think so, the driver can cache enabled hash_tunnel_types every
SET command. Or after the SET command the driver *SHOULD* use the GET
command again, which is the workaround.
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
