lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 2 Dec 2021 09:31:29 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Shay Drory <shayd@...dia.com>
Cc:     "David S . Miller" <davem@...emloft.net>, <jiri@...dia.com>,
        <saeedm@...dia.com>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 0/4] net/mlx5: Memory optimizations

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:  
> >>   - 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.  
> > Why is something allocated in host memory a device resource? 🤔  
> 
> 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 driver.
> 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?  
> 
> 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ