From: Bruce Richardson <bruce.richardson@intel.com>
To: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
Cc: Thomas Monjalon <thomas@monjalon.net>,
Volodymyr Fialko <vfialko@marvell.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"jerinj@marvell.com" <jerinj@marvell.com>,
"anoobj@marvell.com" <anoobj@marvell.com>
Subject: Re: [PATCH] bitmap: add scan init at given position
Date: Thu, 8 Jun 2023 15:50:45 +0100 [thread overview]
Message-ID: <ZIHqxUgZK9LK8a7x@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <DS0PR11MB74425562DF55B0A2300A88B6EB50A@DS0PR11MB7442.namprd11.prod.outlook.com>
On Thu, Jun 08, 2023 at 02:20:13PM +0000, Dumitrescu, Cristian wrote:
> Hi Volodymyr,
>
> Thanks for your patch, comments below under your code:
>
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Sent: Thursday, June 1, 2023 4:26 PM
> > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Volodymyr Fialko
> > <vfialko@marvell.com>
> > Cc: dev@dpdk.org; jerinj@marvell.com; anoobj@marvell.com
> > Subject: Re: [PATCH] bitmap: add scan init at given position
> >
> > Cristian, please could you review this patch?
> >
> > 14/04/2023 10:39, Volodymyr Fialko:
> > > Currently, in the case when we search for a bit set after a particular
> > > value, the bitmap has to be scanned from the beginning and
> > > rte_bitmap_scan() has to be called multiple times until we hit the value.
> > >
> > > Add a new __rte_bitmap_scan_init_at() function to initialize scan state at
> > > the given position, this will allow getting the next bit set after some
> > > value within one rte_bitmap_scan() call.
> > >
> > > Signed-off-by: Volodymyr Fialko <vfialko@marvell.com>
> > [...]
> > > +__rte_experimental
> > > +static inline void
> > > +__rte_bitmap_scan_init_at(struct rte_bitmap *bmp, uint32_t pos)
> > > +{
> > > + bmp->index1 = pos >> (RTE_BITMAP_SLAB_BIT_SIZE_LOG2 +
> > RTE_BITMAP_CL_BIT_SIZE_LOG2);
> > > + bmp->offset1 = (pos >> RTE_BITMAP_CL_BIT_SIZE_LOG2) &
> > RTE_BITMAP_SLAB_BIT_MASK;
> > > + bmp->index2 = pos >> RTE_BITMAP_SLAB_BIT_SIZE_LOG2;
> > > + bmp->go2 = 1;
> > > +}
> >
> > It is supposed to be an internal (inlined) function
> > but it is not used.
> >
>
> My understanding is your proposed procedure for scanning starting at an offset is:
> 1. Call the new function: __rte_bitmap_scan_init_at()
> 2. Call the regular function: rte_bitmap_scan()
>
> I think this procedure is not ideal, therefore I suggest we create a new API function which has an additional offset argument:
>
> rte_bitmap_scan_from_offset(struct rte_bitmap *bmp, uint32_t offset, uint32_t *pos, uint64_t *slab).
>
> Under the hood, the new API should call an internal function similar to yours to start the scan at a given offset (while aborting any scan that might be in progress). Makes sense?
>
> BTW, do we need to declare the experimental functions defined in a header file to the library map file? I don't see this in the patch, but the patch seems to compile and link fine ...
>
Inline functions in headers are not real "functions" in the output code, as
they get inlined into the caller. Therefore, they have no entries in the
version.map file, since they don't exist in the compiled object code.
/Bruce
next prev parent reply other threads:[~2023-06-08 14:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-14 8:39 Volodymyr Fialko
2023-06-01 15:26 ` Thomas Monjalon
2023-06-08 14:20 ` Dumitrescu, Cristian
2023-06-08 14:50 ` Bruce Richardson [this message]
2023-06-12 10:58 ` Volodymyr Fialko
2023-06-13 15:40 ` [PATCH v2] bitmap: add scan from offset function Volodymyr Fialko
2023-06-19 11:30 ` Dumitrescu, Cristian
2023-06-21 10:01 ` [PATCH v3] " Volodymyr Fialko
2023-06-21 10:37 ` Dumitrescu, Cristian
2023-06-22 17:44 ` Thomas Monjalon
2023-06-23 12:40 ` Dumitrescu, Cristian
2023-07-03 10:56 ` Volodymyr Fialko
2023-07-03 11:51 ` Thomas Monjalon
2023-07-03 12:02 ` [EXT] " Volodymyr Fialko
2023-07-03 12:17 ` Thomas Monjalon
2023-07-03 9:31 ` [PATCH v4] " Volodymyr Fialko
2023-07-03 10:54 ` Dumitrescu, Cristian
2023-07-03 12:39 ` [PATCH v5] " Volodymyr Fialko
2023-07-03 13:01 ` Dumitrescu, Cristian
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=ZIHqxUgZK9LK8a7x@bricha3-MOBL.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=anoobj@marvell.com \
--cc=cristian.dumitrescu@intel.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=thomas@monjalon.net \
--cc=vfialko@marvell.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).