From: Vipin P R <vipinp@vmware.com>
To: anatoly.burakov@intel.com
Cc: dev@dpdk.org, Vipin P R <vipinp@vmware.com>
Subject: [PATCH 0/2] *** Memory Allocation: Fixes ignore_msk during find_next_n() in fb_array library***
Date: Fri, 13 Jan 2023 13:14:27 +0000 [thread overview]
Message-ID: <1673615669-21011-1-git-send-email-vipinp@vmware.com> (raw)
***
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(-)
--
2.7.4
next reply other threads:[~2023-01-15 20:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-13 13:14 Vipin P R [this message]
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 ` [PATCH 0/2] *** Memory Allocation: Fixes ignore_msk during find_next_n() in fb_array library*** Thomas Monjalon
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=1673615669-21011-1-git-send-email-vipinp@vmware.com \
--to=vipinp@vmware.com \
--cc=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
/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).