[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <461c66428b411644e78ad5a9a44c47442c9b6edf.camel@intel.com>
Date: Thu, 04 Apr 2019 17:04:36 -0700
From: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
To: Vinicius Costa Gomes <vinicius.gomes@...el.com>,
intel-wired-lan@...ts.osuosl.org
Cc: netdev@...r.kernel.org,
Bhagath Singh Karunakaran <bhagath@...ycito.com>
Subject: Re: [next-queue PATCH v1] igb: Fix limiting the number of queues to
number of cpus
On Thu, 2019-04-04 at 14:56 -0700, Vinicius Costa Gomes wrote:
> We have seen some reports[1] of users complaining that they aren't
> able to use some queues when their machines have less than 4 cpus.
> This affects some TSN workloads, as different traffic classes are
> assigned different queues. The current behavior limits the number of
> traffic classes that can be reliably handled.
>
> In practice, what is not working, it returns an invalid parameter
> error, in hosts with less than 4 cpus is something like this:
>
> $ tc qdisc replace dev IFACE parent root mqprio \
> num_tc 3 map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \
> queues 1@0 1@1 2@2 hw 0
>
> Because changing the default logic of the allocation of queues could
> bring other effects, we propose adding a module parameter so expert
> users may override that decision.
>
> [1] https://github.com/jeez/iproute2/issues/1
>
> Reported-by: Bhagath Singh Karunakaran <bhagath@...ycito.com>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@...el.com>
> ---
>
> A similar fix should also be needed for igc, even if I don't have the
> hardware to test, I can produce a patch, if others are able to test.
>
> I am not totally sure that using a module parameter is the best
> solution, so, suggestions are welcome.
>
> drivers/net/ethernet/intel/igb/igb_main.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
A module parameter maybe fine for our out-of-tree driver, but not for the
kernel driver.
NACK on the basis that a new module parameter is being introduced for the
driver. This is not acceptable by Dave Miller or myself. As of now, I do
not have a alternative solution to propose unfortunately.
I will discuss the issue with my fellow developers and hopefully we can
come up with a kernel interface that all drivers can use to handle this
issue.
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists