All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yonghong Song <yonghong.song@linux.dev>
To: Michael Agun <danielagun@microsoft.com>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	"bpf@ietf.org" <bpf@ietf.org>
Subject: Re: perf_event_output payload capture flags?
Date: Fri, 26 Jul 2024 09:58:52 -0700	[thread overview]
Message-ID: <7ab6fbc6-2f05-4bb1-9596-855f276ab997@linux.dev> (raw)
In-Reply-To: <CY5PR21MB349314B6ECC4284EA3712FCDD7B42@CY5PR21MB3493.namprd21.prod.outlook.com>


On 7/25/24 6:42 PM, Michael Agun wrote:
> Are the perf_event_output flags (and what the event blob looks like) documented? Especially for the program type specific perf_event_output functions.

The documentation is in uapi/linux/bpf.h header.

https://github.com/torvalds/linux/blob/master/include/uapi/linux/bpf.h#L2353-L2397

  *         The *flags* are used to indicate the index in *map* for which
  *         the value must be put, masked with **BPF_F_INDEX_MASK**.
  *         Alternatively, *flags* can be set to **BPF_F_CURRENT_CPU**
  *         to indicate that the index of the current CPU core should be
  *         used.

>
> I've seen notes in (cilium) code passing payload lengths in the flags, and am specifically interested in how the event blob is constructed for perf events with payload capture.

Could you share more details about 'passing payload lengths in the flags'?
AFAIK, networking bpf_perf_event_output() actually utilizes bpf_event_output_data(),
in which 'flags' semantics has the same meaning as the above.

>
>
> Thanks,
> Michael

WARNING: multiple messages have this Message-ID (diff)
From: Yonghong Song <yonghong.song@linux.dev>
To: Michael Agun <danielagun@microsoft.com>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	"bpf@ietf.org" <bpf@ietf.org>
Subject: [Bpf] Re: perf_event_output payload capture flags?
Date: Fri, 26 Jul 2024 09:58:52 -0700	[thread overview]
Message-ID: <7ab6fbc6-2f05-4bb1-9596-855f276ab997@linux.dev> (raw)
Message-ID: <20240726165852.q9K44WUm5ZiqgCSJL-WJayOumV0goKTkWpBGGWJ4DPM@z> (raw)
In-Reply-To: <CY5PR21MB349314B6ECC4284EA3712FCDD7B42@CY5PR21MB3493.namprd21.prod.outlook.com>


On 7/25/24 6:42 PM, Michael Agun wrote:
> Are the perf_event_output flags (and what the event blob looks like) documented? Especially for the program type specific perf_event_output functions.

The documentation is in uapi/linux/bpf.h header.

https://github.com/torvalds/linux/blob/master/include/uapi/linux/bpf.h#L2353-L2397

  *         The *flags* are used to indicate the index in *map* for which
  *         the value must be put, masked with **BPF_F_INDEX_MASK**.
  *         Alternatively, *flags* can be set to **BPF_F_CURRENT_CPU**
  *         to indicate that the index of the current CPU core should be
  *         used.

>
> I've seen notes in (cilium) code passing payload lengths in the flags, and am specifically interested in how the event blob is constructed for perf events with payload capture.

Could you share more details about 'passing payload lengths in the flags'?
AFAIK, networking bpf_perf_event_output() actually utilizes bpf_event_output_data(),
in which 'flags' semantics has the same meaning as the above.

>
>
> Thanks,
> Michael

-- 
Bpf mailing list -- bpf@ietf.org
To unsubscribe send an email to bpf-leave@ietf.org

  reply	other threads:[~2024-07-26 16:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-26  1:42 perf_event_output payload capture flags? Michael Agun
2024-07-26 16:58 ` Yonghong Song [this message]
2024-07-26 16:58   ` [Bpf] " Yonghong Song
2024-07-26 23:45   ` [EXTERNAL] " Michael Agun
2024-07-29 20:58     ` Andrii Nakryiko
2024-07-29 20:58       ` [Bpf] " Andrii Nakryiko
2024-08-02  0:13       ` Michael Agun
2024-08-02  0:13         ` [Bpf] " Michael Agun
2024-08-06 20:21         ` Yonghong Song
2024-08-06 20:21           ` [Bpf] " Yonghong Song

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=7ab6fbc6-2f05-4bb1-9596-855f276ab997@linux.dev \
    --to=yonghong.song@linux.dev \
    --cc=bpf@ietf.org \
    --cc=bpf@vger.kernel.org \
    --cc=danielagun@microsoft.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.