Re: [PATCH] net/tun: expose queue utilization stats via ethtool

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Daniel Xu wrote:
> On Thu, May 15, 2025, at 7:12 AM, Willem de Bruijn wrote:
> > Alexander Shalimov wrote:
> >> 06.05.2025, 22:32, "Willem de Bruijn" <willemdebruijn.kernel@gmail.com>:
> >> > Perhaps bpftrace with a kfunc at a suitable function entry point to
> >> > get access to these ring structures.
> >> 
> >> Thank you for your responses!
> >> 
> >> Initially, we implemented such monitoring using bpftrace but we were
> >> not satisfied with the need to double-check the structure definitions
> >> in tun.c for each new kernel version.
> >> 
> >> We attached kprobe to the "tun_net_xmit()" function. This function
> >> gets a "struct net_device" as an argument, which is then explicitly
> >> cast to a tun_struct - "struct tun_struct *tun = netdev_priv(dev)".
> >> However, performing such a cast within bpftrace is difficult because
> >> tun_struct is defined in tun.c - meaning the structure definition
> >> cannot be included directly (not a header file). As a result, we were
> >> forced to add fake "struct tun_struct" and "struct tun_file"
> >> definitions, whose maintenance across kernel versions became
> >> cumbersome (see below). The same problems exists even with kfunc and
> >> btf - we are not able to cast properly netdev to tun_struct.
> >> 
> >> That’s why we decided to add this functionality directly to the kernel.
> >
> > Let's solve this in bpftrace instead. That's no reason to rever to
> > hardcoded kernel APIs.
> >
> > It quite possibly already is. I'm no bpftrace expert. Cc:ing bpf@
> 
> Yeah, should be possible. You haven't needed to include header
> files to access type information available in BTF for a while now.
> This seems to work for me - mind giving this a try?
> 
> ```
> fentry:tun:tun_net_xmit {
>     $tun = (struct tun_struct *)args->dev->priv;
>     print($tun->numqueues);  // or whatever else you want
> }
> ```
> 
> fentry probes are better in general than kprobes if all you're doing
> is attaching to the entry of a function.
> 
> You could do the same with kprobes like this if you really want, though:
> 
> ```
> kprobe:tun:tun_net_xmit {
>     $dev = (struct net_device *)arg1;
>     $tun = (struct tun_struct *)$dev->priv;
>     print($tun->numqueues);  // or whatever else you want
> }
> ```
> 
> Although it looks like there's a bug when you omit the module name
> where bpftrace doesn't find the struct definition. I'll look into that.

Minor: unless tun is built-in.

Thanks a lot for your response, Daniel. Good to know that we can get
this information without kernel changes. And I learned something new
:) Replicated your examples.