From nobody Mon Jul 17 18:20:04 2023 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4R4Vk91JC0z4nqtj for ; Mon, 17 Jul 2023 18:20:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R4Vk90vmyz3NjP for ; Mon, 17 Jul 2023 18:20:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-51cff235226so10001845a12.0 for ; Mon, 17 Jul 2023 11:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1689618016; x=1692210016; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GtLHzIGNIexbYaVc7vAE90iDks3XGSLuvIK7UQ7+620=; b=oFP0EYm1+ZIJyl6PVd6/BbhYmzCDPRfIC1CwDEIsdSfoeztdLgv3JRrTZutTeZsupy AcZh3iB4W2IHCqASFV6wXU6WRtSvyNvHhcIYYKX48PRaeicXEN/fbIo+N2fQa3U/XWzz OXChzasnJyagCwxdByif0fGa+0Kd2ES9b9eN/E1ePxuEIY8YiD/vql7n3vG1bA8cZTsY 2s7mbEgyC9gYvemRYk4rwa3nbys4HEGkZSqFIslmYh2nFGWI2a4EZH2uwHUqPObTchqe bsgrK+F2UgEdNqFqsreAZV+6FpaSQ0QFeQSqQpP0ogFKyLTsFeMR5fxC+20P+QfHG1nE iLOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689618016; x=1692210016; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GtLHzIGNIexbYaVc7vAE90iDks3XGSLuvIK7UQ7+620=; b=Ro5iEarXb2123laWZ07pxHDfAI79PezwR+8jv7rBuCRZFs/DzXHEgCGQiUd/JvSaL+ QX/p1fQ1TQvhmyO6rSyrwGL8idquD376mTjZVXlZIMKRZOqy3sc35y2XBtRkSQ37qMft /KoguLpVHHmvDULqQgRqPmM367aQCZ8E5Ofsh2c55QlQHq6YpuIITrTD7G0nPAbHKp/+ n4ngtTdjy5Awhe8xWP4SFOmgJKPN884MOpQkzk1H61VJoHlGxQhr0YghGQbaWFrrquVh VdzoURBdOXoJ4QODfTdf65Fu9agW51Q6kV2jta2iJDiWXBYlnIJWDGW4W3ltLAqZ1yBf vdzw== X-Gm-Message-State: ABy/qLYBQE45F/eo2EGUXJ4XBtrZf0wGF63Qxex4CUohBuBgxCbNtsAd UKz3ASCEvzDgYNonHjH8vbezEdkRAA6LxDQWmUk592Yrh0weuu5nKWk= X-Google-Smtp-Source: APBJJlEFBnFqRs6Vx5jI/FizuzVrUgJqEOgadoTJooUtcaOpkI4+lyEgrHP6j2N1r5uSAu51Xvv7U3h/yFJf4KSRs0U= X-Received: by 2002:a05:6402:1857:b0:521:7667:3c7a with SMTP id v23-20020a056402185700b0052176673c7amr7698444edy.19.1689618015858; Mon, 17 Jul 2023 11:20:15 -0700 (PDT) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 References: <202307141841.36EIf3f0019403@gitrepo.freebsd.org> <65d7d8d8-9f98-abd2-1ce3-ae3a2d3bf111@FreeBSD.org> <92656b28-8bfa-23a9-2683-23ccb817b8a7@FreeBSD.org> <09687219-240b-c1a5-8e5a-956b231854d5@FreeBSD.org> In-Reply-To: <09687219-240b-c1a5-8e5a-956b231854d5@FreeBSD.org> From: Warner Losh Date: Mon, 17 Jul 2023 12:20:04 -0600 Message-ID: Subject: Re: git: 60381fd1ee86 - main - memdesc: Retire MEMDESC_CCB. To: John Baldwin Cc: Konstantin Belousov , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="000000000000a445b00600b2d9d1" X-Rspamd-Queue-Id: 4R4Vk90vmyz3NjP X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000a445b00600b2d9d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 17, 2023 at 12:11=E2=80=AFPM John Baldwin wro= te: > On 7/17/23 11:07 AM, Warner Losh wrote: > > On Mon, Jul 17, 2023 at 12:02=E2=80=AFPM John Baldwin = wrote: > > > >> On 7/17/23 10:58 AM, Warner Losh wrote: > >>> On Mon, Jul 17, 2023 at 11:54=E2=80=AFAM Konstantin Belousov < > >> kostikbel@gmail.com> > >>> wrote: > >>> Or if it was in cam.h and made a static inline. It's short enough tha= t > >>> 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 o= f > >>> 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 particul= ar > >> 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 --000000000000a445b00600b2d9d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 17, 2023 at 12:11=E2=80= =AFPM John Baldwin <jhb@freebsd.org> wrote:
On= 7/17/23 11:07 AM, Warner Losh wrote:
> On Mon, Jul 17, 2023 at 12:02=E2=80=AFPM John Baldwin <jhb@freebsd.org> wrote:
>
>> On 7/17/23 10:58 AM, Warner Losh wrote:
>>> On Mon, Jul 17, 2023 at 11:54=E2=80=AFAM Konstantin Belousov &= lt;
>> 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 c= opies 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 origin= ally if that
>> was
>> too invasive in terms of the header bloat it would entail, in part= icular
>> 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...=C2=A0 And only sys/kern/subr_bus_dma.c need= s 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 si= nce
it needs to know about CCB internals anyway.

Yea, that sounds like 2 copies in memory of a routine that's kind= a 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 flim= sier reasons elsewhere in the kernel).

Warner=C2= =A0
--000000000000a445b00600b2d9d1--