From: Thomas Monjalon <thomas@monjalon.net>
To: anatoly.burakov@intel.com
Cc: dev@dpdk.org, Vipin P R <vipinp@vmware.com>,
david.marchand@redhat.com, bruce.richardson@intel.com
Subject: Re: [PATCH 0/2] *** Memory Allocation: Fixes ignore_msk during find_next_n() in fb_array library***
Date: Mon, 20 Feb 2023 12:03:44 +0100 [thread overview]
Message-ID: <11332268.F0gNSz5aLb@thomas> (raw)
In-Reply-To: <1673615669-21011-1-git-send-email-vipinp@vmware.com>
Anatoly, please could you look at this?
13/01/2023 14:14, Vipin P R:
> ***
> In the lookahead logic, let's say after the Right-Shift-And operation to check for contiguity, we hit case http://code.dpdk.org/dpdk/latest/source/lib/eal/common/eal_common_fbarray.c#L235
>
> /* if first bit is not set, we've lost the run */
> if ((lookahead_msk & 1) == 0) {
> /*
> * we've scanned this far, so we know there are
> * no runs in the space we've lookahead-scanned
> * as well, so skip that on next iteration.
> */
> ignore_msk = ~((1ULL << need) - 1);
> msk_idx = lookahead_idx;
> break;
> }
> lets say for mask size of 64 bits : in msk_idx 4 we need 4 consecutive bits.
> let need = 4.
> lets say some of the bits starting from LSB are xx11011.
> Operating on the inverted mask for better clarity. RSA - RightShiftAnd, xx -- don't-care bits before
>
> This condition could hit if there aren't "need" number of contiguous bits starting from LSB.
> But, that doesn't necessarily mean there aren't "need" number of such bits elsewhere in the same lookahead_idx.
> We seem to be ignoring "need" number of bits starting from the LSB for the next iteration.
>
> Due to ignore_mask we might end losing some bits.
> /* if we have an ignore mask, ignore once */
> if (ignore_msk) {
> cur_msk &= ignore_msk;
> ignore_msk = 0;
> }
> e.g.
> lookahead_msk before RSA logic : xx11100 , need = 4, 2 bits lost
> lookahead_msk before RSA logic : xx11011, need = 4, 1 bit lost
> lookahead_msk before RSA logic : xx11110, need = 4, 3 bits lost
>
> NB : To understand the number of bits lost, look at need; that's the number of bits (starting from LSB) that's cleared to zero before the next iteration.
> ***
>
> Vipin P R (2):
> Memory Allocation: Fixes ignore_msk during find_next_n() in fb_array
> library
> Memory Allocation: Alternative fix for ignore_msk during find_next_n()
> in fb_array library
>
> lib/eal/common/eal_common_fbarray.c | 26 +++++++++++++++++++++++---
> 1 file changed, 23 insertions(+), 3 deletions(-)
>
>
prev parent reply other threads:[~2023-02-20 11:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-13 13:14 Vipin P R
2023-01-13 13:14 ` [PATCH 1/2] Memory Allocation: Fixes ignore_msk during find_next_n() in fb_array library Vipin P R
2023-05-19 16:23 ` Burakov, Anatoly
2023-01-13 13:14 ` [PATCH 2/2] Memory Allocation: Alternative fix for " Vipin P R
2023-05-19 16:45 ` Burakov, Anatoly
2023-05-22 5:12 ` Vipin P R
2023-02-20 11:03 ` Thomas Monjalon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=11332268.F0gNSz5aLb@thomas \
--to=thomas@monjalon.net \
--cc=anatoly.burakov@intel.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=vipinp@vmware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).