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.
