[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f15342fb-714b-32d9-ef95-07b2e13bbc9b@mojatatu.com>
Date: Thu, 17 Dec 2020 10:09:17 -0500
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Maxim Mikityanskiy <maximmi@...dia.com>,
Cong Wang <xiyou.wangcong@...il.com>
Cc: Maxim Mikityanskiy <maximmi@...lanox.com>,
"David S. Miller" <davem@...emloft.net>,
Jiri Pirko <jiri@...nulli.us>,
Saeed Mahameed <saeedm@...dia.com>,
Jakub Kicinski <kuba@...nel.org>,
Tariq Toukan <tariqt@...lanox.com>,
Dan Carpenter <dan.carpenter@...cle.com>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
Tariq Toukan <tariqt@...dia.com>,
Yossi Kuperman <yossiku@...dia.com>
Subject: Re: [PATCH net-next v2 2/4] sch_htb: Hierarchical QoS hardware
offload
On 2020-12-16 6:47 a.m., Maxim Mikityanskiy wrote:
> On 2020-12-15 18:37, Jamal Hadi Salim wrote:
[..]
>>
>> Same question above:
>> Is there a limit to the number of classes that can be created?
>
> Yes, the commit message of the mlx5 patch lists the limitations of our
> NICs. Basically, it's 256 leaf classes and 3 levels of hierarchy.
>
Ok, thats what i was looking for.
>> IOW, if someone just created an arbitrary number of queues do they
>> get errored-out if it doesnt make sense for the hardware?
>
> The current implementation starts failing gracefully if the limits are
> exceeded. The tc command won't succeed, and everything will roll back to
> the stable state, which was just before the tc command.
>
Does the user gets notified somehow or it fails silently?
An extack message would help.
>> If such limits exist, it may make sense to provide a knob to query
>> (maybe ethtool)
>
> Sounds legit, but I'm not sure what would be the best interface for
> that. Ethtool is not involved at all in this implementation, and AFAIK
> it doesn't contain any existing command for similar stuff. We could hook
> into set-channels and add new type of channels for HTB, but the
> semantics isn't very clear, because HTB queues != HTB leaf classes, and
> I don't know if it's allowed to extend this interface (if so, I have
> more thoughts of extending it for other purposes).
>
More looking to make sure no suprise to the user. Either the user can
discover what the constraints are or when they provision they get a
a message like "cannot offload more than 3 hierarchies" or "use devlink
if you want to use more than 256 classes", etc.
cheers,
jamal
Powered by blists - more mailing lists