* bpf and local lock
@ 2019-11-25 19:14 David Miller
2019-12-02 21:52 ` Alexei Starovoitov
0 siblings, 1 reply; 3+ messages in thread
From: David Miller @ 2019-11-25 19:14 UTC (permalink / raw)
To: tglx; +Cc: ast, daniel, bpf, netdev, linux-kernel
Thomas,
I am working on eliminating the explicit softirq disables around BPF
program invocation and replacing it with local lock usage instead.
We would really need to at least have the non-RT stubs upstream to
propagate this cleanly, do you think this is possible?
Thanks!
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: bpf and local lock
2019-11-25 19:14 bpf and local lock David Miller
@ 2019-12-02 21:52 ` Alexei Starovoitov
2019-12-02 23:08 ` David Miller
0 siblings, 1 reply; 3+ messages in thread
From: Alexei Starovoitov @ 2019-12-02 21:52 UTC (permalink / raw)
To: David Miller; +Cc: tglx, ast, daniel, bpf, netdev, linux-kernel
On Mon, Nov 25, 2019 at 11:14:33AM -0800, David Miller wrote:
>
> Thomas,
>
> I am working on eliminating the explicit softirq disables around BPF
> program invocation and replacing it with local lock usage instead.
>
> We would really need to at least have the non-RT stubs upstream to
> propagate this cleanly, do you think this is possible?
Hi Thomas,
seconding the same question: any chance local lock api can be sent upstream
soon? If api skeleton can get in during this merge window we will have the next
bpf-next/net-next cycle to sort out details. If not the bpf+rt would need to
wait one more release. Not a big deal. Just trying to figure out a time line
when can we start working on concrete bpf+rt patches.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: bpf and local lock
2019-12-02 21:52 ` Alexei Starovoitov
@ 2019-12-02 23:08 ` David Miller
0 siblings, 0 replies; 3+ messages in thread
From: David Miller @ 2019-12-02 23:08 UTC (permalink / raw)
To: alexei.starovoitov; +Cc: tglx, ast, daniel, bpf, netdev, linux-kernel
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Mon, 2 Dec 2019 13:52:38 -0800
> On Mon, Nov 25, 2019 at 11:14:33AM -0800, David Miller wrote:
>>
>> Thomas,
>>
>> I am working on eliminating the explicit softirq disables around BPF
>> program invocation and replacing it with local lock usage instead.
>>
>> We would really need to at least have the non-RT stubs upstream to
>> propagate this cleanly, do you think this is possible?
>
> Hi Thomas,
>
> seconding the same question: any chance local lock api can be sent upstream
> soon? If api skeleton can get in during this merge window we will have the next
> bpf-next/net-next cycle to sort out details. If not the bpf+rt would need to
> wait one more release. Not a big deal. Just trying to figure out a time line
> when can we start working on concrete bpf+rt patches.
FWIW, I have some simple patches I'm working on that start to annotate
the bpf function invocation call sites.
And as part of that I add the non-RT stubs plus some new interfaces I
think might be necessary.
I've been told Thomas is going to be offline for another week so I'll
just keep working on this and post when I have something concrete.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-12-02 23:08 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-25 19:14 bpf and local lock David Miller
2019-12-02 21:52 ` Alexei Starovoitov
2019-12-02 23:08 ` David Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).