linux-kernel - RE: [PATCH v5 00/27] IB/Verbs: IB Management Helpers

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: <1828884A29C6694DAF28B7E6B8A82373A8FC64BD@ORSMSX109.amr.corp.intel.com>
Date:	Wed, 22 Apr 2015 16:40:49 +0000
From:	"Hefty, Sean" <sean.hefty@...el.com>
To:	"Weiny, Ira" <ira.weiny@...el.com>,
	Liran Liss <liranl@...lanox.com>
CC:	Michael Wang <yun.wang@...fitbricks.com>,
	Roland Dreier <roland@...nel.org>,
	Hal Rosenstock <hal.rosenstock@...il.com>,
	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"hal@....mellanox.co.il" <hal@....mellanox.co.il>,
	Tom Tucker <tom@...ngridcomputing.com>,
	Steve Wise <swise@...ngridcomputing.com>,
	Hoang-Nam Nguyen <hnguyen@...ibm.com>,
	"raisch@...ibm.com" <raisch@...ibm.com>,
	infinipath <infinipath@...el.com>, Eli Cohen <eli@...lanox.com>,
	"Latif, Faisal" <faisal.latif@...el.com>,
	"Jack Morgenstein" <jackm@....mellanox.co.il>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	Haggai Eran <haggaie@...lanox.com>,
	Tom Talpey <tom@...pey.com>,
	"Jason Gunthorpe" <jgunthorpe@...idianresearch.com>,
	Doug Ledford <dledford@...hat.com>
Subject: RE: [PATCH v5 00/27] IB/Verbs: IB Management Helpers

> > So, I think that our "old-transport" below is just fine.
> > No need to change it (and you aren't, since it is currently implemented
> as a function).
> 
> I think there is a need to change this.  Encoding the transport into the
> node
> type is not a good idea.  Having different "transport semantics" while
> still
> returning the same transport for the port is confusing.
> 
> The only thing which is clear currently is Link Layer.
> 
> But the use of "Link Layer" in the code is so convoluted that it is very
> confusing.

I agree.

One could implement software iWarp or IBoUDP (RoCEv2) protocols that could run over any link layer and interoperate with existing HW solutions.  The stack shouldn't be dealing with the link level at all, with the exception of user space compatibility.

> Define Transport?  There has been a lot of discussion over what a
> transport is
> in Verbs.

IMO, we should replace using the word 'transport' with just 'rdma_protocol'.  And even then I'm not convinced that anything should care, beyond user space compatibility.  The caps are what matter.

- Sean