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

Message-ID: <20150424164226.GB9305@obsidianresearch.com>
Date:	Fri, 24 Apr 2015 10:42:26 -0600
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	Liran Liss <liranl@...lanox.com>
Cc:	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"ira.weiny" <ira.weiny@...el.com>,
	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>, Doug Ledford <dledford@...hat.com>
Subject: Re: [PATCH v5 00/27] IB/Verbs: IB Management Helpers

On Fri, Apr 24, 2015 at 03:00:15PM +0000, Liran Liss wrote:

> Currently, the only code in the kernel that has an SMI interface is IB.
> When OPA is introduced, add the proper helper.

We already have tests checking for SMI is supported so QP0 can be
created, this is to support ROCEE
 
> All I am saying is that there will always be code paths that are
> technology- and standards-specific.  For example, the low-level MAD
> processing code *must* do stuff like:

> if (rdma_is_transport_ib())
> 	/* IB-spec compliant stuff */
> else if (rdma_is_transport_opa())
> 	/* OPA stuff */

Why should we open code that? It is back to what I said - that doesn't
help the reader. Which of the few differences between OPA and IB MADs
is that code trying to deal with?

Heck, what are the differences? Do you know? Do I know?

If you don't know what the differences are, you can't realistically
work on the MAD layer anymore, because you might break OPA.

Whereas, If I see:

if (cap_2k_mad())
 /* Special handling for OPA 2k mad support */
if (cap_opa_mad_space() && mad->baseVersion == ... )
 /* Decode OPA mads */
if (cap_ib_mad_space() && mad->baseVersion == ... )
 /* Decode IB mads */

The I *know* what to look for when writing new code.

That is the problem we are trying to address here. iWarp has already
created it, we addressed it using 'rdma_is_transport_iwarp' and I
don't think those results were very satisfying.

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