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:

[..]

quoted

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.

quoted

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.

quoted

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