From: Liran Liss <liranl@mellanox.com>
To: "Hefty, Sean" <sean.hefty@intel.com>, "Weiny, Ira" <ira.weiny@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>
CC: Michael Wang <yun.wang@profitbricks.com>,
        Roland Dreier <roland@kernel.org>,
        Hal Rosenstock <hal.rosenstock@gmail.com>,
        "hal@dev.mellanox.co.il" <hal@dev.mellanox.co.il>,
        Tom Tucker <tom@opengridcomputing.com>,
        Steve Wise <swise@opengridcomputing.com>,
        Hoang-Nam Nguyen <hnguyen@de.ibm.com>,
        "raisch@de.ibm.com" <raisch@de.ibm.com>,
        infinipath <infinipath@intel.com>, Eli Cohen <eli@mellanox.com>,
        "Latif, Faisal" <faisal.latif@intel.com>,
        "Jack Morgenstein" <jackm@dev.mellanox.co.il>,
        Or Gerlitz <ogerlitz@mellanox.com>, Haggai Eran <haggaie@mellanox.com>,
        Tom Talpey <tom@talpey.com>,
        "Jason Gunthorpe" <jgunthorpe@obsidianresearch.com>,
        Doug Ledford <dledford@redhat.com>
Subject: RE: [PATCH v5 00/27] IB/Verbs: IB Management Helpers
Thread-Topic: [PATCH v5 00/27] IB/Verbs: IB Management Helpers
Thread-Index: AQHQe0QWgYjx3AmeeEu2Ae1BasUTY51YB1mAgABNxACAAOqHgIAC/1Rw
Date: Fri, 24 Apr 2015 14:49:49 +0000
Message-ID: <DB4PR05MB0863B7122F8FD7EFA4A80A9AB1EC0@DB4PR05MB0863.eurprd05.prod.outlook.com>
References: <5534B8C9.506@profitbricks.com>
 <DB4PR05MB0863E9CCCD1BEA34F244EE2CB1EF0@DB4PR05MB0863.eurprd05.prod.outlook.com>
 <20150422024123.GA18675@phlsvsds.ph.intel.com>
 <1828884A29C6694DAF28B7E6B8A82373A8FC64BD@ORSMSX109.amr.corp.intel.com>
In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373A8FC64BD@ORSMSX109.amr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2015 14:49:49.2530
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR05MB445
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by nfs id t3OEo55R001410
Content-Length: 1721
Lines: 44

> From: Hefty, Sean [mailto:sean.hefty@intel.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()

????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?