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:
 <BN8PR15MB25131FB51A63577B5795614399A72@BN8PR15MB2513.namprd15.prod.outlook.com>
Date: Tue, 25 Mar 2025 13:22:04 +0000
From: Bernard Metzler <BMT@...ich.ibm.com>
To: Sean Hefty <shefty@...dia.com>, Roland Dreier <roland@...abrica.net>,
        Jason Gunthorpe <jgg@...dia.com>
CC: 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>,
        "ian.ziemba@....com" <ian.ziemba@....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



> -----Original Message-----
> From: Sean Hefty <shefty@...dia.com>
> Sent: Monday, March 24, 2025 10:28 PM
> To: Roland Dreier <roland@...abrica.net>; Jason Gunthorpe <jgg@...dia.com>
> Cc: Nikolay Aleksandrov <nikolay@...abrica.net>; netdev@...r.kernel.org;
> shrijeet@...abrica.net; alex.badea@...sight.com; eric.davis@...adcom.com;
> rip.sohan@....com; dsahern@...nel.org; Bernard Metzler
> <BMT@...ich.ibm.com>; winston.liu@...sight.com;
> dan.mihailescu@...sight.com; Kamal Heib <kheib@...hat.com>;
> parth.v.parikh@...sight.com; Dave Miller <davem@...hat.com>;
> ian.ziemba@....com; andrew.tauferner@...nelisnetworks.com; welch@....com;
> rakhahari.bhunia@...sight.com; kingshuk.mandal@...sight.com; linux-
> rdma@...r.kernel.org; kuba@...nel.org; Paolo Abeni <pabeni@...hat.com>
> Subject: [EXTERNAL] RE: [RFC PATCH 00/13] Ultra Ethernet driver
> introduction
> 
> > I think the netlink API and job handling overall is the area where the
> most
> > discussion is probably required. UE is somewhat novel in elevating the
> concept
> > of a "job" to a standard object with specific properties that determine
> the
> > values in packet headers. But I'm open to making "job" a top-level RDMA
> > object... I guess the idea would be to define an interface for creating a
> new
> > type of "job FD" with a standard ABI for setting properties?
> 
> I view a job as scoped by a network address, versus a system global object.
> So, I was looking at a per device scope, though I guess a per port (similar
> to a pkey) is also possible.  My reasoning was that a device _may_ need to
> allocate some per job resource.  Per device job objects could be configured
> to have the same 'job address', for an indirect association.
> 


If I understand UEC's job semantics correctly, then the local scope
of a job may span multiple local ports from multiple local devices.
It would of course translate into device specific reservations.

> I considered using an fd to share a job object between processes; however,
> sharing was restricted per device.
> 
> I believe a job may be associated with other security objects (e.g.
> encryption) which may also need per device allocations and state tracking.
> 
> - Sean