[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y9qCejI/C13dQsuK@corigine.com>
Date: Wed, 1 Feb 2023 16:17:14 +0100
From: Simon Horman <simon.horman@...igine.com>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Claudiu Manoil <claudiu.manoil@....com>,
Vinicius Costa Gomes <vinicius.gomes@...el.com>,
Kurt Kanzenbach <kurt@...utronix.de>,
Jacob Keller <jacob.e.keller@...el.com>,
Jamal Hadi Salim <jhs@...atatu.com>,
Cong Wang <xiyou.wangcong@...il.com>,
Jiri Pirko <jiri@...nulli.us>
Subject: Re: [PATCH v4 net-next 14/15] net/sched: taprio: mask off bits in
gate mask that exceed number of TCs
On Mon, Jan 30, 2023 at 07:31:44PM +0200, Vladimir Oltean wrote:
> "man tc-taprio" says:
>
> | each gate state allows outgoing traffic for a subset (potentially
> | empty) of traffic classes.
>
> So it makes sense to not allow gate actions to have bits set for traffic
> classes that exceed the number of TCs of the device (according to the
> mqprio configuration).
>
> Validating precisely that would risk introducing breakage in commands
> that worked (because taprio ignores the upper bits). OTOH, the user may
> not immediately realize that taprio ignores the upper bits (may confuse
> the gate mask to be per TXQ rather than per TC). So at least warn to
> dmesg, mask off the excess bits and continue.
>
> For this patch to work, we need to move the assignment of the mqprio
> queue configuration to the netdev above the parse_taprio_schedule()
> call, because we make use of netdev_get_num_tc().
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
> Reviewed-by: Jacob Keller <jacob.e.keller@...el.com>
Reviewed-by: Simon Horman <simon.horman@...igine.com>
Powered by blists - more mailing lists