Fwd: [PATCH net-next 1/5] netlink: spec: add shaper YAML spec

Oops, I unintentionally dropped most recipients, re-adding them, sorry
for the duplicate.

On Tue, Jul 2, 2024 at 5:05 PM Jakub Kicinski [off-list ref] wrote:

On Tue, 02 Jul 2024 16:21:38 +0200 Paolo Abeni wrote:

quoted

quoted

I see, I had a look at patch 2 now.
But that's really "Andrew's use-case" it doesn't cover deletion, right?
Sorry that I don't have a perfect suggestion either but it seems like
a half-measure. It's a partial support for transactions. If we want
transactions we should group ops like nftables. Have normal ops (add,
delete, modify) and control ops (start, commit) which clone the entire
tree, then ops change it, and commit presents new tree to the device.

Yes, it does not cover deletion _and_ update/add/move within the same
atomic operation.

Still any configuration could be reached from default/initial state
with set(<possibly many shapers>). Additionally, given any arbitrary
configuration, the default/initial state could be restored with a
single delete(<possibly many handlers>).

From:

q0 -. RR \
q1 /      > SP
q2 -. RR /
q3 /

Call this C1

To:

q0 ------\
q1 -------> SP
q2 -. RR /
q3 /

Call this C2

You have to both delete an RR node, and set SP params on Q0 and Q1.

default -> C1:

./tools/net/ynl/cli.py --spec Documentation/netlink/specs/shaper.yaml \
   --do set --json '{ "ifindex":2, "shapers": [ \
                         { "parent": { "scope": "netdev"}, "handle": {
"scope": "detached", "id": 1 }, "priority": 1 },
                         { "parent": { "scope": "netdev"}, "handle": {
"scope": "detached", "id": 2 }, "priority": 2 },
                         { "parent": { "scope": "detached", "id":1},
"handle": { "scope": "queue", "id": 1 }, "weight": 1 },
                         { "parent": { "scope": "detached", "id":1},
"handle": { "scope": "queue", "id": 2 }, "weight": 2 },
                         { "parent": { "scope": "detached" "id":2},
"handle": { "scope": "queue", "id": 3 }, "weight": 1 },
                         { "parent": { "scope": "detached" "id":2},
"handle": { "scope": "queue", "id": 4 }, "weight": 2 }]}
C1 -> C2:

./tools/net/ynl/cli.py --spec Documentation/netlink/specs/shaper.yaml \
   --do delete --json '{ "ifindex":2, "handles": [ \
                         { "scope": "queue", "id": 1 },
                         { "scope": "queue", "id": 2 },
                         { "scope": "queue", "id": 3 },
                         { "scope": "queue", "id": 4 },
                         {  "scope": "detached", "id": 1 },
                         {  "scope": "detached", "id": 2 }]}

./tools/net/ynl/cli.py --spec Documentation/netlink/specs/shaper.yaml \
   --do set --json '{ "ifindex":2, "shapers": [ \
                         { "parent": { "scope": "netdev"}, "handle": {
"scope": "detached", "id": 1 }, "priority": 1 },
                         { "parent": { "scope": "netdev"}, "handle": {
"scope": "queue", "id": 1 }, "priority": 2 },
                         { "parent": { "scope": "netdev"}, "handle": {
"scope": "queue", "id": 2 }, "priorirty": 3 },
                         { "parent": { "scope": "detached" "id":1},
"handle": { "scope": "queue", "id": 3 }, "weight": 1 },
                         { "parent": { "scope": "detached" "id":1},
"handle": { "scope": "queue", "id": 4 }, "weight": 2 },

The goal is to allow the system to reach the final configuration, even
with the assumption the H/W does not support any configuration except
the starting one and the final one.
But the infra requires that the system _must_ support at least a 3rd
configuration, the default one.

quoted

The above covers any possible limitation enforced by the H/W, not just
the DSA use-case.

Do you have a strong feeling for atomic transactions from any arbitrary
state towards any other? If so, I’d like to understand why?

I don't believe this is covers all cases.

Given any pair of configurations C1, C2 we can reach C2 via C1 ->
default, default -> C2. respecting any H/W constraint.

quoted

Dealing with transactions allowing arbitrary any state <> any state
atomic changes will involve some complex logic that seems better
assigned to user-space.

Complex logic in which part of the code?

IIRC in a past iteration you pointed out that the complexity of
computing the delta between 2 arbitrary configurations is
significantly higher than going through the empty/default
configuration.

In any case I think that the larger complexity to implement a full
transactional model. nft had proven that to be very hard and bug
prone. I really would avoid that option, if possible.

Thanks,

Paolo