| Message ID | 20230919074915.103110-2-hengqi@linux.alibaba.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | virtio-net: Fix and update interrupt moderation | expand |
On Tue, Sep 19, 2023 at 3:49 PM Heng Qi <hengqi@linux.alibaba.com> wrote: > > Background: > 1. Commit 0c465be183c7 ("virtio_net: ethtool tx napi configuration") uses > tx-frames to toggle napi_tx (0 off and 1 on) if notification coalescing > is not supported. > 2. Commit 31c03aef9bc2 ("virtio_net: enable napi_tx by default") enables > napi_tx for all txqs by default. > > Status: > When virtio-net supports notification coalescing, after initialization, > tx-frames is 0 and napi_tx is true. > > Problem: > When the user only wants to set rx coalescing params using > ethtool -C eth0 rx-usecs 10, or > ethtool -Q eth0 queue_mask 0x1 -C rx-usecs 10, > these cmds will carry tx-frames as 0, causing the napi_tx switching condition > is satisfied. Then the user gets: > netlink error: Device or resource busy. > > The same happens when trying to set rx-frames, adaptive_rx, adaptive_tx... > > Result: It's probably not the result but how to fix it? > When notification coalescing feature is negotiated, initially make the > value of tx-frames to be consistent with napi_tx. > > For compatibility with the past, it is still supported to use tx-frames > to toggle napi_tx. > > Reported-by: Xiaoming Zhao <zxm377917@alibaba-inc.com> > Signed-off-by: Heng Qi <hengqi@linux.alibaba.com> > --- > drivers/net/virtio_net.c | 42 +++++++++++++++++++++++++++++++++------- > 1 file changed, 35 insertions(+), 7 deletions(-) > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > index fe7f314d65c9..fd5bc8d59eda 100644 > --- a/drivers/net/virtio_net.c > +++ b/drivers/net/virtio_net.c > @@ -4442,13 +4442,6 @@ static int virtnet_probe(struct virtio_device *vdev) > dev->xdp_features |= NETDEV_XDP_ACT_RX_SG; > } > > - if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_NOTF_COAL)) { > - vi->intr_coal_rx.max_usecs = 0; > - vi->intr_coal_tx.max_usecs = 0; > - vi->intr_coal_tx.max_packets = 0; > - vi->intr_coal_rx.max_packets = 0; > - } > - > if (virtio_has_feature(vdev, VIRTIO_NET_F_HASH_REPORT)) > vi->has_rss_hash_report = true; > > @@ -4523,6 +4516,41 @@ static int virtnet_probe(struct virtio_device *vdev) > if (err) > goto free; > > + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_NOTF_COAL)) { > + vi->intr_coal_rx.max_usecs = 0; > + vi->intr_coal_tx.max_usecs = 0; > + vi->intr_coal_rx.max_packets = 0; > + > + /* Why is this needed? > + * If without this setting, consider that when VIRTIO_NET_F_NOTF_COAL is > + * negotiated and napi_tx is initially true: when the user sets non tx-frames > + * parameters, such as the following cmd or others, > + * ethtool -C eth0 rx-usecs 10. > + * Then > + * 1. ethtool_set_coalesce() first calls virtnet_get_coalesce() to get > + * the last parameters except rx-usecs. If tx-frames has never been set before, > + * virtnet_get_coalesce() returns with tx-frames=0 in the parameters. > + * 2. virtnet_set_coalesce() is then called, according to 1: > + * ec->tx_max_coalesced_frames=0. Now napi_tx switching condition is met. > + * 3. If the device is up, the user setting fails: > + * "netlink error: Device or resource busy" > + * This is not intuitive. Therefore, we keep napi_tx state consistent with > + * tx-frames when VIRTIO_NET_F_NOTF_COAL is negotiated. This behavior is > + * compatible with before. > + */ Maybe it's sufficient to say it tries to align the behaviour with that tx NAPI is enabled by default? Other than these minor issues: Acked-by: Jason Wang <jasowang@redhat.com> Thanks > + if (vi->sq[0].napi.weight) > + vi->intr_coal_tx.max_packets = 1; > + else > + vi->intr_coal_tx.max_packets = 0; > + } > + > + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_VQ_NOTF_COAL)) { > + /* The reason is the same as VIRTIO_NET_F_NOTF_COAL. */ > + for (i = 0; i < vi->max_queue_pairs; i++) > + if (vi->sq[i].napi.weight) > + vi->sq[i].intr_coal.max_packets = 1; > + } > + > #ifdef CONFIG_SYSFS > if (vi->mergeable_rx_bufs) > dev->sysfs_rx_queue_group = &virtio_net_mrg_rx_group; > -- > 2.19.1.6.gb485710b >
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index fe7f314d65c9..fd5bc8d59eda 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -4442,13 +4442,6 @@ static int virtnet_probe(struct virtio_device *vdev) dev->xdp_features |= NETDEV_XDP_ACT_RX_SG; } - if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_NOTF_COAL)) { - vi->intr_coal_rx.max_usecs = 0; - vi->intr_coal_tx.max_usecs = 0; - vi->intr_coal_tx.max_packets = 0; - vi->intr_coal_rx.max_packets = 0; - } - if (virtio_has_feature(vdev, VIRTIO_NET_F_HASH_REPORT)) vi->has_rss_hash_report = true; @@ -4523,6 +4516,41 @@ static int virtnet_probe(struct virtio_device *vdev) if (err) goto free; + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_NOTF_COAL)) { + vi->intr_coal_rx.max_usecs = 0; + vi->intr_coal_tx.max_usecs = 0; + vi->intr_coal_rx.max_packets = 0; + + /* Why is this needed? + * If without this setting, consider that when VIRTIO_NET_F_NOTF_COAL is + * negotiated and napi_tx is initially true: when the user sets non tx-frames + * parameters, such as the following cmd or others, + * ethtool -C eth0 rx-usecs 10. + * Then + * 1. ethtool_set_coalesce() first calls virtnet_get_coalesce() to get + * the last parameters except rx-usecs. If tx-frames has never been set before, + * virtnet_get_coalesce() returns with tx-frames=0 in the parameters. + * 2. virtnet_set_coalesce() is then called, according to 1: + * ec->tx_max_coalesced_frames=0. Now napi_tx switching condition is met. + * 3. If the device is up, the user setting fails: + * "netlink error: Device or resource busy" + * This is not intuitive. Therefore, we keep napi_tx state consistent with + * tx-frames when VIRTIO_NET_F_NOTF_COAL is negotiated. This behavior is + * compatible with before. + */ + if (vi->sq[0].napi.weight) + vi->intr_coal_tx.max_packets = 1; + else + vi->intr_coal_tx.max_packets = 0; + } + + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_VQ_NOTF_COAL)) { + /* The reason is the same as VIRTIO_NET_F_NOTF_COAL. */ + for (i = 0; i < vi->max_queue_pairs; i++) + if (vi->sq[i].napi.weight) + vi->sq[i].intr_coal.max_packets = 1; + } + #ifdef CONFIG_SYSFS if (vi->mergeable_rx_bufs) dev->sysfs_rx_queue_group = &virtio_net_mrg_rx_group;
Background: 1. Commit 0c465be183c7 ("virtio_net: ethtool tx napi configuration") uses tx-frames to toggle napi_tx (0 off and 1 on) if notification coalescing is not supported. 2. Commit 31c03aef9bc2 ("virtio_net: enable napi_tx by default") enables napi_tx for all txqs by default. Status: When virtio-net supports notification coalescing, after initialization, tx-frames is 0 and napi_tx is true. Problem: When the user only wants to set rx coalescing params using ethtool -C eth0 rx-usecs 10, or ethtool -Q eth0 queue_mask 0x1 -C rx-usecs 10, these cmds will carry tx-frames as 0, causing the napi_tx switching condition is satisfied. Then the user gets: netlink error: Device or resource busy. The same happens when trying to set rx-frames, adaptive_rx, adaptive_tx... Result: When notification coalescing feature is negotiated, initially make the value of tx-frames to be consistent with napi_tx. For compatibility with the past, it is still supported to use tx-frames to toggle napi_tx. Reported-by: Xiaoming Zhao <zxm377917@alibaba-inc.com> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com> --- drivers/net/virtio_net.c | 42 +++++++++++++++++++++++++++++++++------- 1 file changed, 35 insertions(+), 7 deletions(-)