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

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <c1b9d002-85f5-420e-b452-d6f2a11720d4@hpe.com>
Date: Mon, 7 Apr 2025 14:32:34 -0500
From: "Ziemba, Ian" <ian.ziemba@....com>
To: Sean Hefty <shefty@...dia.com>, Jason Gunthorpe <jgg@...dia.com>
CC: Bernard Metzler <BMT@...ich.ibm.com>,
        Roland Dreier
	<roland@...abrica.net>,
        Nikolay Aleksandrov <nikolay@...abrica.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "shrijeet@...abrica.net"
	<shrijeet@...abrica.net>,
        "alex.badea@...sight.com"
	<alex.badea@...sight.com>,
        "eric.davis@...adcom.com"
	<eric.davis@...adcom.com>,
        "rip.sohan@....com" <rip.sohan@....com>,
        "dsahern@...nel.org" <dsahern@...nel.org>,
        "winston.liu@...sight.com"
	<winston.liu@...sight.com>,
        "dan.mihailescu@...sight.com"
	<dan.mihailescu@...sight.com>,
        Kamal Heib <kheib@...hat.com>,
        "parth.v.parikh@...sight.com" <parth.v.parikh@...sight.com>,
        Dave Miller
	<davem@...hat.com>,
        "andrew.tauferner@...nelisnetworks.com"
	<andrew.tauferner@...nelisnetworks.com>,
        "welch@....com" <welch@....com>,
        "rakhahari.bhunia@...sight.com" <rakhahari.bhunia@...sight.com>,
        "kingshuk.mandal@...sight.com" <kingshuk.mandal@...sight.com>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "kuba@...nel.org"
	<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [RFC PATCH 00/13] Ultra Ethernet driver introduction

> There's also the MR relationship:
> 
> Job <- 1 --- 0..n -> MR <- 0..n --- 1 -> PD

Current UE memory registration is centered around the libfabric
FI_MR_ENDPOINT mode which states memory regions are associated with an
endpoint instead of libfabric domain. For remotely accessible UE MRs,
this translates to the following.

- Relative Addressing: {job ID, endpoint, RKEY} identifies the MR.

- Absolute Addressing: {endpoint, RKEY} identifies the MR with optional
  MR job-ID access control check.

In addition, UE memory registration supports user-defined RKEYs. This
enables programming model implementations the optimization to use
well-known per process endpoint RKEYs. For relative addressing, this
could result in the same RKEY value existing multiple times at the
{job ID} level, but only once at the {job ID, endpoint} level.

The UE remote MR relationship would look like:

Job <- 1 --- 0..n -> EP <- 0..n ---------------------- 1 -> PD
                      ^                                      ^
                      |--- 1 --- 0..n -> MR <- 0..n --- 1 ---|

> There's discussion on defining this relationship:
> 
> Job <- 0..n --- 1 -> PD
> 
> I can't think of a technical reason why that's needed.

>From my UE perspective, I agree. UE needs to share job IDs across
processes while still having inter-process isolation for things like
local memory registrations.

Thanks,

Ian