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

[Parav Pandit <parav@nvidia.com>]

> From: Heng Qi <hengqi@linux.alibaba.com>
> Sent: Wednesday, June 21, 2023 8:59 PM

[..]
> > 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.
> 
Right.

> 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.
>
There is no need to perform GET after SET.
A driver-device contract is, is SET command returns success, it means device accepted the command and will apply the filter.
If device fails it, there is anyway error.

Later when if driver wants to modify the tunnel type (add/remove), 
a. either it can used previously read supported type (if cached in driver)
b. issue GET to know supported tunnel types (if not cached)
 
> Thanks.
> 
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org