BPF List
 help / color / mirror / Atom feed
From: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
To: "Emil Tsalapatis" <emil@etsalapatis.com>,
	"Alexei Starovoitov" <alexei.starovoitov@gmail.com>
Cc: <bpf@vger.kernel.org>, <andrii@kernel.org>, <eddyz87@gmail.com>,
	<daniel@iogearbox.net>
Subject: Re: [PATCH bpf-next 0/7] bpf: Inline IRQ enter/exit instructions
Date: Wed, 28 Oct 2026 17:56:30 +0100	[thread overview]
Message-ID: <DMGMON3EQ62I.20R7XJBDGWJ4U@gmail.com> (raw)
In-Reply-To: <CABFh=a6PxhNKnQ7KJJ9TbWhLg_GOQYWPxe3QSEAGEMTQ=o-5Vg@mail.gmail.com>

On Wed Oct 28, 2026 at 2:55 AM CET, Emil Tsalapatis wrote:
> On Tue, Oct 27, 2026 at 4:53 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>>
>> On Tue, Oct 27, 2026 at 09:28 AM Emil Tsalapatis <emil@etsalapatis.com> wrote:
>> > Add inlining for those functions. The inlining happens in two stages.
>> > First replace the call itself with a special BPF instruction denoting
>> > an IRQ disable-and save, or restore-and-enable. Those instructions
>> > are translated by the architecture-specific JIT into the corresponding
>> > operation.
>>
>> No. That doesn't scale. We cannot add new insns for every to-be-inlined kfunc.
>> See bpf_jit_inlines_helper_call().
>>
>
> Ack, the code below seems strictly better than reserving an instruction.
>
>> Like:
>>
>> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
>> index 6a2fe3d..c1c9a1c 100644
>> --- a/arch/x86/net/bpf_jit_comp.c
>> +++ b/arch/x86/net/bpf_jit_comp.c
>> @@ -3495,6 +3495,17 @@ populate_extable:
>>                         }
>>                         if (!imm32)
>>                                 return -EINVAL;
>> +                       if (src_reg == BPF_PSEUDO_KFUNC_CALL && bpf_jit_inlines_kfunc_call(func)) {
>> +                               if (func == (u8 *)bpf_local_irq_save) {
>> +                                       /* pushfq; pop [rdi]; cli */
>> +                                       EMIT4(0x9C, 0x8F, 0x07, 0xFA);
>> +                               } else {
>> +                                       /* test dword ptr [rdi], X86_EFLAGS_IF; je 1f; sti; 1: */
>> +                                       EMIT2_off32(0xF7, 0x07, X86_EFLAGS_IF);
>> +                                       EMIT3(X86_JE, 1, 0xFB);
>> +                               }
>> +                               break;
>> +                       }
>>                         if (src_reg == BPF_PSEUDO_KFUNC_CALL) {
>>                                 fm = bpf_jit_find_kfunc_model(bpf_prog, insn);
>>                                 if (!fm)
>> @@ -5116,6 +5127,14 @@ bool bpf_jit_supports_kfunc_call(void)
>>         return true;
>>  }
>>
>> +bool bpf_jit_inlines_kfunc_call(void *func)
>> +{
>> +       if (!IS_ENABLED(CONFIG_BPF_SYSCALL) || IS_ENABLED(CONFIG_TRACE_IRQFLAGS) ||
>> +           cpu_feature_enabled(X86_FEATURE_XENPV))
>> +               return false;
>> +       return func == bpf_local_irq_save || func == bpf_local_irq_restore;
>> +}
>>
>> ...
>>
>> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
>> index 648abe1..26b6a9d 100644
>> --- a/kernel/bpf/helpers.c
>> +++ b/kernel/bpf/helpers.c
>> @@ -5197,8 +5197,8 @@ BTF_ID_FLAGS(func, bpf_get_kmem_cache, KF_PERFMON)
>>  BTF_ID_FLAGS(func, bpf_iter_kmem_cache_new, KF_ITER_NEW | KF_SLEEPABLE)
>>  BTF_ID_FLAGS(func, bpf_iter_kmem_cache_next, KF_ITER_NEXT | KF_RET_NULL | KF_SLEEPABLE)
>>  BTF_ID_FLAGS(func, bpf_iter_kmem_cache_destroy, KF_ITER_DESTROY | KF_SLEEPABLE)
>> -BTF_ID_FLAGS(func, bpf_local_irq_save)
>> -BTF_ID_FLAGS(func, bpf_local_irq_restore)
>> +BTF_ID_FLAGS(func, bpf_local_irq_save, KF_FASTCALL)
>> +BTF_ID_FLAGS(func, bpf_local_irq_restore, KF_FASTCALL)
>>
>> and corresponding bits in bpf_get_call_summary()...
>>
>> but before doing any of that there gotta be performance numbers that it's worth doing.
>>
>
> Makes sense, I assume you mean more macro numbers from
> production-grade programs apart from ubench numbers.
>

While you are it, it would be useful for bpf_preempt_{disable,enable}() to get
similar treatment.

>> pw-bot: cr


      reply	other threads:[~2026-10-28 16:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-27 16:28 [PATCH bpf-next 0/7] bpf: Inline IRQ enter/exit instructions Emil Tsalapatis
2026-10-27 16:28 ` [PATCH bpf-next 1/7] bpf: Add internal IRQ save and restore instructions Emil Tsalapatis
2026-10-27 16:28 ` [PATCH bpf-next 2/7] x86, bpf: JIT " Emil Tsalapatis
2026-10-27 16:28 ` [PATCH bpf-next 3/7] arm64, " Emil Tsalapatis
2026-10-27 17:10   ` bot+bpf-ci
2026-10-27 16:28 ` [PATCH bpf-next 4/7] bpf: Inline local IRQ kfunc calls during verifier fixup Emil Tsalapatis
2026-10-27 16:28 ` [PATCH bpf-next 5/7] selftests/bpf: Test local IRQ kfunc inlining Emil Tsalapatis
2026-10-27 16:46   ` sashiko-bot
2026-10-27 17:10   ` bot+bpf-ci
2026-10-27 16:28 ` [PATCH bpf-next 6/7] bpf: Enable fastcall for inlined local IRQ kfuncs Emil Tsalapatis
2026-10-27 16:28 ` [PATCH bpf-next 7/7] selftests/bpf: Verify register preservation for IRQ fastcalls Emil Tsalapatis
2026-10-27 17:10   ` bot+bpf-ci
2026-10-27 16:53 ` [PATCH bpf-next 0/7] bpf: Inline IRQ enter/exit instructions Alexei Starovoitov
2026-10-28  1:55   ` Emil Tsalapatis
2026-10-28 16:56     ` Kumar Kartikeya Dwivedi [this message]

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=DMGMON3EQ62I.20R7XJBDGWJ4U@gmail.com \
    --to=memxor@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=emil@etsalapatis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox