Re: Proposal using RCU for callbacks

[Marat Khalili <qm2k21@gmail.com>]

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.