tools: ynl: add a sample for TC

Add a very simple TC dump sample with decoding of fq_codel attrs:

# ./tools/net/ynl/samples/tc
dummy0: fq_codel limit: 10240p target: 5ms new_flow_cnt: 0

tools: ynl: add a sample for TC

Add a very simple TC dump sample with decoding of fq_codel attrs:

# ./tools/net/ynl/samples/tc
dummy0: fq_codel limit: 10240p target: 5ms new_flow_cnt: 0

proving that selector passing (for stats) works.

Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Link: https://patch.msgid.link/20250520161916.413298-13-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

show more ...

tools: ynl: add a sample for rt-link

Add a fairly complete example of rt-link usage. If run without any
arguments it simply lists the interfaces and some of their attrs.
If run with an arg it tries

tools: ynl: add a sample for rt-link

Add a fairly complete example of rt-link usage. If run without any
arguments it simply lists the interfaces and some of their attrs.
If run with an arg it tries to create and delete a netkit device.

1 # ./tools/net/ynl/samples/rt-link 1
2 Trying to create a Netkit interface
3 Testing error message for policy being bad:
4 Kernel error: 'Provided default xmit policy not supported' (bad attribute: .linkinfo.data(netkit).policy)
5 1: lo: mtu 65536
6 2: wlp0s1: mtu 1500
7 3: enp0s13: mtu 1500
8 4: dummy0: mtu 1500 kind dummy altname one two
9 5: nk0: mtu 1500 kind netkit primary 0 policy forward
10 6: nk1: mtu 1500 kind netkit primary 1 policy blackhole
11 Trying to delete a Netkit interface (ifindex 6)

Sample creates the device first, it sets an invalid value for a netkit
attribute to trigger reverse parsing. Line 4 shows the error with the
attribute path correctly generated by YNL.

Then sample fixes the bad attribute and re-issues the request, with
NLM_F_ECHO set. This flag causes the notification to be looped back
to the initiating socket (our socket). Sample parses this notification
to save the ifindex of the created netkit.

Sample then proceeds to list the devices. Line 8 above shows a dummy
device with two alt names. Lines 9 and 10 show the netkit devices
the sample itself created.

The "primary" and "policy" attrs are from inside the netkit submsg.
The string values are auto-generated for the enums by YNL.

To clean up sample deletes the interface it created (line 11).

Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Link: https://patch.msgid.link/20250515231650.1325372-10-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

show more ...

tools: ynl-gen: move the count into a presence struct too

While we reshuffle the presence members, move the counts as well.
Previously array count members would have been place directly in
the struc

tools: ynl-gen: move the count into a presence struct too

While we reshuffle the presence members, move the counts as well.
Previously array count members would have been place directly in
the struct, so:

struct family_op_req {
struct {
u32 a:1;
u32 b:1;
} _present;
struct {
u32 bin;
} _len;

u32 a;
u64 b;
const unsigned char *bin;
u32 n_multi; << count
u32 *multi; << objects
};

Since len has been moved to its own presence struct move the count
as well:

struct family_op_req {
struct {
u32 a:1;
u32 b:1;
} _present;
struct {
u32 bin;
} _len;
struct {
u32 multi; << count
} _count;

u32 a;
u64 b;
const unsigned char *bin;
u32 *multi; << objects
};

This improves the consistency and allows us to remove some hacks
in the codegen. Unlike for len there is no known name collision
with the existing scheme.

Link: https://patch.msgid.link/20250505165208.248049-4-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

show more ...

tools: ynl-gen: split presence metadata

Each YNL struct contains the data and a sub-struct indicating which
fields are valid. Something like:

struct family_op_req {
struct {
u32

tools: ynl-gen: split presence metadata

Each YNL struct contains the data and a sub-struct indicating which
fields are valid. Something like:

struct family_op_req {
struct {
u32 a:1;
u32 b:1;
u32 bin_len;
} _present;

u32 a;
u64 b;
const unsigned char *bin;
};

Note that the bin object 'bin' has a length stored, and that length
has a _len suffix added to the field name. This breaks if there
is a explicit field called bin_len, which is the case for some
TC actions. Move the length fields out of the _present struct,
create a new struct called _len:

struct family_op_req {
struct {
u32 a:1;
u32 b:1;
} _present;
struct {
u32 bin;
} _len;

u32 a;
u64 b;
const unsigned char *bin;
};

This should prevent name collisions and help with the packing
of the struct.

Unfortunately this is a breaking change, but hopefully the migration
isn't too painful.

Link: https://patch.msgid.link/20250505165208.248049-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

show more ...

tools: ynl: generate code for rt-route and add a sample

YNL C can now generate code for simple classic netlink families.
Include rt-route in the Makefile for generation and add a sample.

$ ./to

tools: ynl: generate code for rt-route and add a sample

YNL C can now generate code for simple classic netlink families.
Include rt-route in the Makefile for generation and add a sample.

$ ./tools/net/ynl/samples/rt-route
oif: wlp0s20f3 gateway: 192.168.1.1
oif: wlp0s20f3 dst: 192.168.1.0/24
oif: vpn0 dst: fe80::/64
oif: wlp0s20f3 dst: fe80::/64
oif: wlp0s20f3 gateway: fe80::200:5eff:fe00:201

Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Link: https://patch.msgid.link/20250410014658.782120-14-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

show more ...

tools: ynl: generate code for rt-addr and add a sample

YNL C can now generate code for simple classic netlink families.
Include rt-addr in the Makefile for generation and add a sample.

$ ./tools/

tools: ynl: generate code for rt-addr and add a sample

YNL C can now generate code for simple classic netlink families.
Include rt-addr in the Makefile for generation and add a sample.

$ ./tools/net/ynl/samples/rt-addr
lo: 127.0.0.1
wlp0s20f3: 192.168.1.101
lo: ::
wlp0s20f3: fe80::6385:be6:746e:8116
vpn0: fe80::3597:d353:b5a7:66dd

Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Link: https://patch.msgid.link/20250410014658.782120-13-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

show more ...