Re: git: 60381fd1ee86 - main - memdesc: Retire MEMDESC_CCB.

From: Warner Losh <imp_at_bsdimp.com>
Date: Mon, 17 Jul 2023 18:20:04 UTC
On Mon, Jul 17, 2023 at 12:11 PM John Baldwin <jhb@freebsd.org> wrote:

> On 7/17/23 11:07 AM, Warner Losh wrote:
> > On Mon, Jul 17, 2023 at 12:02 PM John Baldwin <jhb@freebsd.org> wrote:
> >
> >> On 7/17/23 10:58 AM, Warner Losh wrote:
> >>> On Mon, Jul 17, 2023 at 11:54 AM Konstantin Belousov <
> >> kostikbel@gmail.com>
> >>> wrote:
> >>> Or if it was in cam.h and made a static inline. It's short enough that
> >>> won't bloat
> >>> the kernel in the half a dozen places its called, and it would give
> >> similar
> >>> performance
> >>> to what we have today with the half a dozen nearly identical copies of
> >>> this routine.
> >>> And since it's all done with structure dancing, there's no other bits
> of
> >>> CAM that would
> >>> be brought into the kernel.
> >>
> >> I would be happy with an inline actually, I wasn't sure originally if
> that
> >> was
> >> too invasive in terms of the header bloat it would entail, in particular
> >> if it
> >> lived in sys/memdesc.h, but maybe it could live in cam_ccb.h?
> >>
> >
> > cam_ccb.h likely is fine, and logically it does belong there more than
> cam.h
> > now that you mention it...  And only sys/kern/subr_bus_dma.c needs it,
> > since that's the only place that calls if my grep can be believed.
>
> I use it in my NVMeoF host, but that is also already including cam_ccb.h
> since
> it needs to know about CCB internals anyway.
>

Yea, that sounds like 2 copies in memory of a routine that's kinda small
and might
be worth the performance improvement with fewer function calls (and even if
it not,
the hundred or so bytes is a small price to fix this issue, and we do way
worse for
much flimsier reasons elsewhere in the kernel).

Warner