[DTrace-devel] [PATCH 1/5] udp: new provider

[Alan Maguire]

On 28/08/2025 18:56, Eugene Loh wrote:
> FWIW, we should have the "cg: fix offset for > 8 bit bitfields in
> dt_cg_ctf_offsetof()" patch land before this patch series does.
> 
> Anyhow, testing x86 and arm for OL8/UEK6 OL8/UEK7 OL9/UEK7 OL9/UEK8
> OL10/UEK8, I get
>     test/unittest/udp/tst.ipv6localudp.sh: FAIL: expected results differ.
> for
>     x86/OL8/UEK7
>     x86/OL9/UEK7
>     x86/OL9/UEK8
>     x86/OL10/UEK8
>     arm/OL10/UEK8
> If you like, I can investigate more or report more details.  I just
> didn't want to dive in too deep without checking in with you first.
> 

Thanks for the additional analysis on these in later messages! I think
given that udp[6]_queue_rcv_skb are static - and hence can wind up with
"." suffixes and not be fprobe-able - it's probably best to convert all
probe points to use rawfbt here.

> I do not know how documentation will be handled, but it's possible we
> will start to see that become part of this repo, in which perhaps new
> providers need to be accompanied by doc updates.  But I guess that will
> be the burden of whichever patch comes second.
> 
> Why is the module for these probes "vmlinux" when not all the underlying
> probes are?
>    ID   PROVIDER       MODULE                FUNCTION NAME
> 75616        fbt      vmlinux       udp_queue_rcv_skb entry
> 78708        fbt         ipv6     udpv6_queue_rcv_skb entry
> 74498        fbt      vmlinux             ip_send_skb entry
> 77968        fbt         ipv6            ip6_send_skb entry
> 

It depends whether CONFIG_IPV6=y or CONFIG_IPV6=m I think; not sure how
to reflect that dynamically in dt_sdt_populate() tho.

> I do not understand why the arg5 trick is needed, but I trust you!
>

It originated in the TCP provider, where checking outbound/inbound was
more efficient than a string comparison on probe name, especially where
there were multiple inbound probes like receive, accept-established etc.


> On 8/22/25 14:16, Alan Maguire via DTrace-devel wrote:
>> Based upon fbt probes support UDP send, receive.
> 
> To me, this would read more clearly if it were "Support UDP send and
> receive, using fbt probes."

Sure, will change. I'll also squash some of the patches as you suggest.