Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S966711AbbDVQk7 (ORCPT <rfc822;w@1wt.eu>);
	Wed, 22 Apr 2015 12:40:59 -0400
Received: from mga02.intel.com ([134.134.136.20]:41519 "EHLO mga02.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S966695AbbDVQkw (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 22 Apr 2015 12:40:52 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.11,624,1422950400"; 
   d="scan'208";a="699260595"
From: "Hefty, Sean" <sean.hefty@intel.com>
To: "Weiny, Ira" <ira.weiny@intel.com>, Liran Liss <liranl@mellanox.com>
CC: Michael Wang <yun.wang@profitbricks.com>,
        Roland Dreier <roland@kernel.org>,
        Hal Rosenstock <hal.rosenstock@gmail.com>,
        "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "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: AQHQe0QQ0Q91AMGo0kiEmbfJYbtAQ51YltgAgAAznQCAAHRP0A==
Date: Wed, 22 Apr 2015 16:40:49 +0000
Message-ID: <1828884A29C6694DAF28B7E6B8A82373A8FC64BD@ORSMSX109.amr.corp.intel.com>
References: <5534B8C9.506@profitbricks.com>
 <DB4PR05MB0863E9CCCD1BEA34F244EE2CB1EF0@DB4PR05MB0863.eurprd05.prod.outlook.com>
 <20150422024123.GA18675@phlsvsds.ph.intel.com>
In-Reply-To: <20150422024123.GA18675@phlsvsds.ph.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.139]
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
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 t3MGf4rD022425
Content-Length: 1256
Lines: 28

> > 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

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