From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: xuanzhuo@linux.alibaba.com, netdev <netdev@vger.kernel.org>,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, eperezma@redhat.com,
edumazet@google.com, maxime.coquelin@redhat.com, kuba@kernel.org,
pabeni@redhat.com, david.marchand@redhat.com,
davem@davemloft.net
Subject: Re: [PATCH net-next V2 1/2] virtio-net: convert rx mode setting to use workqueue
Date: Fri, 14 Apr 2023 03:21:38 -0400 [thread overview]
Message-ID: <20230414031947-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CACGkMEunn1Z3n8yjVaWLqdV502yjaCBSAb_LO4KsB0nuxXmV8A@mail.gmail.com>
On Fri, Apr 14, 2023 at 01:04:15PM +0800, Jason Wang wrote:
> Forget to cc netdev, adding.
>
> On Fri, Apr 14, 2023 at 12:25 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Thu, Apr 13, 2023 at 02:40:26PM +0800, Jason Wang wrote:
> > > This patch convert rx mode setting to be done in a workqueue, this is
> > > a must for allow to sleep when waiting for the cvq command to
> > > response since current code is executed under addr spin lock.
> > >
> > > Signed-off-by: Jason Wang <jasowang@redhat.com>
> >
> > I don't like this frankly. This means that setting RX mode which would
> > previously be reliable, now becomes unreliable.
>
> It is "unreliable" by design:
>
> void (*ndo_set_rx_mode)(struct net_device *dev);
>
> > - first of all configuration is no longer immediate
>
> Is immediate a hard requirement? I can see a workqueue is used at least:
>
> mlx5e, ipoib, efx, ...
>
> > and there is no way for driver to find out when
> > it actually took effect
>
> But we know rx mode is best effort e.g it doesn't support vhost and we
> survive from this for years.
>
> > - second, if device fails command, this is also not
> > propagated to driver, again no way for driver to find out
> >
> > VDUSE needs to be fixed to do tricks to fix this
> > without breaking normal drivers.
>
> It's not specific to VDUSE. For example, when using virtio-net in the
> UP environment with any software cvq (like mlx5 via vDPA or cma
> transport).
>
> Thanks
Hmm. Can we differentiate between these use-cases?
> >
> >
> > > ---
> > > Changes since V1:
> > > - use RTNL to synchronize rx mode worker
> > > ---
> > > drivers/net/virtio_net.c | 55 +++++++++++++++++++++++++++++++++++++---
> > > 1 file changed, 52 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > index e2560b6f7980..2e56bbf86894 100644
> > > --- a/drivers/net/virtio_net.c
> > > +++ b/drivers/net/virtio_net.c
> > > @@ -265,6 +265,12 @@ struct virtnet_info {
> > > /* Work struct for config space updates */
> > > struct work_struct config_work;
> > >
> > > + /* Work struct for config rx mode */
> > > + struct work_struct rx_mode_work;
> > > +
> > > + /* Is rx mode work enabled? */
> > > + bool rx_mode_work_enabled;
> > > +
> > > /* Does the affinity hint is set for virtqueues? */
> > > bool affinity_hint_set;
> > >
> > > @@ -388,6 +394,20 @@ static void disable_delayed_refill(struct virtnet_info *vi)
> > > spin_unlock_bh(&vi->refill_lock);
> > > }
> > >
> > > +static void enable_rx_mode_work(struct virtnet_info *vi)
> > > +{
> > > + rtnl_lock();
> > > + vi->rx_mode_work_enabled = true;
> > > + rtnl_unlock();
> > > +}
> > > +
> > > +static void disable_rx_mode_work(struct virtnet_info *vi)
> > > +{
> > > + rtnl_lock();
> > > + vi->rx_mode_work_enabled = false;
> > > + rtnl_unlock();
> > > +}
> > > +
> > > static void virtqueue_napi_schedule(struct napi_struct *napi,
> > > struct virtqueue *vq)
> > > {
> > > @@ -2310,9 +2330,11 @@ static int virtnet_close(struct net_device *dev)
> > > return 0;
> > > }
> > >
> > > -static void virtnet_set_rx_mode(struct net_device *dev)
> > > +static void virtnet_rx_mode_work(struct work_struct *work)
> > > {
> > > - struct virtnet_info *vi = netdev_priv(dev);
> > > + struct virtnet_info *vi =
> > > + container_of(work, struct virtnet_info, rx_mode_work);
> > > + struct net_device *dev = vi->dev;
> > > struct scatterlist sg[2];
> > > struct virtio_net_ctrl_mac *mac_data;
> > > struct netdev_hw_addr *ha;
> > > @@ -2325,6 +2347,8 @@ static void virtnet_set_rx_mode(struct net_device *dev)
> > > if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_RX))
> > > return;
> > >
> > > + rtnl_lock();
> > > +
> > > vi->ctrl->promisc = ((dev->flags & IFF_PROMISC) != 0);
> > > vi->ctrl->allmulti = ((dev->flags & IFF_ALLMULTI) != 0);
> > >
> > > @@ -2342,14 +2366,19 @@ static void virtnet_set_rx_mode(struct net_device *dev)
> > > dev_warn(&dev->dev, "Failed to %sable allmulti mode.\n",
> > > vi->ctrl->allmulti ? "en" : "dis");
> > >
> > > + netif_addr_lock_bh(dev);
> > > +
> > > uc_count = netdev_uc_count(dev);
> > > mc_count = netdev_mc_count(dev);
> > > /* MAC filter - use one buffer for both lists */
> > > buf = kzalloc(((uc_count + mc_count) * ETH_ALEN) +
> > > (2 * sizeof(mac_data->entries)), GFP_ATOMIC);
> > > mac_data = buf;
> > > - if (!buf)
> > > + if (!buf) {
> > > + netif_addr_unlock_bh(dev);
> > > + rtnl_unlock();
> > > return;
> > > + }
> > >
> > > sg_init_table(sg, 2);
> > >
> > > @@ -2370,6 +2399,8 @@ static void virtnet_set_rx_mode(struct net_device *dev)
> > > netdev_for_each_mc_addr(ha, dev)
> > > memcpy(&mac_data->macs[i++][0], ha->addr, ETH_ALEN);
> > >
> > > + netif_addr_unlock_bh(dev);
> > > +
> > > sg_set_buf(&sg[1], mac_data,
> > > sizeof(mac_data->entries) + (mc_count * ETH_ALEN));
> > >
> > > @@ -2377,9 +2408,19 @@ static void virtnet_set_rx_mode(struct net_device *dev)
> > > VIRTIO_NET_CTRL_MAC_TABLE_SET, sg))
> > > dev_warn(&dev->dev, "Failed to set MAC filter table.\n");
> > >
> > > + rtnl_unlock();
> > > +
> > > kfree(buf);
> > > }
> > >
> > > +static void virtnet_set_rx_mode(struct net_device *dev)
> > > +{
> > > + struct virtnet_info *vi = netdev_priv(dev);
> > > +
> > > + if (vi->rx_mode_work_enabled)
> > > + schedule_work(&vi->rx_mode_work);
> > > +}
> > > +
> > > static int virtnet_vlan_rx_add_vid(struct net_device *dev,
> > > __be16 proto, u16 vid)
> > > {
> > > @@ -3150,6 +3191,8 @@ static void virtnet_freeze_down(struct virtio_device *vdev)
> > >
> > > /* Make sure no work handler is accessing the device */
> > > flush_work(&vi->config_work);
> > > + disable_rx_mode_work(vi);
> > > + flush_work(&vi->rx_mode_work);
> > >
> > > netif_tx_lock_bh(vi->dev);
> > > netif_device_detach(vi->dev);
> >
> > So now configuration is not propagated to device.
> > Won't device later wake up in wrong state?
> >
> >
> > > @@ -3172,6 +3215,7 @@ static int virtnet_restore_up(struct virtio_device *vdev)
> > > virtio_device_ready(vdev);
> > >
> > > enable_delayed_refill(vi);
> > > + enable_rx_mode_work(vi);
> > >
> > > if (netif_running(vi->dev)) {
> > > err = virtnet_open(vi->dev);
> > > @@ -3969,6 +4013,7 @@ static int virtnet_probe(struct virtio_device *vdev)
> > > vdev->priv = vi;
> > >
> > > INIT_WORK(&vi->config_work, virtnet_config_changed_work);
> > > + INIT_WORK(&vi->rx_mode_work, virtnet_rx_mode_work);
> > > spin_lock_init(&vi->refill_lock);
> > >
> > > if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF)) {
> > > @@ -4077,6 +4122,8 @@ static int virtnet_probe(struct virtio_device *vdev)
> > > if (vi->has_rss || vi->has_rss_hash_report)
> > > virtnet_init_default_rss(vi);
> > >
> > > + enable_rx_mode_work(vi);
> > > +
> > > /* serialize netdev register + virtio_device_ready() with ndo_open() */
> > > rtnl_lock();
> > >
> > > @@ -4174,6 +4221,8 @@ static void virtnet_remove(struct virtio_device *vdev)
> > >
> > > /* Make sure no work handler is accessing the device. */
> > > flush_work(&vi->config_work);
> > > + disable_rx_mode_work(vi);
> > > + flush_work(&vi->rx_mode_work);
> > >
> > > unregister_netdev(vi->dev);
> > >
> > > --
> > > 2.25.1
> >
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, virtualization@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, maxime.coquelin@redhat.com,
alvaro.karsz@solid-run.com, eperezma@redhat.com,
xuanzhuo@linux.alibaba.com, david.marchand@redhat.com,
netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next V2 1/2] virtio-net: convert rx mode setting to use workqueue
Date: Fri, 14 Apr 2023 03:21:38 -0400 [thread overview]
Message-ID: <20230414031947-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CACGkMEunn1Z3n8yjVaWLqdV502yjaCBSAb_LO4KsB0nuxXmV8A@mail.gmail.com>
On Fri, Apr 14, 2023 at 01:04:15PM +0800, Jason Wang wrote:
> Forget to cc netdev, adding.
>
> On Fri, Apr 14, 2023 at 12:25 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Thu, Apr 13, 2023 at 02:40:26PM +0800, Jason Wang wrote:
> > > This patch convert rx mode setting to be done in a workqueue, this is
> > > a must for allow to sleep when waiting for the cvq command to
> > > response since current code is executed under addr spin lock.
> > >
> > > Signed-off-by: Jason Wang <jasowang@redhat.com>
> >
> > I don't like this frankly. This means that setting RX mode which would
> > previously be reliable, now becomes unreliable.
>
> It is "unreliable" by design:
>
> void (*ndo_set_rx_mode)(struct net_device *dev);
>
> > - first of all configuration is no longer immediate
>
> Is immediate a hard requirement? I can see a workqueue is used at least:
>
> mlx5e, ipoib, efx, ...
>
> > and there is no way for driver to find out when
> > it actually took effect
>
> But we know rx mode is best effort e.g it doesn't support vhost and we
> survive from this for years.
>
> > - second, if device fails command, this is also not
> > propagated to driver, again no way for driver to find out
> >
> > VDUSE needs to be fixed to do tricks to fix this
> > without breaking normal drivers.
>
> It's not specific to VDUSE. For example, when using virtio-net in the
> UP environment with any software cvq (like mlx5 via vDPA or cma
> transport).
>
> Thanks
Hmm. Can we differentiate between these use-cases?
> >
> >
> > > ---
> > > Changes since V1:
> > > - use RTNL to synchronize rx mode worker
> > > ---
> > > drivers/net/virtio_net.c | 55 +++++++++++++++++++++++++++++++++++++---
> > > 1 file changed, 52 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > index e2560b6f7980..2e56bbf86894 100644
> > > --- a/drivers/net/virtio_net.c
> > > +++ b/drivers/net/virtio_net.c
> > > @@ -265,6 +265,12 @@ struct virtnet_info {
> > > /* Work struct for config space updates */
> > > struct work_struct config_work;
> > >
> > > + /* Work struct for config rx mode */
> > > + struct work_struct rx_mode_work;
> > > +
> > > + /* Is rx mode work enabled? */
> > > + bool rx_mode_work_enabled;
> > > +
> > > /* Does the affinity hint is set for virtqueues? */
> > > bool affinity_hint_set;
> > >
> > > @@ -388,6 +394,20 @@ static void disable_delayed_refill(struct virtnet_info *vi)
> > > spin_unlock_bh(&vi->refill_lock);
> > > }
> > >
> > > +static void enable_rx_mode_work(struct virtnet_info *vi)
> > > +{
> > > + rtnl_lock();
> > > + vi->rx_mode_work_enabled = true;
> > > + rtnl_unlock();
> > > +}
> > > +
> > > +static void disable_rx_mode_work(struct virtnet_info *vi)
> > > +{
> > > + rtnl_lock();
> > > + vi->rx_mode_work_enabled = false;
> > > + rtnl_unlock();
> > > +}
> > > +
> > > static void virtqueue_napi_schedule(struct napi_struct *napi,
> > > struct virtqueue *vq)
> > > {
> > > @@ -2310,9 +2330,11 @@ static int virtnet_close(struct net_device *dev)
> > > return 0;
> > > }
> > >
> > > -static void virtnet_set_rx_mode(struct net_device *dev)
> > > +static void virtnet_rx_mode_work(struct work_struct *work)
> > > {
> > > - struct virtnet_info *vi = netdev_priv(dev);
> > > + struct virtnet_info *vi =
> > > + container_of(work, struct virtnet_info, rx_mode_work);
> > > + struct net_device *dev = vi->dev;
> > > struct scatterlist sg[2];
> > > struct virtio_net_ctrl_mac *mac_data;
> > > struct netdev_hw_addr *ha;
> > > @@ -2325,6 +2347,8 @@ static void virtnet_set_rx_mode(struct net_device *dev)
> > > if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_RX))
> > > return;
> > >
> > > + rtnl_lock();
> > > +
> > > vi->ctrl->promisc = ((dev->flags & IFF_PROMISC) != 0);
> > > vi->ctrl->allmulti = ((dev->flags & IFF_ALLMULTI) != 0);
> > >
> > > @@ -2342,14 +2366,19 @@ static void virtnet_set_rx_mode(struct net_device *dev)
> > > dev_warn(&dev->dev, "Failed to %sable allmulti mode.\n",
> > > vi->ctrl->allmulti ? "en" : "dis");
> > >
> > > + netif_addr_lock_bh(dev);
> > > +
> > > uc_count = netdev_uc_count(dev);
> > > mc_count = netdev_mc_count(dev);
> > > /* MAC filter - use one buffer for both lists */
> > > buf = kzalloc(((uc_count + mc_count) * ETH_ALEN) +
> > > (2 * sizeof(mac_data->entries)), GFP_ATOMIC);
> > > mac_data = buf;
> > > - if (!buf)
> > > + if (!buf) {
> > > + netif_addr_unlock_bh(dev);
> > > + rtnl_unlock();
> > > return;
> > > + }
> > >
> > > sg_init_table(sg, 2);
> > >
> > > @@ -2370,6 +2399,8 @@ static void virtnet_set_rx_mode(struct net_device *dev)
> > > netdev_for_each_mc_addr(ha, dev)
> > > memcpy(&mac_data->macs[i++][0], ha->addr, ETH_ALEN);
> > >
> > > + netif_addr_unlock_bh(dev);
> > > +
> > > sg_set_buf(&sg[1], mac_data,
> > > sizeof(mac_data->entries) + (mc_count * ETH_ALEN));
> > >
> > > @@ -2377,9 +2408,19 @@ static void virtnet_set_rx_mode(struct net_device *dev)
> > > VIRTIO_NET_CTRL_MAC_TABLE_SET, sg))
> > > dev_warn(&dev->dev, "Failed to set MAC filter table.\n");
> > >
> > > + rtnl_unlock();
> > > +
> > > kfree(buf);
> > > }
> > >
> > > +static void virtnet_set_rx_mode(struct net_device *dev)
> > > +{
> > > + struct virtnet_info *vi = netdev_priv(dev);
> > > +
> > > + if (vi->rx_mode_work_enabled)
> > > + schedule_work(&vi->rx_mode_work);
> > > +}
> > > +
> > > static int virtnet_vlan_rx_add_vid(struct net_device *dev,
> > > __be16 proto, u16 vid)
> > > {
> > > @@ -3150,6 +3191,8 @@ static void virtnet_freeze_down(struct virtio_device *vdev)
> > >
> > > /* Make sure no work handler is accessing the device */
> > > flush_work(&vi->config_work);
> > > + disable_rx_mode_work(vi);
> > > + flush_work(&vi->rx_mode_work);
> > >
> > > netif_tx_lock_bh(vi->dev);
> > > netif_device_detach(vi->dev);
> >
> > So now configuration is not propagated to device.
> > Won't device later wake up in wrong state?
> >
> >
> > > @@ -3172,6 +3215,7 @@ static int virtnet_restore_up(struct virtio_device *vdev)
> > > virtio_device_ready(vdev);
> > >
> > > enable_delayed_refill(vi);
> > > + enable_rx_mode_work(vi);
> > >
> > > if (netif_running(vi->dev)) {
> > > err = virtnet_open(vi->dev);
> > > @@ -3969,6 +4013,7 @@ static int virtnet_probe(struct virtio_device *vdev)
> > > vdev->priv = vi;
> > >
> > > INIT_WORK(&vi->config_work, virtnet_config_changed_work);
> > > + INIT_WORK(&vi->rx_mode_work, virtnet_rx_mode_work);
> > > spin_lock_init(&vi->refill_lock);
> > >
> > > if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF)) {
> > > @@ -4077,6 +4122,8 @@ static int virtnet_probe(struct virtio_device *vdev)
> > > if (vi->has_rss || vi->has_rss_hash_report)
> > > virtnet_init_default_rss(vi);
> > >
> > > + enable_rx_mode_work(vi);
> > > +
> > > /* serialize netdev register + virtio_device_ready() with ndo_open() */
> > > rtnl_lock();
> > >
> > > @@ -4174,6 +4221,8 @@ static void virtnet_remove(struct virtio_device *vdev)
> > >
> > > /* Make sure no work handler is accessing the device. */
> > > flush_work(&vi->config_work);
> > > + disable_rx_mode_work(vi);
> > > + flush_work(&vi->rx_mode_work);
> > >
> > > unregister_netdev(vi->dev);
> > >
> > > --
> > > 2.25.1
> >
next prev parent reply other threads:[~2023-04-14 7:21 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-13 6:40 [PATCH net-next V2 0/2] virtio-net: don't busy poll for cvq command Jason Wang
2023-04-13 6:40 ` Jason Wang
2023-04-13 6:40 ` [PATCH net-next V2 1/2] virtio-net: convert rx mode setting to use workqueue Jason Wang
2023-04-13 6:40 ` Jason Wang
2023-04-13 16:25 ` Michael S. Tsirkin
2023-04-13 16:25 ` Michael S. Tsirkin
2023-04-14 5:04 ` Jason Wang
2023-04-14 5:04 ` Jason Wang
2023-04-14 7:21 ` Michael S. Tsirkin [this message]
2023-04-14 7:21 ` Michael S. Tsirkin
2023-04-17 3:40 ` Jason Wang
2023-04-17 3:40 ` Jason Wang
2023-05-05 3:46 ` Jason Wang
2023-05-05 3:46 ` Jason Wang
2023-05-10 5:32 ` Michael S. Tsirkin
2023-05-10 5:32 ` Michael S. Tsirkin
2023-05-15 1:05 ` Jason Wang
2023-05-15 1:05 ` Jason Wang
2023-05-15 4:45 ` Michael S. Tsirkin
2023-05-15 4:45 ` Michael S. Tsirkin
2023-05-15 5:13 ` Jason Wang
2023-05-15 5:13 ` Jason Wang
2023-05-15 10:17 ` Michael S. Tsirkin
2023-05-15 10:17 ` Michael S. Tsirkin
2023-05-16 2:44 ` Jason Wang
2023-05-16 2:44 ` Jason Wang
2023-05-16 4:12 ` Michael S. Tsirkin
2023-05-16 4:12 ` Michael S. Tsirkin
2023-05-16 4:17 ` Jason Wang
2023-05-16 4:17 ` Jason Wang
2023-05-16 5:56 ` Michael S. Tsirkin
2023-05-16 5:56 ` Michael S. Tsirkin
2023-05-16 19:36 ` Jakub Kicinski
2023-04-13 6:40 ` [PATCH net-next V2 2/2] virtio-net: sleep instead of busy waiting for cvq command Jason Wang
2023-04-13 6:40 ` Jason Wang
2023-04-13 7:27 ` Xuan Zhuo
2023-04-13 7:27 ` Xuan Zhuo
2023-04-14 5:09 ` Jason Wang
2023-04-14 5:09 ` Jason Wang
2023-04-14 5:10 ` Jason Wang
2023-04-14 5:10 ` Jason Wang
2023-05-16 20:54 ` Michael S. Tsirkin
2023-05-16 20:54 ` Michael S. Tsirkin
2023-05-17 0:50 ` Jason Wang
2023-05-17 0:50 ` Jason Wang
2023-04-13 13:02 ` [PATCH net-next V2 0/2] virtio-net: don't busy poll " Maxime Coquelin
2023-04-13 13:02 ` Maxime Coquelin
2023-04-13 13:05 ` Maxime Coquelin
2023-04-13 13:05 ` Maxime Coquelin
2023-04-13 14:04 ` Jakub Kicinski
2023-04-14 4:53 ` Jason Wang
2023-04-14 4:53 ` Jason Wang
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=20230414031947-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=davem@davemloft.net \
--cc=david.marchand@redhat.com \
--cc=edumazet@google.com \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.coquelin@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=virtualization@lists.linux-foundation.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.