Re: [PATCH net-next 1/2] net/sched: sch_fq_pie: add per-flow statistics via class ops

["Hemendra M. Naik" <hemendranaik@gmail.com>]

On Sun, 31 May 2026 15:41:49 -0700, Stephen Hemminger wrote:

> Sorry, you can't change the kernel/userspace ABI like this.
> How will old iproute2 handle new kernel and vice/versa.
>
> The better safer way to do this is to either extend the
> existing structure and have iproute2 know how how to handle
> short (missing) class data; or use another netlink
> type for class data.

Hello Stephen,

Apologies for breaking the ABI.

We've been working on two fixes along the lines of what you suggested.

Approach #1

Append type and the union after the original 9 fields rather than
inserting them at the front:

struct tc_fq_pie_xstats {
__u32 packets_in;       /* offset  0, untouched */
...
__u32 memory_usage;     /* offset 32, untouched */
__u32 type;             /* offset 36, new */

```
      union {
              struct tc_fq_pie_cl_stats  class_stats;
              struct tc_fq_pie_xqd_stats xqdisc_stats;
      };
```

};

tc_fq_pie_xqd_stats is currently empty. It acts as a placeholder for
future qdisc stats if needed.

With this layout, older iproute2 versions receiving the new 64-byte
blob still see RTA_PAYLOAD(64) >= sizeof(36) and read the original
fields correctly since offsets 0-35 remain unchanged.

Conversely, newer iproute2 versions receiving the old 36-byte blob
take the memcpy path into a zeroed local struct, type defaults to 0
(QDISC), and execution falls back to the qdisc stats path.

Approach #2

Leave struct tc_fq_pie_xstats unchanged and export class stats
separately as an NLA blob via gnet_stats_copy_app():

enum {
TCA_FQ_PIE_XSTATS_UNSPEC,
TCA_FQ_PIE_XSTATS_TYPE,
TCA_FQ_PIE_XSTATS_CL_PROB,
TCA_FQ_PIE_XSTATS_CL_DELAY,
TCA_FQ_PIE_XSTATS_CL_AVG_DQ_RATE,
...
};

Adding any new stat, class or qdisc, is just a new enum entry and one
nla_put() call. Old iproute2 sees an unknown TYPE and skips it
gracefully via the default case. No struct versioning, no size math.

Let us know which approach you'd prefer, or if there's another
approach you think would work better, and we'll send a revised patch
accordingly.

Thanks,
Hemendra