From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: Heng Qi <hengqi@linux.alibaba.com>,
"virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
Jason Wang <jasowang@redhat.com>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Subject: Re: [virtio-comment] RE: [virtio-dev] RE: [virtio-comment] [PATCH v2] virtio-net: support setting coalescing params for multiple vqs
Date: Mon, 22 Jan 2024 02:36:19 -0500 [thread overview]
Message-ID: <20240122022002-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB5481E1A236C868B671275DCBDC752@PH0PR12MB5481.namprd12.prod.outlook.com>
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. 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
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.
So, here's my question: what exactly is the guest behaviour
that is driving this work? Is it with a linux guest? which
commands does userspace issue that we need to send multiple
vq coalescing commands? 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 ?
--
MST
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: Heng Qi <hengqi@linux.alibaba.com>,
"virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
Jason Wang <jasowang@redhat.com>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Subject: [virtio-dev] Re: [virtio-comment] RE: [virtio-dev] RE: [virtio-comment] [PATCH v2] virtio-net: support setting coalescing params for multiple vqs
Date: Mon, 22 Jan 2024 02:36:19 -0500 [thread overview]
Message-ID: <20240122022002-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB5481E1A236C868B671275DCBDC752@PH0PR12MB5481.namprd12.prod.outlook.com>
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. 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
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.
So, here's my question: what exactly is the guest behaviour
that is driving this work? Is it with a linux guest? which
commands does userspace issue that we need to send multiple
vq coalescing commands? 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 ?
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2024-01-22 7:36 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-15 13:06 [virtio-comment] [PATCH v2] virtio-net: support setting coalescing params for multiple vqs Heng Qi
2024-01-15 13:06 ` [virtio-dev] " Heng Qi
2024-01-15 13:21 ` [virtio-comment] " Parav Pandit
2024-01-15 13:21 ` [virtio-dev] " Parav Pandit
2024-01-17 4:52 ` [virtio-comment] " Heng Qi
2024-01-17 4:52 ` Heng Qi
2024-01-20 9:59 ` [virtio-comment] " Parav Pandit
2024-01-20 9:59 ` Parav Pandit
2024-01-22 2:57 ` [virtio-comment] " Heng Qi
2024-01-22 2:57 ` [virtio-dev] " Heng Qi
2024-01-22 5:03 ` Parav Pandit
2024-01-22 5:03 ` [virtio-dev] " Parav Pandit
2024-01-22 7:36 ` Michael S. Tsirkin [this message]
2024-01-22 7:36 ` [virtio-dev] " Michael S. Tsirkin
2024-01-23 5:55 ` Parav Pandit
2024-01-23 5:55 ` [virtio-dev] " Parav Pandit
2024-01-23 7:15 ` Michael S. Tsirkin
2024-01-23 7:15 ` [virtio-dev] " Michael S. Tsirkin
2024-01-23 7:28 ` Parav Pandit
2024-01-23 7:28 ` [virtio-dev] " Parav Pandit
2024-01-24 2:43 ` [virtio-comment] Re: [virtio-dev] " Heng Qi
2024-01-24 2:43 ` Heng Qi
2024-01-24 13:01 ` [virtio-comment] Re: [virtio-dev] " Heng Qi
2024-01-24 13:01 ` Heng Qi
2024-01-24 13:18 ` [virtio-comment] " Parav Pandit
2024-01-24 13:18 ` Parav Pandit
2024-01-25 3:05 ` [virtio-comment] " Heng Qi
2024-01-25 3:05 ` [virtio-dev] " Heng Qi
2024-01-25 3:51 ` Jason Wang
2024-01-25 3:51 ` [virtio-dev] " Jason Wang
2024-01-15 22:58 ` [virtio-comment] " Michael S. Tsirkin
2024-01-15 22:58 ` [virtio-dev] " Michael S. Tsirkin
2024-01-17 8:53 ` [virtio-comment] " Heng Qi
2024-01-17 8:53 ` Heng Qi
2024-01-24 10:50 ` [virtio-comment] " Michael S. Tsirkin
2024-01-24 10:50 ` [virtio-dev] " Michael S. Tsirkin
2024-01-24 10:52 ` [virtio-comment] " Michael S. Tsirkin
2024-01-24 10:52 ` [virtio-dev] " Michael S. Tsirkin
2024-01-25 2:33 ` [virtio-comment] " Heng Qi
2024-01-25 2:33 ` [virtio-dev] " Heng Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240122022002-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=hengqi@linux.alibaba.com \
--cc=jasowang@redhat.com \
--cc=parav@nvidia.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.