All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>, netdev@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>
Subject: Re: [RFC PATCH 2/3] veth: make queues nr configurable via kernel module params
Date: Fri, 09 Jul 2021 17:33:00 +0200	[thread overview]
Message-ID: <e425920ed8120597a3a2c129c5a19fa1bc4854a2.camel@redhat.com> (raw)
In-Reply-To: <875yxjvl73.fsf@toke.dk>

On Fri, 2021-07-09 at 12:24 +0200, Toke Høiland-Jørgensen wrote:
> Paolo Abeni <pabeni@redhat.com> writes:
> 
> > This allows configuring the number of tx and rx queues at
> > module load time. A single module parameter controls
> > both the default number of RX and TX queues created
> > at device registration time.
> > 
> > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > ---
> >  drivers/net/veth.c | 21 +++++++++++++++++++++
> >  1 file changed, 21 insertions(+)
> > 
> > diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> > index 10360228a06a..787b4ad2cc87 100644
> > --- a/drivers/net/veth.c
> > +++ b/drivers/net/veth.c
> > @@ -27,6 +27,11 @@
> >  #include <linux/bpf_trace.h>
> >  #include <linux/net_tstamp.h>
> >  
> > +static int queues_nr	= 1;
> > +
> > +module_param(queues_nr, int, 0644);
> > +MODULE_PARM_DESC(queues_nr, "Max number of RX and TX queues (default = 1)");
> 
> Adding new module parameters is generally discouraged. Also, it's sort
> of a cumbersome API that you'll have to set this first, then re-create
> the device, and then use channels to get the number you want.
> 
> So why not just default to allocating num_possible_cpus() number of
> queues? Arguably that is the value that makes the most sense from a
> scalability point of view anyway, but if we're concerned about behaviour
> change (are we?), we could just default real_num_*_queues to 1, so that
> the extra queues have to be explicitly enabled by ethtool?

I was concerned by the amount of memory wasted memory (should be ~256
bytes per rx queue, ~320 per tx, plus the sysfs entries).

real_num_tx_queue > 1 will makes the xmit path slower, so we likely
want to keep that to 1 by default - unless the userspace explicitly set
numtxqueues via netlink.

Finally, a default large num_tx_queue slows down device creation:

cat << ENDL > run.sh
#!/bin/sh
MAX=$1
for I in `seq 1 $MAX`; do
	ip link add name v$I type veth peer name pv$I
done
for I in `seq 1 $MAX`; do
	ip link del dev v$I
done
ENDL
chmod a+x run.sh

# with num_tx_queue == 1
time ./run.sh 100 
real	0m2.276s
user	0m0.107s
sys	0m0.162s

# with num_tx_queue == 128
time ./run.sh 100 1
real	0m4.199s
user	0m0.091s
sys	0m1.419s

# with num_tx_queue == 4096
time ./run.sh 100 
real	0m24.519s
user	0m0.089s
sys	0m21.711s

Still, if there is agreement I can switch to num_possible_cpus default,
plus some trickery to keep real_num_{r,t}x_queue unchanged.

WDYT?

Thanks!

Paolo


  reply	other threads:[~2021-07-09 15:33 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
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 [this message]
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=e425920ed8120597a3a2c129c5a19fa1bc4854a2.camel@redhat.com \
    --to=pabeni@redhat.com \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=toke@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.