[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <C8C3B8DB-1CF1-4C51-91A1-6D4C6FEFD6D1@avride.ai>
Date: Mon, 27 Mar 2023 17:19:50 +0300
From: Kamil Zaripov <zaripov-kamil@...ide.ai>
To: Stanislav Fomichev <sdf@...gle.com>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: Network RX per process per interface statistics
> By "modifies" - do you mean the payload/headers? You can probably use
> the skb pointer address as a unique identifier to connect across different
> tracepoints?
No, I mean when situations when same package through its way to the network stack change sk_buff pointer. For example, after skb_clone() call. I have made some test and found out (empirically) that pointer to the skb->head a much better tracking ID. However, I am not sure that there is no other corner cases when skb->head also can change.
> Nothing pops to my mind. But I think that if you store skbaddr=dev from
> netif_receive_skb, you should be able to look this up at a later point
> where you know skb->process association?
Yes, I have already implemented and make some test of this approach: I’m listening at netif_receive_skb tracepoint to create skb_head->netif map and then listening for __kfree_skb calls to create pid->skb_head map. However, this approach have some weaknesses:
- Part of packages of TCP protocol packages (ACK, for example) are handled by the kernel, so I account this packages as kernel activity. But almost every TCP ACK package have some associated socket, which, in turn, have associated process.
- I am not sure that all package consumes call __kfree_skb at the end. Maybe there is some other miscounting in this place.
Maybe there is some other approaches to map packages to processes?
Powered by blists - more mailing lists