From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Paolo Abeni <pabeni@redhat.com>, netdev@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>
Subject: Re: [RFC PATCH 1/3] veth: implement support for set_channel ethtool op
Date: Fri, 09 Jul 2021 12:15:11 +0200 [thread overview]
Message-ID: <878s2fvln4.fsf@toke.dk> (raw)
In-Reply-To: <681c32be3a9172e9468893a89fb928b46c5c5ee6.1625823139.git.pabeni@redhat.com>
Paolo Abeni <pabeni@redhat.com> writes:
> This change implements the set_channel() ethtool operation,
> preserving the current defaults values and allowing up set
> the number of queues in the range set ad device creation
> time.
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> drivers/net/veth.c | 62 +++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 58 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index bdb7ce3cb054..10360228a06a 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -72,6 +72,8 @@ struct veth_priv {
> atomic64_t dropped;
> struct bpf_prog *_xdp_prog;
> struct veth_rq *rq;
> + unsigned int num_tx_queues;
> + unsigned int num_rx_queues;
Why are these needed to be duplicated? Don't they just duplicate the
'real_num_tx_queues' members in struct net_device?
> unsigned int requested_headroom;
> };
>
> @@ -224,10 +226,49 @@ static void veth_get_channels(struct net_device *dev,
> {
> channels->tx_count = dev->real_num_tx_queues;
> channels->rx_count = dev->real_num_rx_queues;
> - channels->max_tx = dev->real_num_tx_queues;
> - channels->max_rx = dev->real_num_rx_queues;
> + channels->max_tx = dev->num_tx_queues;
> + channels->max_rx = dev->num_rx_queues;
> channels->combined_count = min(dev->real_num_rx_queues, dev->real_num_tx_queues);
> - channels->max_combined = min(dev->real_num_rx_queues, dev->real_num_tx_queues);
> + channels->max_combined = min(dev->num_rx_queues, dev->num_tx_queues);
> +}
> +
> +static int veth_close(struct net_device *dev);
> +static int veth_open(struct net_device *dev);
> +
> +static int veth_set_channels(struct net_device *dev,
> + struct ethtool_channels *ch)
> +{
> + struct veth_priv *priv = netdev_priv(dev);
> + struct veth_priv *peer_priv;
> +
> + /* accept changes only on rx/tx */
> + if (ch->combined_count != min(dev->real_num_rx_queues, dev->real_num_tx_queues))
> + return -EINVAL;
> +
> + /* respect contraint posed at device creation time */
> + if (ch->rx_count > dev->num_rx_queues || ch->tx_count > dev->num_tx_queues)
> + return -EINVAL;
> +
> + if (!ch->rx_count || !ch->tx_count)
> + return -EINVAL;
> +
> + /* avoid braking XDP, if that is enabled */
> + if (priv->_xdp_prog && ch->rx_count < priv->peer->real_num_tx_queues)
> + return -EINVAL;
> +
> + peer_priv = netdev_priv(priv->peer);
> + if (peer_priv->_xdp_prog && ch->tx_count > priv->peer->real_num_rx_queues)
> + return -EINVAL;
An XDP program could be loaded later, so I think it's better to enforce
this constraint unconditionally.
(What happens on the regular xmit path if the number of TX queues is out
of sync with the peer RX queues, BTW?)
> + if (netif_running(dev))
> + veth_close(dev);
> +
> + priv->num_tx_queues = ch->tx_count;
> + priv->num_rx_queues = ch->rx_count;
Why can't just you use netif_set_real_num_*_queues() here directly (and
get rid of the priv members as above)?
-Toke
next prev parent reply other threads:[~2021-07-09 10:15 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-09 9:39 [RFC PATCH 0/3] veth: more flexible channels number configuration Paolo Abeni
2021-07-09 9:39 ` [RFC PATCH 1/3] veth: implement support for set_channel ethtool op Paolo Abeni
2021-07-09 10:15 ` Toke Høiland-Jørgensen [this message]
2021-07-09 10:49 ` Paolo Abeni
2021-07-09 11:36 ` Toke Høiland-Jørgensen
2021-07-09 14:38 ` Paolo Abeni
2021-07-09 15:23 ` Toke Høiland-Jørgensen
2021-07-09 16:35 ` Paolo Abeni
2021-07-09 19:56 ` Jakub Kicinski
2021-07-09 19:54 ` Jakub Kicinski
2021-07-12 1:44 ` David Ahern
2021-07-12 10:45 ` Paolo Abeni
2021-07-12 15:23 ` Jakub Kicinski
2021-07-10 8:43 ` kernel test robot
2021-07-09 9:39 ` [RFC PATCH 2/3] veth: make queues nr configurable via kernel module params Paolo Abeni
2021-07-09 10:24 ` Toke Høiland-Jørgensen
2021-07-09 15:33 ` Paolo Abeni
2021-07-09 16:12 ` Toke Høiland-Jørgensen
2021-07-09 14:25 ` kernel test robot
2021-07-09 16:59 ` kernel test robot
2021-07-10 17:52 ` kernel test robot
2021-07-10 17:52 ` [RFC PATCH] veth: veth_get_num_tx_queues() can be static kernel test robot
2021-07-09 9:39 ` [RFC PATCH 3/3] selftests: net: veth: add tests for set_channel Paolo Abeni
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=878s2fvln4.fsf@toke.dk \
--to=toke@redhat.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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.