perf_event_output payload capture flags?

perf_event_output payload capture flags?

[Michael Agun]

Are the perf_event_output flags (and what the event blob looks like) documented? Especially for the program type specific perf_event_output functions.

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.


Thanks,
Michael

Re: perf_event_output payload capture flags?

[Yonghong Song]

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] Re: perf_event_output payload capture flags?

[Yonghong Song]

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

Re: [EXTERNAL] Re: perf_event_output payload capture flags?

[Michael Agun]

CC Dave

Thank you.

Due to Microsoft policies we avoid reading code with strong licensing (like GPL 2.0).

Is there some other documentation of the flags, or could you explain them in words?
Or is that the complete flags description (which is in other documentation) and I am misunderstanding the code below?

https://github.com/cilium/cilium/blob/3fa44b59eef792e28f70b1fd23e3e17e426909f5/bpf/lib/dbg.h#L229

It looks to me here like the capture length is being OR'd into the flags.

Any insights would be appreciated.

Thanks,
Michael

________________________________________
From: Yonghong Song <yonghong.song@linux.dev>
Sent: Friday, July 26, 2024 9:58 AM
To: Michael Agun <danielagun@microsoft.com>; bpf@vger.kernel.org <bpf@vger.kernel.org>; bpf@ietf.org <bpf@ietf.org>
Subject: [EXTERNAL] Re: perf_event_output payload capture flags?

[You don't often get email from yonghong.song@linux.dev. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

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

Re: [EXTERNAL] Re: perf_event_output payload capture flags?

[Andrii Nakryiko]

On Fri, Jul 26, 2024 at 4:45 PM Michael Agun <danielagun@microsoft.com> wrote:
>
> CC Dave
>
> Thank you.
>
> Due to Microsoft policies we avoid reading code with strong licensing (like GPL 2.0).

Linux UAPI headers are licensed as `GPL-2.0 WITH Linux-syscall-note`,
and see [0]. Will cite it in full below. Doesn't this mean that it's
fine to read UAPI definitions?

SPDX-Exception-Identifier: Linux-syscall-note
SPDX-URL: https://spdx.org/licenses/Linux-syscall-note.html
SPDX-Licenses: GPL-2.0, GPL-2.0+, GPL-1.0+, LGPL-2.0, LGPL-2.0+,
LGPL-2.1, LGPL-2.1+, GPL-2.0-only, GPL-2.0-or-later
Usage-Guide:
  This exception is used together with one of the above SPDX-Licenses
  to mark user space API (uapi) header files so they can be included
  into non GPL compliant user space application code.
  To use this exception add it with the keyword WITH to one of the
  identifiers in the SPDX-Licenses tag:
    SPDX-License-Identifier: <SPDX-License> WITH Linux-syscall-note
License-Text:

   NOTE! This copyright does *not* cover user programs that use kernel
 services by normal system calls - this is merely considered normal use
 of the kernel, and does *not* fall under the heading of "derived work".
 Also note that the GPL below is copyrighted by the Free Software
 Foundation, but the instance of code that it refers to (the Linux
 kernel) is copyrighted by me and others who actually wrote it.

 Also note that the only valid version of the GPL as far as the kernel
 is concerned is _this_ particular version of the license (ie v2, not
 v2.2 or v3.x or whatever), unless explicitly otherwise stated.

            Linus Torvalds


  [0] https://github.com/torvalds/linux/blob/master/LICENSES/exceptions/Linux-syscall-note

>
> Is there some other documentation of the flags, or could you explain them in words?
> Or is that the complete flags description (which is in other documentation) and I am misunderstanding the code below?
>
> https://github.com/cilium/cilium/blob/3fa44b59eef792e28f70b1fd23e3e17e426909f5/bpf/lib/dbg.h#L229
>
> It looks to me here like the capture length is being OR'd into the flags.
>
> Any insights would be appreciated.
>
> Thanks,
> Michael
>
> ________________________________________
> From: Yonghong Song <yonghong.song@linux.dev>
> Sent: Friday, July 26, 2024 9:58 AM
> To: Michael Agun <danielagun@microsoft.com>; bpf@vger.kernel.org <bpf@vger.kernel.org>; bpf@ietf.org <bpf@ietf.org>
> Subject: [EXTERNAL] Re: perf_event_output payload capture flags?
>
> [You don't often get email from yonghong.song@linux.dev. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> 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] Re: [EXTERNAL] Re: perf_event_output payload capture flags?

[Andrii Nakryiko]

On Fri, Jul 26, 2024 at 4:45 PM Michael Agun <danielagun@microsoft.com> wrote:
>
> CC Dave
>
> Thank you.
>
> Due to Microsoft policies we avoid reading code with strong licensing (like GPL 2.0).

Linux UAPI headers are licensed as `GPL-2.0 WITH Linux-syscall-note`,
and see [0]. Will cite it in full below. Doesn't this mean that it's
fine to read UAPI definitions?

SPDX-Exception-Identifier: Linux-syscall-note
SPDX-URL: https://spdx.org/licenses/Linux-syscall-note.html
SPDX-Licenses: GPL-2.0, GPL-2.0+, GPL-1.0+, LGPL-2.0, LGPL-2.0+,
LGPL-2.1, LGPL-2.1+, GPL-2.0-only, GPL-2.0-or-later
Usage-Guide:
  This exception is used together with one of the above SPDX-Licenses
  to mark user space API (uapi) header files so they can be included
  into non GPL compliant user space application code.
  To use this exception add it with the keyword WITH to one of the
  identifiers in the SPDX-Licenses tag:
    SPDX-License-Identifier: <SPDX-License> WITH Linux-syscall-note
License-Text:

   NOTE! This copyright does *not* cover user programs that use kernel
 services by normal system calls - this is merely considered normal use
 of the kernel, and does *not* fall under the heading of "derived work".
 Also note that the GPL below is copyrighted by the Free Software
 Foundation, but the instance of code that it refers to (the Linux
 kernel) is copyrighted by me and others who actually wrote it.

 Also note that the only valid version of the GPL as far as the kernel
 is concerned is _this_ particular version of the license (ie v2, not
 v2.2 or v3.x or whatever), unless explicitly otherwise stated.

            Linus Torvalds


  [0] https://github.com/torvalds/linux/blob/master/LICENSES/exceptions/Linux-syscall-note

>
> Is there some other documentation of the flags, or could you explain them in words?
> Or is that the complete flags description (which is in other documentation) and I am misunderstanding the code below?
>
> https://github.com/cilium/cilium/blob/3fa44b59eef792e28f70b1fd23e3e17e426909f5/bpf/lib/dbg.h#L229
>
> It looks to me here like the capture length is being OR'd into the flags.
>
> Any insights would be appreciated.
>
> Thanks,
> Michael
>
> ________________________________________
> From: Yonghong Song <yonghong.song@linux.dev>
> Sent: Friday, July 26, 2024 9:58 AM
> To: Michael Agun <danielagun@microsoft.com>; bpf@vger.kernel.org <bpf@vger.kernel.org>; bpf@ietf.org <bpf@ietf.org>
> Subject: [EXTERNAL] Re: perf_event_output payload capture flags?
>
> [You don't often get email from yonghong.song@linux.dev. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> 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

Re: [EXTERNAL] Re: perf_event_output payload capture flags?

[Michael Agun]

Thanks Andrii, I had to confirm I could read it and it looks like that is the same as the docs I have seen. I now see where the capture length is being placed, but am still missing something.

Down near the bottom there is a flag constant BPF_F_CTXLEN_MASK. It appears that is bitfield in the flags value the capture length goes in, but I don't see any other mention of that constant. Do you know where that is documented?

Thanks,
Michael

________________________________________
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Sent: Monday, July 29, 2024 1:58 PM
To: Michael Agun <danielagun@microsoft.com>
Cc: Yonghong Song <yonghong.song@linux.dev>; bpf@vger.kernel.org <bpf@vger.kernel.org>; bpf@ietf.org <bpf@ietf.org>; dthaler1968@googlemail.com <dthaler1968@googlemail.com>
Subject: Re: [EXTERNAL] Re: perf_event_output payload capture flags?

On Fri, Jul 26, 2024 at 4:45 PM Michael Agun <danielagun@microsoft.com> wrote:
>
> CC Dave
>
> Thank you.
>
> Due to Microsoft policies we avoid reading code with strong licensing (like GPL 2.0).

Linux UAPI headers are licensed as `GPL-2.0 WITH Linux-syscall-note`,
and see [0]. Will cite it in full below. Doesn't this mean that it's
fine to read UAPI definitions?

SPDX-Exception-Identifier: Linux-syscall-note
SPDX-URL: https://spdx.org/licenses/Linux-syscall-note.html
SPDX-Licenses: GPL-2.0, GPL-2.0+, GPL-1.0+, LGPL-2.0, LGPL-2.0+,
LGPL-2.1, LGPL-2.1+, GPL-2.0-only, GPL-2.0-or-later
Usage-Guide:
  This exception is used together with one of the above SPDX-Licenses
  to mark user space API (uapi) header files so they can be included
  into non GPL compliant user space application code.
  To use this exception add it with the keyword WITH to one of the
  identifiers in the SPDX-Licenses tag:
    SPDX-License-Identifier: <SPDX-License> WITH Linux-syscall-note
License-Text:

   NOTE! This copyright does *not* cover user programs that use kernel
 services by normal system calls - this is merely considered normal use
 of the kernel, and does *not* fall under the heading of "derived work".
 Also note that the GPL below is copyrighted by the Free Software
 Foundation, but the instance of code that it refers to (the Linux
 kernel) is copyrighted by me and others who actually wrote it.

 Also note that the only valid version of the GPL as far as the kernel
 is concerned is _this_ particular version of the license (ie v2, not
 v2.2 or v3.x or whatever), unless explicitly otherwise stated.

            Linus Torvalds


  [0] https://github.com/torvalds/linux/blob/master/LICENSES/exceptions/Linux-syscall-note

>
> Is there some other documentation of the flags, or could you explain them in words?
> Or is that the complete flags description (which is in other documentation) and I am misunderstanding the code below?
>
> https://github.com/cilium/cilium/blob/3fa44b59eef792e28f70b1fd23e3e17e426909f5/bpf/lib/dbg.h#L229
>
> It looks to me here like the capture length is being OR'd into the flags.
>
> Any insights would be appreciated.
>
> Thanks,
> Michael
>
> ________________________________________
> From: Yonghong Song <yonghong.song@linux.dev>
> Sent: Friday, July 26, 2024 9:58 AM
> To: Michael Agun <danielagun@microsoft.com>; bpf@vger.kernel.org <bpf@vger.kernel.org>; bpf@ietf.org <bpf@ietf.org>
> Subject: [EXTERNAL] Re: perf_event_output payload capture flags?
>
> [You don't often get email from yonghong.song@linux.dev. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> 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] Re: [EXTERNAL] Re: perf_event_output payload capture flags?

[Michael Agun]

Thanks Andrii, I had to confirm I could read it and it looks like that is the same as the docs I have seen. I now see where the capture length is being placed, but am still missing something.

Down near the bottom there is a flag constant BPF_F_CTXLEN_MASK. It appears that is bitfield in the flags value the capture length goes in, but I don't see any other mention of that constant. Do you know where that is documented?

Thanks,
Michael

________________________________________
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Sent: Monday, July 29, 2024 1:58 PM
To: Michael Agun <danielagun@microsoft.com>
Cc: Yonghong Song <yonghong.song@linux.dev>; bpf@vger.kernel.org <bpf@vger.kernel.org>; bpf@ietf.org <bpf@ietf.org>; dthaler1968@googlemail.com <dthaler1968@googlemail.com>
Subject: Re: [EXTERNAL] Re: perf_event_output payload capture flags?

On Fri, Jul 26, 2024 at 4:45 PM Michael Agun <danielagun@microsoft.com> wrote:
>
> CC Dave
>
> Thank you.
>
> Due to Microsoft policies we avoid reading code with strong licensing (like GPL 2.0).

Linux UAPI headers are licensed as `GPL-2.0 WITH Linux-syscall-note`,
and see [0]. Will cite it in full below. Doesn't this mean that it's
fine to read UAPI definitions?

SPDX-Exception-Identifier: Linux-syscall-note
SPDX-URL: https://spdx.org/licenses/Linux-syscall-note.html
SPDX-Licenses: GPL-2.0, GPL-2.0+, GPL-1.0+, LGPL-2.0, LGPL-2.0+,
LGPL-2.1, LGPL-2.1+, GPL-2.0-only, GPL-2.0-or-later
Usage-Guide:
  This exception is used together with one of the above SPDX-Licenses
  to mark user space API (uapi) header files so they can be included
  into non GPL compliant user space application code.
  To use this exception add it with the keyword WITH to one of the
  identifiers in the SPDX-Licenses tag:
    SPDX-License-Identifier: <SPDX-License> WITH Linux-syscall-note
License-Text:

   NOTE! This copyright does *not* cover user programs that use kernel
 services by normal system calls - this is merely considered normal use
 of the kernel, and does *not* fall under the heading of "derived work".
 Also note that the GPL below is copyrighted by the Free Software
 Foundation, but the instance of code that it refers to (the Linux
 kernel) is copyrighted by me and others who actually wrote it.

 Also note that the only valid version of the GPL as far as the kernel
 is concerned is _this_ particular version of the license (ie v2, not
 v2.2 or v3.x or whatever), unless explicitly otherwise stated.

            Linus Torvalds


  [0] https://github.com/torvalds/linux/blob/master/LICENSES/exceptions/Linux-syscall-note

>
> Is there some other documentation of the flags, or could you explain them in words?
> Or is that the complete flags description (which is in other documentation) and I am misunderstanding the code below?
>
> https://github.com/cilium/cilium/blob/3fa44b59eef792e28f70b1fd23e3e17e426909f5/bpf/lib/dbg.h#L229
>
> It looks to me here like the capture length is being OR'd into the flags.
>
> Any insights would be appreciated.
>
> Thanks,
> Michael
>
> ________________________________________
> From: Yonghong Song <yonghong.song@linux.dev>
> Sent: Friday, July 26, 2024 9:58 AM
> To: Michael Agun <danielagun@microsoft.com>; bpf@vger.kernel.org <bpf@vger.kernel.org>; bpf@ietf.org <bpf@ietf.org>
> Subject: [EXTERNAL] Re: perf_event_output payload capture flags?
>
> [You don't often get email from yonghong.song@linux.dev. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> 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

Re: [EXTERNAL] Re: perf_event_output payload capture flags?

[Yonghong Song]

On 8/1/24 5:13 PM, Michael Agun wrote:
> Thanks Andrii, I had to confirm I could read it and it looks like that is the same as the docs I have seen. I now see where the capture length is being placed, but am still missing something.
>
> Down near the bottom there is a flag constant BPF_F_CTXLEN_MASK. It appears that is bitfield in the flags value the capture length goes in, but I don't see any other mention of that constant. Do you know where that is documented?

Okay. The following in uapi bpf.h:

/* BPF_FUNC_perf_event_output for sk_buff input context. */
         BPF_F_CTXLEN_MASK               = (0xfffffULL << 32),

That is why I missed it since it is for networking side of perf_event_output.

The networking flavored bpf_perf_event_output tries to output
networking packets plus meta data. It is a little bit different
from tracing side of bpf_perf_event_output.
Unfortunately, we do not have a good documentation for this yet.

>
> Thanks,
> Michael
>
> ________________________________________
> From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
> Sent: Monday, July 29, 2024 1:58 PM
> To: Michael Agun <danielagun@microsoft.com>
> Cc: Yonghong Song <yonghong.song@linux.dev>; bpf@vger.kernel.org <bpf@vger.kernel.org>; bpf@ietf.org <bpf@ietf.org>; dthaler1968@googlemail.com <dthaler1968@googlemail.com>
> Subject: Re: [EXTERNAL] Re: perf_event_output payload capture flags?
>
> On Fri, Jul 26, 2024 at 4:45 PM Michael Agun <danielagun@microsoft.com> wrote:
>> CC Dave
>>
>> Thank you.
>>
>> Due to Microsoft policies we avoid reading code with strong licensing (like GPL 2.0).
> Linux UAPI headers are licensed as `GPL-2.0 WITH Linux-syscall-note`,
> and see [0]. Will cite it in full below. Doesn't this mean that it's
> fine to read UAPI definitions?
>
> SPDX-Exception-Identifier: Linux-syscall-note
> SPDX-URL: https://spdx.org/licenses/Linux-syscall-note.html
> SPDX-Licenses: GPL-2.0, GPL-2.0+, GPL-1.0+, LGPL-2.0, LGPL-2.0+,
> LGPL-2.1, LGPL-2.1+, GPL-2.0-only, GPL-2.0-or-later
> Usage-Guide:
>    This exception is used together with one of the above SPDX-Licenses
>    to mark user space API (uapi) header files so they can be included
>    into non GPL compliant user space application code.
>    To use this exception add it with the keyword WITH to one of the
>    identifiers in the SPDX-Licenses tag:
>      SPDX-License-Identifier: <SPDX-License> WITH Linux-syscall-note
> License-Text:
>
>     NOTE! This copyright does *not* cover user programs that use kernel
>   services by normal system calls - this is merely considered normal use
>   of the kernel, and does *not* fall under the heading of "derived work".
>   Also note that the GPL below is copyrighted by the Free Software
>   Foundation, but the instance of code that it refers to (the Linux
>   kernel) is copyrighted by me and others who actually wrote it.
>
>   Also note that the only valid version of the GPL as far as the kernel
>   is concerned is _this_ particular version of the license (ie v2, not
>   v2.2 or v3.x or whatever), unless explicitly otherwise stated.
>
>              Linus Torvalds
>
>
>    [0] https://github.com/torvalds/linux/blob/master/LICENSES/exceptions/Linux-syscall-note
>
>> Is there some other documentation of the flags, or could you explain them in words?
>> Or is that the complete flags description (which is in other documentation) and I am misunderstanding the code below?
>>
>> https://github.com/cilium/cilium/blob/3fa44b59eef792e28f70b1fd23e3e17e426909f5/bpf/lib/dbg.h#L229
>>
>> It looks to me here like the capture length is being OR'd into the flags.
>>
>> Any insights would be appreciated.
>>
>> Thanks,
>> Michael
>>
>> ________________________________________
>> From: Yonghong Song <yonghong.song@linux.dev>
>> Sent: Friday, July 26, 2024 9:58 AM
>> To: Michael Agun <danielagun@microsoft.com>; bpf@vger.kernel.org <bpf@vger.kernel.org>; bpf@ietf.org <bpf@ietf.org>
>> Subject: [EXTERNAL] Re: perf_event_output payload capture flags?
>>
>> [You don't often get email from yonghong.song@linux.dev. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> 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] Re: [EXTERNAL] Re: perf_event_output payload capture flags?

[Yonghong Song]

On 8/1/24 5:13 PM, Michael Agun wrote:
> Thanks Andrii, I had to confirm I could read it and it looks like that is the same as the docs I have seen. I now see where the capture length is being placed, but am still missing something.
>
> Down near the bottom there is a flag constant BPF_F_CTXLEN_MASK. It appears that is bitfield in the flags value the capture length goes in, but I don't see any other mention of that constant. Do you know where that is documented?

Okay. The following in uapi bpf.h:

/* BPF_FUNC_perf_event_output for sk_buff input context. */
         BPF_F_CTXLEN_MASK               = (0xfffffULL << 32),

That is why I missed it since it is for networking side of perf_event_output.

The networking flavored bpf_perf_event_output tries to output
networking packets plus meta data. It is a little bit different
from tracing side of bpf_perf_event_output.
Unfortunately, we do not have a good documentation for this yet.

>
> Thanks,
> Michael
>
> ________________________________________
> From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
> Sent: Monday, July 29, 2024 1:58 PM
> To: Michael Agun <danielagun@microsoft.com>
> Cc: Yonghong Song <yonghong.song@linux.dev>; bpf@vger.kernel.org <bpf@vger.kernel.org>; bpf@ietf.org <bpf@ietf.org>; dthaler1968@googlemail.com <dthaler1968@googlemail.com>
> Subject: Re: [EXTERNAL] Re: perf_event_output payload capture flags?
>
> On Fri, Jul 26, 2024 at 4:45 PM Michael Agun <danielagun@microsoft.com> wrote:
>> CC Dave
>>
>> Thank you.
>>
>> Due to Microsoft policies we avoid reading code with strong licensing (like GPL 2.0).
> Linux UAPI headers are licensed as `GPL-2.0 WITH Linux-syscall-note`,
> and see [0]. Will cite it in full below. Doesn't this mean that it's
> fine to read UAPI definitions?
>
> SPDX-Exception-Identifier: Linux-syscall-note
> SPDX-URL: https://spdx.org/licenses/Linux-syscall-note.html
> SPDX-Licenses: GPL-2.0, GPL-2.0+, GPL-1.0+, LGPL-2.0, LGPL-2.0+,
> LGPL-2.1, LGPL-2.1+, GPL-2.0-only, GPL-2.0-or-later
> Usage-Guide:
>    This exception is used together with one of the above SPDX-Licenses
>    to mark user space API (uapi) header files so they can be included
>    into non GPL compliant user space application code.
>    To use this exception add it with the keyword WITH to one of the
>    identifiers in the SPDX-Licenses tag:
>      SPDX-License-Identifier: <SPDX-License> WITH Linux-syscall-note
> License-Text:
>
>     NOTE! This copyright does *not* cover user programs that use kernel
>   services by normal system calls - this is merely considered normal use
>   of the kernel, and does *not* fall under the heading of "derived work".
>   Also note that the GPL below is copyrighted by the Free Software
>   Foundation, but the instance of code that it refers to (the Linux
>   kernel) is copyrighted by me and others who actually wrote it.
>
>   Also note that the only valid version of the GPL as far as the kernel
>   is concerned is _this_ particular version of the license (ie v2, not
>   v2.2 or v3.x or whatever), unless explicitly otherwise stated.
>
>              Linus Torvalds
>
>
>    [0] https://github.com/torvalds/linux/blob/master/LICENSES/exceptions/Linux-syscall-note
>
>> Is there some other documentation of the flags, or could you explain them in words?
>> Or is that the complete flags description (which is in other documentation) and I am misunderstanding the code below?
>>
>> https://github.com/cilium/cilium/blob/3fa44b59eef792e28f70b1fd23e3e17e426909f5/bpf/lib/dbg.h#L229
>>
>> It looks to me here like the capture length is being OR'd into the flags.
>>
>> Any insights would be appreciated.
>>
>> Thanks,
>> Michael
>>
>> ________________________________________
>> From: Yonghong Song <yonghong.song@linux.dev>
>> Sent: Friday, July 26, 2024 9:58 AM
>> To: Michael Agun <danielagun@microsoft.com>; bpf@vger.kernel.org <bpf@vger.kernel.org>; bpf@ietf.org <bpf@ietf.org>
>> Subject: [EXTERNAL] Re: perf_event_output payload capture flags?
>>
>> [You don't often get email from yonghong.song@linux.dev. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> 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