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:
 <DM6PR12MB4313D576318921D47B3C61B5BDA42@DM6PR12MB4313.namprd12.prod.outlook.com>
Date: Mon, 24 Mar 2025 21:28:17 +0000
From: Sean Hefty <shefty@...dia.com>
To: 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>,
	"bmt@...ich.ibm.com" <bmt@...ich.ibm.com>, "winston.liu@...sight.com"
	<winston.liu@...sight.com>, "dan.mihailescu@...sight.com"
	<dan.mihailescu@...sight.com>, "kheib@...hat.com" <kheib@...hat.com>,
	"parth.v.parikh@...sight.com" <parth.v.parikh@...sight.com>,
	"davem@...hat.com" <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>, "pabeni@...hat.com" <pabeni@...hat.com>
Subject: 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.

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