Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: implement egress tbf qdisc for 6393x family

[Alexis Lothoré]

Hi Sunil,

On 6/12/23 08:34, Sunil Kovvuri wrote:
> 
> 
> On Fri, Jun 9, 2023 at 11:08 PM Alexis Lothoré <alexis.lothore@xxxxxxxxxxx
> <mailto:alexis.lothore@xxxxxxxxxxx>> wrote:
> 
>     On 6/9/23 19:16, Andrew Lunn wrote:
>     >> Yes, I can do that (or maybe -EINVAL to match Vladimir's comment ?). I think
>     >> it's worth mentioning that I encountered an issue regarding those values
>     during
>     >> tests: I use tc program to set the tbf, and I observed that tc does not even
>     >> reach kernel to set the qdisc if we pass no burst/latency value OR if we
>     set it
>     >> to 0. So tc enforces right on userspace side non-zero value for those
>     >> parameters, and I have passed random values and ignored them on kernel side.
>     >
>     > That is not good. Please take a look around and see if any other
>     > driver offloads TBF, and what they do with burst.
>     >
>     >> Checking available doc about tc-tbf makes me feel like that indeed a TBF
>     qdisc
>     >> command without burst or latency value makes no sense, except my use case can
>     >> not have such values. That's what I struggled a bit to find a proper qdisc to
>     >> match hardware cap. I may fallback to a custom netlink program to improve
>     testing.
>     >
>     > We don't really want a custom application, since we want users to use
>     > TC to set this up.
>     >
>     > Looking at the 6390 datasheet, Queue Counter Registers, mode 8 gives
>     > the number of egress buffers for a port. You could validate that the
>     > switch has at least the requested number of buffers assigned to the
>     > port? There is quite a bit you can configure, so maybe there is a way
>     > to influence the number of buffers, so you can actually implement the
>     > burst parameter?
> 
>     Thanks for the pointers. I will check the egress buffers configuration and see
>     if I can come up with something better
> 
> 
> For setting up simple per-port ratelimit, instead of TBF isn't "egress matchall"
> suitable here ?

I guess you are suggesting matchall + policer ? At first glance, I see no
obvious elements showing if one or another is more relevant. From user point of
view, controls are pretty much the same (rate + burst at least), but it looks
like policer is more of a pass/drop action, contrary to TBF which has some delay
notions, so it would solve the latency/limit absence of control. I am not sure
how it would look like on kernel side and how it would behave (how is managed
the filter, how can the policer be offloaded). I see some port_policer_add/del
callbacks in DSA, I will take a look at that as well and check differences with
TBF. Thanks for the suggestion.

Alexis
> 
> Thanks,
> Sunil. 

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com