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
>
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
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
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:
>
>
>
Hello All,
I am having an issue with the new VPP version 21.10 because of some header
files missing.
The issue was fixed in master a few days ago [0], but it is still present in
the tag v21.10, so
I cherry-picked the change and created a patch for the branch stable/2110 [1].
Is it possible to
Pankaj,
> In file vnet/ip/ip6_forward.c(VPP 21.01), function ip6_local_inline(),
> the node's packet processing has the following check:
>
> if (PREDICT_FALSE (need_csum))
> {
> flags = ip6_tcp_udp_icmp_validate_checksum (vm, b[0]);
>
