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

[Heng Qi <hengqi@linux.alibaba.com>]

在 2023/6/22 上午4:52, Parav Pandit 写道:
>> From: Michael S. Tsirkin <mst@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-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org