Date:   Thu, 2 Dec 2021 09:31:29 -0800
From:   Jakub Kicinski <kuba@kernel.org>
To:     Shay Drory <shayd@nvidia.com>
Cc:     "David S . Miller" <davem@davemloft.net>, <jiri@nvidia.com>,
        <saeedm@nvidia.com>, <netdev@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next 0/4] net/mlx5: Memory optimizations
Message-ID: <20211202093129.2713b64f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
In-Reply-To: <879d6d7c-f789-69bc-9f2d-bf77d558586a@nvidia.com>
References: <20211130150705.19863-1-shayd@nvidia.com>
 <20211130113910.25a9e3ab@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
 <879d6d7c-f789-69bc-9f2d-bf77d558586a@nvidia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, 1 Dec 2021 10:22:17 +0200 Shay Drory wrote:
> On 11/30/2021 21:39, Jakub Kicinski wrote:
> > On Tue, 30 Nov 2021 17:07:02 +0200 Shay Drory wrote: =20
> >>   - Patch-1 Provides I/O EQ size resource which enables to save
> >>     up to 128KB.
> >>   - Patch-2 Provides event EQ size resource which enables to save up to
> >>     512KB. =20
> > Why is something allocated in host memory a device resource? =F0=9F=A4=
=94 =20
>=20
> EQ resides in the host memory. It is RO for host driver, RW by device.
> When interrupt is generated EQ entry is placed by device and read by driv=
er.
> It indicates about what event occurred such as CQE, async and more.

I understand that. My point was the resource which is being consumed
here is _host_ memory. Is there precedent for configuring host memory
consumption via devlink resource?

I'd even question whether this belongs in devlink in the first place.
It is not global device config in any way. If devlink represents the
entire device it's rather strange to have a case where main instance
limits a size of some resource by VFs and other endpoints can still
choose whatever they want.

> > Did you analyze if others may need this? =20
>=20
> So far no feedback by other vendors.
> The resources are implemented in generic way, if other vendors would
> like to implement them.

Well, I was hoping you'd look around, but maybe that's too much to ask
of a vendor.