Re: [PATCH net-next 00/12] Add tc-mqprio and tc-taprio support for preemptible traffic classes

Hi Vladimir!

Thank you for the update!

On Sun, 2023-02-19 at 14:58 +0200, Vladimir Oltean wrote:

Hi Ferenc,

On Sun, Feb 19, 2023 at 10:47:31AM +0100, Ferenc Fejes wrote:

quoted

Do you have the iproute2 part? Sorry if I missed it, but it would
be
nice to see how is that UAPI exposed for the config tools. Is there
any
new parameter for mqprio/taprio?

I haven't posted the iproute2 part (yet). For those familiar with my
recent development, FP is a per-traffic-class netlink attribute just
like queueMaxSDU from tc-taprio. That was exposed in iproute2 as an
array of values, one per tc.

What I have in my tree would allow something like this:

tc qdisc replace dev $swp1 root stab overhead 20 taprio \
        num_tc 8 \
        map 0 1 2 3 4 5 6 7 \
        queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \
        base-time 0 \
        sched-entry S 0x7e 900000 \
        sched-entry S 0x82 100000 \
        max-sdu 0 0 0 0 0 0 0 200 \
        fp P E E E E E E E \   # this is new (one entry per tc)
        flags 0x2

tc qdisc replace dev $swp1 root mqprio \
        num_tc 8 \
        map 0 1 2 3 4 5 6 7 \
        queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \
        fp P E E E E E E E \   # this is new (one entry per tc)
        hw 1

of course the exact syntax is a potential matter of debate on its
own,
and does not really matter for the purpose of defining the kernel
UAPI,
which is why I wanted to keep discussions separate.

Fair enough. What you have right here is pretty straightforward IMO, I
would definitely support something like this.

For hardware which understands preemptible queues rather than traffic
classes, how many queues are preemptible, and what are their offsets,
will be deduced by translating the "queues" argument.

For hardware which understands preemptible priorities rather than
traffic classes, which priorities are preemptible will be deduced by
translating the "map" argument.

Great, that cover both cases with the same UAPI. I love the fact that
this even lets open the possibility to use prio-s (map) instead of
queues for FP.

The traffic class is the kernel entity which has the preemptible
priority in my proposed UAPI because this is what my analysis of the
standard has deduced that the preemptible quality is fundamentally
attached to.

Considering that the UAPI for FP is a topic that has been discussed
to
death at least since August without any really new input since then,
I'm
going to submit v2 later today, and the iproute2 patch set afterwards
(still need to write man page entries for that).

Best,
Ferenc