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>] [day] [month] [year] [list]

Message-ID: <20150427205832.GC5347@phlsvsds.ph.intel.com>
Date:	Mon, 27 Apr 2015 16:58:33 -0400
From:	"ira.weiny" <ira.weiny@...el.com>
To:	Liran Liss <liranl@...lanox.com>
Cc:	Doug Ledford <dledford@...hat.com>,
	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Michael Wang <yun.wang@...fitbricks.com>,
	Roland Dreier <roland@...nel.org>,
	Sean Hefty <sean.hefty@...el.com>,
	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>,
	Mike Marciniszyn <infinipath@...el.com>,
	Eli Cohen <eli@...lanox.com>,
	Faisal Latif <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>
Subject: Re: [PATCH v5 00/27] IB/Verbs: IB Management Helpers

On Fri, Apr 24, 2015 at 02:53:37PM +0000, Liran Liss wrote:
> > From: ira.weiny [mailto:ira.weiny@...el.com]
> > [snip]
> > 
> > > >
> > > > 2)The name rdma_tech_* is lame.
> > > > rdma_transport_*(), adhering to the above (*) remark, is much better.
> > > > For example, both IB and ROCE *do* use the same transport.
> > >
> > > I especially want to second this.  I haven't really been happy with
> > > the
> > > rdma_tech_* names at all.
> > >
> > 
> > I am sure Michael is open to alternative names.  I know I am.  The problem is
> > that we can't figure out what "IBoE" is.  It is not a transport, even though
> > query_transport is now returning it as one.  :-P
> 
> IBOE is used in part of the kernel symbols that refer to RoCE. That's it.
> ROCE HCA links have the following characteristics:
> - Ethernet link layer
> - IB transport
> - CA node type
> 
> And, if needed in the future:
> - ROCEv1 and ROCEv2 protocol stacks

Let me rephrase that[*].

We don't know what to "call" "IBoE" vs "IBoIB" vs "iWarp Verbs over iWarp" vs
"IBoOPA", etc.

The problem with your argument (no matter what name we use, "Transport",
"tech", "protocol") etc is that support for various features are implied rather
than explicit.

Your argument that RoCE is just "IB transport" over Ethernet (while technically
correct) is not relevant for the problem we are trying to solve.

The ib_mad, ib_cm, rdma_cm, and ib_sa modules are attempting to support many
different device type (on a port basis).  The functionality they provide is
dependent on so much more that the notion of "transport" and "link layer".

The purpose of this patch series was to create the specific helper functions
based on the support the core modules need to explicitly determine what they
should do for a port.  Furthermore, the implementation of those features was to
be based on the current implementation (which happens to use the transport and
link layer) to ensure we don't break everything.

Once we could agree on items like the feature set and the names of the helper
calls we could then alter the implementation to remove the implied nature of
this support.

> 
> > 
> > I think the idea behind the "tech" name was that it is a technology "family".
> > I can't think of a better name.

I see "protocol" and "specification" being discussed.  Those are probably
decent.

Ira

[*] We all know what RoCE (IBoE) _is_...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/