Proposal using RCU for callbacks

Proposal using RCU for callbacks

[Stephen Hemminger]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]


The BPF and packet capture Rx/Tx callbacks use a per-queue use counter
so that removal can wait for the datapath. In BPF that costs a locked
instruction per burst. The code would be faster and cleaner if RCU
could be used, but DPDK RCU is limited to the QSBR model, which
requires application opt-in.

The userspace RCU library (liburcu) supports other models, so I did a
brief investigation into whether something similar could be done in
DPDK. As expected, it also turned up pre-existing issues: the counters
are wrong with MT_LOCKFREE Tx, the pdump one is not safe as written,
and cryptodev callback removal never waits.

I used Claude to write it up in more detail (attached). It is all from
code reading; nothing has been reproduced or prototyped yet.
This is too big to go into 26.11 at this point, will try and have something
for 27.03

[-- Attachment #2: rcu-ethdev-callback-removal.html --]
[-- Type: text/html, Size: 22874 bytes --]

Re: Proposal using RCU for callbacks

[Marat Khalili]

On 12/10/2026 19:13, Stephen Hemminger wrote:

> The BPF and packet capture Rx/Tx callbacks use a per-queue use counter
> so that removal can wait for the datapath. In BPF that costs a locked
> instruction per burst. The code would be faster and cleaner if RCU
> could be used, but DPDK RCU is limited to the QSBR model, which
> requires application opt-in.
>
> The userspace RCU library (liburcu) supports other models, so I did a
> brief investigation into whether something similar could be done in
> DPDK. As expected, it also turned up pre-existing issues: the counters
> are wrong with MT_LOCKFREE Tx, the pdump one is not safe as written,
> and cryptodev callback removal never waits.
>
> I used Claude to write it up in more detail (attached). It is all from
> code reading; nothing has been reproduced or prototyped yet.
> This is too big to go into 26.11 at this point, will try and have something
> for 27.03

Maybe it's just me, but the document is a little hard to read without 
knowing all of the context. Nevertheless, there is no doubt the sync 
mechanism in bpf_pkt.c can be improved. It done today, it would probably 
be written differently, very likely with RCU.

I would argue for incremental approach however. I'm currently aware of 
the following problems, in the order of decreasing priority and gain/effort:
* Deprecated rte_smp barrier functions being used.
* BPF inuse counter is not safe when using lockfree transmit (Bug 2051)
* Code needs cleanup and documenting to make discussions more productive.
* Possibly additional safety issues listed above (which I don't yet 
fully understand).
* Missing features: multi-threaded data planes, multiple callbacks, BPF 
program reuse etc.
* On the very last place, performance; as usual, benchmarks are 
mandatory for it to have any meaning.

I think we need to resist the temptation to just rewrite everything, 
especially with AI. Some recent research shows that productivity gains 
from AI are very limited particularly because code review becomes 
bottleneck (tbh it always was). Test coverage is also clearly 
insufficient for any major rewrites of this code. A patch solving 
everything at once risks getting stuck in review for very long time. 
Perhaps we arrive at RCU solution eventually, but I'd start with first 
items in the list.

Re: Proposal using RCU for callbacks

[Stephen Hemminger]

On Mon, 12 Oct 2026 21:27:08 +0100
Marat Khalili <qm2k21@gmail.com> wrote:

> On 12/10/2026 19:13, Stephen Hemminger wrote:
> 
> > The BPF and packet capture Rx/Tx callbacks use a per-queue use counter
> > so that removal can wait for the datapath. In BPF that costs a locked
> > instruction per burst. The code would be faster and cleaner if RCU
> > could be used, but DPDK RCU is limited to the QSBR model, which
> > requires application opt-in.
> >
> > The userspace RCU library (liburcu) supports other models, so I did a
> > brief investigation into whether something similar could be done in
> > DPDK. As expected, it also turned up pre-existing issues: the counters
> > are wrong with MT_LOCKFREE Tx, the pdump one is not safe as written,
> > and cryptodev callback removal never waits.
> >
> > I used Claude to write it up in more detail (attached). It is all from
> > code reading; nothing has been reproduced or prototyped yet.
> > This is too big to go into 26.11 at this point, will try and have something
> > for 27.03  
> 
> Maybe it's just me, but the document is a little hard to read without 
> knowing all of the context. Nevertheless, there is no doubt the sync 
> mechanism in bpf_pkt.c can be improved. It done today, it would probably 
> be written differently, very likely with RCU.
> 
> I would argue for incremental approach however. I'm currently aware of 
> the following problems, in the order of decreasing priority and gain/effort:
> * Deprecated rte_smp barrier functions being used.
> * BPF inuse counter is not safe when using lockfree transmit (Bug 2051)
> * Code needs cleanup and documenting to make discussions more productive.
> * Possibly additional safety issues listed above (which I don't yet 
> fully understand).
> * Missing features: multi-threaded data planes, multiple callbacks, BPF 
> program reuse etc.
> * On the very last place, performance; as usual, benchmarks are 
> mandatory for it to have any meaning.
> 
> I think we need to resist the temptation to just rewrite everything, 
> especially with AI. Some recent research shows that productivity gains 
> from AI are very limited particularly because code review becomes 
> bottleneck (tbh it always was). Test coverage is also clearly 
> insufficient for any major rewrites of this code. A patch solving 
> everything at once risks getting stuck in review for very long time. 
> Perhaps we arrive at RCU solution eventually, but I'd start with first 
> items in the list.
> 

Short form: BPF and pdump could use RCU to manage callback lifetime;
cryptodev already uses QSBR, but incorrectly. I would like to see
one usage pattern across all of DPDK that is fast and correct.

DPDK RCU only does QSBR, which needs the application to report when
each thread has passed a quiescent state. That restriction is why it is underused.

Other RCU flavors avoid this. With membarrier, the reader side needs
no fence, only a compiler barrier, and the writer pays with a syscall.
Reader state can hang off EAL thread registration, so no application
change is needed.

Today the BPF callback does a full memory barrier per burst. RCU would
replace that with a compiler barrier. Benchmarks will be needed to
show it matters.

This is not "let's use AI to rewrite it". AI was useful for the what-if
analysis; the real fixes will be real code, done incrementally.
Agree the barrier conversion and Bug 2051 come first.

See:
 - https://man7.org/linux/man-pages/man2/membarrier.2.html
 - https://liburcu.org/
 - https://github.com/nmraz/simplercu (toy implementation)
 - https://lwn.net/Articles/369018/ (original 2010 RFC)