Re: [RFC PATCH 00/13] Ultra Ethernet driver introduction

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Apr 01, 2025 at 04:57:52PM +0000, Sean Hefty wrote:
> > > Specifically, I want to *allow* separating the different functions
> > > that a single PD provides into separate PDs.  The functions being page
> > > mapping (registration), local (lkey) access, and remote (rkey) access.
> > 
> > That seems like quite a stretch for the PD.. Especially from a verbs perspective
> > we do expect single PD and that is the entire security context.
> 
> From the viewpoint of a transport, the target QPN and incoming rkey
> must align on some backing security object (let's call that the PD).
> As a model, I view this as there needs to exist some {QPN, rkey, PD
> ID} tuple with appropriate memory access permissions.

Yes, but I'd say the IBTA modeling has the network headers select a PD
and then the PD limits what objects that packet can reach.

I still think that is a good starting point, and if there is more fine
grained limitations then I'd say each object has an additional ACL
list about what subset of the network headers (already within the PD)
that it can accept.

> The change here is to expand that tuple to include a job id: {QPN, rkey, job ID, PD ID}.

IB does QPN -> PD, if you do Job -> PD I think that would make
sense. If the QP is providing additional restriction that would be a
job for ACLs..

> I don't know that I can talk about the UEC spec, 

Right, it is too early to talk about UEC and Linux until people can
freely talk about what it actually needs.

> I can envision a job manager creating, sharing, and possibly
> controlling the PD-related resources.

Really? Beyond Job, what would make sense? Addressing Handles?

I wondering if addressing handles are really part of the job..

Jason