netdev - Re: [PATCH v5 0/8] Introduce fwctl subystem

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z9FjJAgdmWcepxkg@mini-arch>
Date: Wed, 12 Mar 2025 03:34:12 -0700
From: Stanislav Fomichev <stfomichev@...il.com>
To: David Ahern <dsahern@...nel.org>
Cc: Leon Romanovsky <leon@...nel.org>, Jason Gunthorpe <jgg@...dia.com>,
	Saeed Mahameed <saeed@...nel.org>, Jiri Pirko <jiri@...nulli.us>,
	Jakub Kicinski <kuba@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andy Gospodarek <andrew.gospodarek@...adcom.com>,
	Aron Silverton <aron.silverton@...cle.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Dave Jiang <dave.jiang@...el.com>,
	Christoph Hellwig <hch@...radead.org>,
	Itay Avraham <itayavr@...dia.com>, Jiri Pirko <jiri@...dia.com>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	Leonid Bloch <lbloch@...dia.com>, linux-cxl@...r.kernel.org,
	linux-rdma@...r.kernel.org, netdev@...r.kernel.org,
	Saeed Mahameed <saeedm@...dia.com>,
	"Nelson, Shannon" <shannon.nelson@....com>
Subject: Re: [PATCH v5 0/8] Introduce fwctl subystem

On 03/12, David Ahern wrote:
> On 3/11/25 2:59 PM, Leon Romanovsky wrote:
> > On Tue, Mar 11, 2025 at 12:23:19PM +0100, David Ahern wrote:
> >> On 3/6/25 12:21 AM, Jason Gunthorpe wrote:
> >>> On Wed, Mar 05, 2025 at 12:41:35PM -0800, Saeed Mahameed wrote:
> >>>
> >>>> How do you imagine this driver/core structure should look like? Who
> >>>> will be the top dir maintainer?
> >>>
> >>> I would set something like this up more like DRM. Every driver
> >>> maintainer gets commit rights, some rules about no uAPIs, or at least
> >>> other acks before merging uAPI. Use the tree for staging shared
> >>> branches.
> >>
> >> why no uapi? Core driver can have knowledge of h/w resources across all
> >> use cases. For example, our core driver supports a generid netlink based
> >> dump (no set operations; get and dump only so maybe that should be the
> >> restriction?) of all objects regardless of how created -- netdev, ib,
> >> etc. -- and with much more detail.
> > 
> > Because, we want to make sure that UAPI will be aligned with relevant
> > subsystems without any way to bypass them.
> > 
> > Thanks
> 
> I hope there will be an open mind on get / dump style introspection apis
> here. Devices can work support and work within limited subsystem APIs
> and also allow the dumping of full essential and relevant contexts for a
> device.

[..]

> More specifically, I do not see netdev APIs ever recognizing RDMA
> concepts like domains and memory regions. For us, everything is relative
> to a domain and a region - e.g., whether a queue is created for a netdev
> device or an IB QP both use the same common internal APIs.  I would
> prefer not to use fwctl for something so basic.

What specifically do you mean here by 'memory regions'? Netdev does
recognize (as of recently, devmem) the concept of memory regions in
the form of dmabufs.