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

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

在 2023/6/29 下午7:48, Michael S. Tsirkin 写道:
> On Thu, Jun 29, 2023 at 10:05:09AM +0800, Heng Qi wrote:
>>
>> 在 2023/6/29 上午9:56, Parav Pandit 写道:
>>>> From: Michael S. Tsirkin <mst@redhat.com>
>>>> Sent: Wednesday, June 28, 2023 3:45 PM
>>>>>> Maybe I get it. You want to use the new features as a carrot to
>>>>>> force drivers to implement DMA? You suspect they will ignore the
>>>>>> spec requirement just because things seem to work?
>>>>>>
>>>>> Right because it is not a must normative.
>>>> Well SHOULD also does not mean "ok to just ignore".
>>>>
>>>> 	This word, or the adjective "RECOMMENDED", mean that there
>>>> 	   may exist valid reasons in particular circumstances to ignore a
>>>> 	   particular item, but the full implications must be understood and
>>>> 	   carefully weighed before choosing a different course.
>>>>
>>> RECOMMENDED and SHOULD forces the device to support MMIO, which is not good.
>>> So rather a good design is device tells the starting offset for the extended config space.
>>> And extended config space MUST be accessed using a DMA.
>>> With this sw can have infinite size MMIO and hw device forces DMA based on its implementation of where to start DMA from.
>>> This also gives the ability to maintain current config as MMIO for backward compatibility.
>>>>>> There's some logic here, for sure. you just might be right.
>>>>>>
>>>>>> However, surely we can discuss this small tweak in 1.4 timeframe?
>>>>> Sure, if we prefer the DMA approach I don't have a problem in adding
>>>> temporary one field to config space.
>>>>> I propose to add a line to the spec " Device Configuration Space"
>>>>> section, something like,
>>>>>
>>>>> Note: Any new device configuration space fields additional MUST consider
>>>> accessing such fields via a DMA interface.
>>>>> And this will guide the new patches of what to do instead of last moment
>>>> rush.
>>>>
>>>> Yea, except again I'd probably make it a SHOULD: e.g. I can see how switching to
>>>> MMIO might be an option for qemu helping us debug DMA issues.
>>>>
>>> There are too many queues whose debugging is needed and MMIO likely not the way to debug.
>>>> The time to discuss this detail would be around when proposal for the DMA
>>>> access to config space is on list though: I feel this SHOULD vs MUST is a small
>>>> enough detail.
>>>>
>>>   From implementation POV it is certainly critical and good step forward to optimize virtio interface.
>>>> Going back to inner hash. If we move supported_tunnels back to config space,
>>>> do you feel we still need GET or just drop it? I note we do not have GET for
>>>> either hash or rss config.
>>>>
>>> For hash and rss config, debugging is missing. :)
>>> Yes, we can drop the GET after switching supported_tunnels to struct virtio_net_hash_config.
>> Great! Glad to hear this!
>>
>>>> And if we no longer have GET is there still a reason for a separate command as
>>>> opposed to a field in virtio_net_hash_config?
>>>> I know this was done in v11 but there it was misaligned.
>>>> We went with a command because we needed it for supported_tunnels but
>>>> now that is no longer the case and there are reserved words in
>>>> virtio_net_hash_config ...
>>>>
>>>> Let me know how you feel it about that, not critical for me.
>>> struct virtio_net_hash_config reserved is fine.
>> +1.
>>
>> Inner header hash is orthogonal to RSS, and it's fine to have its own
>> structure and commands.
>> There is no need to send additional RSS fields when we configure inner
>> header hash.
>>
>> Thanks.
> Not RSS, hash calculations. It's not critical, but I note that
> practically you said you will enable this with symmetric hash
> so it makes sense to me to send this in the same command

This works for me.

Thanks.

> with the key.
>
> Not critical though if there's opposition.
>


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