Let me resurrect this discussion as my patch is still in gerrit.
Nick, any chance you can submit your proposal as discussed bellow?
Thanks,
—
Damjan
> On 04.11.2021., at 19:35, Damjan Marion via lists.fd.io
> wrote:
>
>
> Dear Nick,
>
> Will be great if you can support your proposal wi
Hi Nick,
Not sure I understood everything correctly but here are a couple of comments:
- max_threads cannot be known upfront and that makes the use of bihashes a bit
more complicated
- the writer needs to scan the whole rlock array to check for readers. If
max_threads is large (say 100) it mig
Dear Nick,
Will be great if you can support your proposal with a running code so we can
understand exactly what it means.
—
Damjan
> On 04.11.2021., at 19:24, Nick Zavaritsky wrote:
>
> Hi, thanks for an insightful discussion!
>
> I do understand that high performance is one of the most
Hi, thanks for an insightful discussion!
I do understand that high performance is one of the most important goals of
vpp, therefore certain solutions might not fly. From my POV, the version
counter would be an improvement. It definitely decreases the probability of
triggering the bug.
Concerni
Agreed it’s unlikely so maybe just use the 2 bits left for the epoch counter as
a middle ground? The new approach should be better either way :-)
Florin
> On Nov 3, 2021, at 11:55 AM, Damjan Marion wrote:
>
> What about the following, we shift offset by 6, as all buckets are aligned to
> 64,
What about the following, we shift offset by 6, as all buckets are aligned to
64, anyway, and that gives us 6 more bits so we can have 8 bit epoch counter….
?
—
Damjan
> On 03.11.2021., at 19:45, Damjan Marion wrote:
>
>
>
> yes, i am aware of that, it is extremelly unlikely and only way
yes, i am aware of that, it is extremelly unlikely and only way i can see this
fixed is introducing epoch on the bucket level but we dont have enough space
there….
—
Damjan
> On 03.11.2021., at 19:16, Florin Coras wrote:
>
> Hi Damjan,
>
> Definitely like the scheme but the change bit m
Hi Damjan,
Definitely like the scheme but the change bit might not be enough, unless I’m
misunderstanding. For instance, two consecutive updates to a bucket before
reader grabs b1 will hide the change.
Florin
> On Nov 3, 2021, at 9:36 AM, Damjan Marion via lists.fd.io
> wrote:
>
>
> Agre
Agree with Dave on atomic ops being bad on the reader side.
What about following schema:
As bucket is just u64 value on the reader side we grab bucket before (b0) and
after (b1) search operation.
If search finds entry, we simply do 2 checks:
- that b0 is equal to b1
- that lock bit is not se
Dear Nick,
As the code comment suggests, we tiptoe right up to the line to extract
performance. Have you tried e.g. ISOLCPUS, thread priority, or some other
expedients to make the required assumptions true?
It’s easy enough to change the code in various ways so this use-case cannot
backf
10 matches
Mail list logo
