All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kamil Zaripov <zaripov-kamil@avride.ai>
To: Stanislav Fomichev <sdf@google.com>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: Network RX per process per interface statistics
Date: Mon, 27 Mar 2023 17:19:50 +0300	[thread overview]
Message-ID: <C8C3B8DB-1CF1-4C51-91A1-6D4C6FEFD6D1@avride.ai> (raw)
In-Reply-To: <ZB4F7l0Nh2ZYwjci@google.com>

> 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?

  reply	other threads:[~2023-03-27 14:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-24 16:29 Network RX per process per interface statistics Kamil Zaripov
2023-03-24 20:19 ` Stanislav Fomichev
2023-03-27 14:19   ` Kamil Zaripov [this message]
2023-03-27 17:09     ` Stanislav Fomichev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C8C3B8DB-1CF1-4C51-91A1-6D4C6FEFD6D1@avride.ai \
    --to=zaripov-kamil@avride.ai \
    --cc=bpf@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sdf@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.