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: <DB4PR05MB0863B7122F8FD7EFA4A80A9AB1EC0@DB4PR05MB0863.eurprd05.prod.outlook.com>
Date:	Fri, 24 Apr 2015 14:49:49 +0000
From:	Liran Liss <liranl@...lanox.com>
To:	"Hefty, Sean" <sean.hefty@...el.com>,
	"Weiny, Ira" <ira.weiny@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>
CC:	Michael Wang <yun.wang@...fitbricks.com>,
	Roland Dreier <roland@...nel.org>,
	Hal Rosenstock <hal.rosenstock@...il.com>,
	"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

> From: Hefty, Sean [mailto:sean.hefty@...el.com]

[snip]
> > > 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

I completely agree.
If we ever see a need for representing a set or subset of cross-layer protocols (at any level, L2-L4, various encapsulations), we will add the proper management helpers.
For example:
- rdma_protocol_roce() /* both v1 and v2 */
- rdma_protocol_roce_v1()
- rdma_protocol_roce_v2()
- rdma_protocol_usnic()
- rdma_protocol_usnic_udp()