Re: Network RX per process per interface statistics

On 03/27, Kamil Zaripov wrote:

quoted

By "modifies" - do you mean the payload/headers? You can probably use
the skb pointer address as a unique identifier to connect across  

different

quoted

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.

Yeah, those are tricky :-(

quoted

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?

I'm not super familiar with those tracing hooks. Maybe you need to
handle consume_skb as well?

If I were to solve something like this, I'd probably look at cgroup/ingress
hooks. Those are guaranteed to run for every incoming packet into cgroup's
sockets. (at least removes that kfree_skb vs consume_skb issue).

But it doesn't solve your problem with the clones...