svn commit: r354977 - in head: share/man/man3 sys/sys tests/sys/sys

[Keller, Jacob E]

On Thu, 2019-11-21 at 13:34 -0800, Eric Joyner wrote:
> On Thu, Nov 21, 2019 at 12:07 PM Conrad Meyer <cem at freebsd.org>
> wrote:
> > Hi Eric,
> > 
> > On Thu, Nov 21, 2019 at 11:58 AM Eric Joyner <erj at freebsd.org>
> > wrote:
> > >
> > > Author: erj
> > > Date: Thu Nov 21 19:57:56 2019
> > > New Revision: 354977
> > > URL: https://svnweb.freebsd.org/changeset/base/354977
> > >
> > > Log:
> > >   bitstring: add functions to find contiguous set/unset bit
> > sequences
> > >
> > >   Add bit_ffs_area_at and bit_ffc_area_at functions for searching
> > a bit
> > >   string for a sequence of contiguous set or unset bits of at
> > least the
> > >   specified size.
> > >
> > >   The bit_ffc_area function will be used by the Intel ice driver
> > for
> > >   implementing resource assignment logic using a bitstring to
> > represent
> > >   whether or not a given index has been assigned or is currently
> > free.
> > 
> > I don't know what the ice driver is/does, so apologies if this is
> > nonsensical.  Would it make more sense to use vmem(9) for this
> > purpose?  It's a general-purpose resource allocator and can scale
> > well
> > with large numbers of resources / CPUs.
> > 
> > Best,
> > Conrad
> 

Eric already added the review link for the ice driver, which we
recently published. I'm currently going through review comments and
preeparing an update.

We use a bit string as a method of determining which index numbers have
been assigned.

> +Jake
> 
> Hi Conrad,
> 
> It doesn't seem nonsensical; this seems like it would vaguely be an
> ok fit. But one issue
> I find after looking at it is that it doesn't support the "scattered"
> allocations that we need; for some types of 
> hardware queues we need to be able to group together multiple non-
> sequential allocations into one single block,
> and it doesn't look like we could do that without having to add
> another layer on top of vmem.
> 

I don't know much about vmem.. it might be suitable for our purposes,
but it does sound like a bit overkill for what we do.

I'll try to do a review of the vmem interfaces to see if it makes
sense.

> As well, it looks like it's kind of overbuilt for what we need; we
> only need a few operations. It also seems to import
> a bunch of stuff in its headers, which might complicate using it in
> our unit test code.
> 
> If you want to look at the current structure we use, you can look at
> the ice_pf_qmgr.[ch] files in this Phabricator
> review that introduces ice(4) to the kernel: 
> https://reviews.freebsd.org/D21959.
> 
> - Eric

Yes, we'd definitely appreciate review of the ice device driver code.

Thanks,
Jake