Re: [virtio-dev] Re: [virtio-comment] RE: [virtio-dev] RE: [virtio-comment] [PATCH v2] virtio-net: support setting coalescing params for multiple vqs

在 2024/1/23 下午3:15, Michael S. Tsirkin 写道:
> On Tue, Jan 23, 2024 at 05:55:02AM +0000, Parav Pandit wrote:
>>> From: Michael S. Tsirkin <[email protected]>
>>> Sent: Monday, January 22, 2024 1:06 PM
>>>
>>> On Mon, Jan 22, 2024 at 05:03:38AM +0000, Parav Pandit wrote:
>>>>>>>> The right test on Linux to do without rtnl lock which is anyway
>>>>>>>> ugly and
>>>>>>> wrong semantic to use blocking the whole netdev stack.
>>>>>>>> (in case if you used that).
>>>>>>> Do you have any good directions and attempts to remove rtnl_lock?
>>>>>>>
>>>>>> I think per device lock instead of rtnl is first step that we can start with.
>>>> Wil check internally who if someone already started working on it.
>>> I feel the issue is at the conceptual level.
>> Not for requests which are initiated by the kernel stack (non user initiated).
> So how is this different? Is it basically just because
> tweaking coalescing in unexpected ways is considered mostly
> harmless?

DIM sends configurations frequently, which is try best.

>
>>> Yes some drivers will take a command
>>> and just queue it for execution later, but this means that errors can not be
>>> propagated back at all. Imagine device with mac
>>> 0x123 in promisc mode. Now commands:
>>>
>>> 1- program MAC 0xabcdef
>>> 2- disable promisc mode
>>>
>> User initiated commands error can be propagated when the command completes.
>> Enqueuing command is at the different bottom level in the driver.
>>
>>> If command 1 fails but 2 proceeds then packets with MAC 0xabc will be
>>> dropped.
>>>
>>> Any attempts to batch arbitrary commands will have this issue - be it at driver
>>> or device level.
>>>
>> There is no suggestion to batch arbitrary commands from the driver side.
>> The suggestion is to batch VQs notification coalescing from the driver side.
>>
>>> So, here's my question: what exactly is the guest behaviour that is driving this
>>> work? Is it with a linux guest?
>> At least looks to me yes based on the partial patches which are taking rtnl lock on netdim's worker callbacks.
>>
>>> which commands does userspace issue that we
>>> need to send multiple vq coalescing commands?
>> None.
>>
>>>   If all you want is to send
>>> same config to all VQs then why not just use
>>> VIRTIO_NET_CTRL_NOTF_COAL_RX_SET as opposed to
>>> VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET ?
>> Only kernel stack initiated VQ notification coalescing changes.
>> Since every VQ has different values, VIRTIO_NET_CTRL_NOTF_COAL_RX_SET is not sufficient.


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]