Messages in this thread | | | Date | Mon, 12 Jun 2023 10:54:29 +0200 | Subject | Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: implement egress tbf qdisc for 6393x family | From | 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@bootlin.com > <mailto:alexis.lothore@bootlin.com>> 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
| |