[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <81d6fb01-e914-4c04-875a-58e61b433a80@app.fastmail.com>
Date: Fri, 16 May 2025 13:21:30 -0700
From: "Daniel Xu" <dxu@...uu.xyz>
To: "Willem de Bruijn" <willemdebruijn.kernel@...il.com>,
"Alexander Shalimov" <alex-shalimov@...dex-team.ru>
Cc: "Andrew Lunn" <andrew@...n.ch>, "David Miller" <davem@...emloft.net>,
"Eric Dumazet" <edumazet@...gle.com>,
"Jacob Keller" <jacob.e.keller@...el.com>, jasowang@...hat.com,
"Jakub Kicinski" <kuba@...nel.org>, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, "Paolo Abeni" <pabeni@...hat.com>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>
Subject: Re: [PATCH] net/tun: expose queue utilization stats via ethtool
On Fri, May 16, 2025, at 10:22 AM, Willem de Bruijn wrote:
> 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@...il.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.
Ah, right.
>
> 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.
Nice! Feel free to CC me if you have other stuff in the future.
Bug fix for parsing implicit module BTF up here:
https://github.com/bpftrace/bpftrace/pull/4137
Powered by blists - more mailing lists