[PATCH v2 5/9] bpf: simplify callback inuse tracking to boolean flag

[Konstantin Ananyev]

>
> On 25/10/2026 10:50, Konstantin Ananyev wrote:
>>>>        /* in use, busy wait till current RX/TX iteration is 
>>>> finished */
>>>>         if ((puse & BPF_ETH_CBI_INUSE) != 0) {
>>>>                 RTE_WAIT_UNTIL_MASKED((__rte_atomic uint32_t 
>>>> *)(uintptr_t)&cbi->use,
>>>>                         UINT32_MAX, !=, puse, 
>>>> rte_memory_order_acquire);
>>>>         }
>>>>
>>>> Here, we are waiting when 'puse' will become not equal to 'cbi->use'.
>>>> So, any value except current puse is good.
>>>
>>> If you look a the sequence diagram, there is no way to arrive here 
>>> without the callback being removed and `cb` cleared in the DP 
>>> thread, no matter how you move the arrows around.  So the DP thread 
>>> will increment `use` once to make it even, and then will never ever 
>>> reach the callback or increment anything again. We allow any value 
>>> except current puse, but there are never any values except the 
>>> current puse and the one after it. It's just these two values we can 
>>> possibly see.
>>
>> DP can (and most likely will) call rx/tx_burst again.
>> Just to give you an example:
>> --- DP thread:
>> cbi->use = 1;
>>                          --- CP thread:
>>                             read cbi->use (1)
> By this time the callback is removed and `cb` is cleared.

from CP thread perspective:
  a) bc->cb is removed from ethdev callback list
  b) bc->cb = NULL
But there is no guarantee that DP thread will see these changes till next
bpf_eth_cbi_inuse()->rte_atomic_thread_fence(rte_memory_order_seq_cst);
So it can still (at least once) invoke bpf callback and read and update 
cbi->use.

Thinking about that once again - it seems that could happen only once
(i.e. in that example CP thread will see just one of {1,2,3,4} after 
that point.
So I probably was too pessimistic about 'live-lock'.
But anyway, I don't see any point to change existing code to what you 
propose (boolean value).
 From my perspective it doesn't make it safer (or faster) in any way.

>> --DP thread:
>> cbi->use = 2;
>> ...
>> next rx burst:
>> cbi->use = 3;
> How did we reach hear if `cb` is NULL?
>>                 read cbi->use (3)
>>
>> So CP sees an odd value (3), but it is ok to proceed, as previoud RX 
>> iteration (quiscent period) had already finished,
>> and in new one rx_burst will not see removed call-back.