on pool_put.
/neale
From: vpp-dev@lists.fd.io on behalf of Florin Coras via
lists.fd.io
Date: Thursday, 4 November 2021 at 22:19
To: Stanislav Zaikin
Cc: Damjan Marion , vpp-dev
Subject: Re: [vpp-dev] a free_bitmap may expand while pool_put
Hi Stanislav,
Yes, binary api messages are handled by main
Hi Stanislav,
Yes, binary api messages are handled by main thread. If the issue is purely
binary api related, then yes, checking for pool (vectors or bitmap) realloc
with single writer should work.
Note that the pool’s free_indices vector can also expand (not only the bitmap),
so that should
Hi Damjan,
Hi Florin,
I may have given the wrong example, even though the IP API's marked as
mt-safe (VL_API_IP_ROUTE_ADD_DEL/VL_API_IP_ROUTE_ADD_DEL_V2), they'd be
called only from the main thread, right? So, only one pool_put will be
called and it looks like the patch actually fixes the problem
Agreed! Since pools are not thread safe, the whole load balance destroy scheme
should probably be refactored.
Maybe add, with locks, the indices to be freed to a vector and once enough
accumulate, or if a new element is needed, grab the worker barrier and actually
free them all.
Regards,
Dear Stanislav,
It doesn’t look to me as a thread safe solution.
i.e imagine 2 threads call pool_put_will expand on the same time, and there is
just one free slot. Both will get negative answer, but 2nd put operation will
actually expand.
—
Damjan
> On 04.11.2021., at 18:24, Stanislav
Hello folks,
In a multi-threaded environment (in my case I have 2 workers) I observed a
crash, and thanks to Neale, it turned out that free_bitmap may expand while
doing pool_put.
Let's say one thread is doing pool_put, while another thread is calling
"pool_elt_at_index". I observed different
