> From: Michael S. Tsirkin <m...@redhat.com> > 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).
> 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: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org