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

[Stanislav Fomichev <stfomichev@gmail.com>]

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.