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

Message-ID: <20150427191030.GA5347@phlsvsds.ph.intel.com>
Date:	Mon, 27 Apr 2015 15:10:31 -0400
From:	"ira.weiny" <ira.weiny@...el.com>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc:	Liran Liss <liranl@...lanox.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>, Doug Ledford <dledford@...hat.com>
Subject: Re: [PATCH v5 00/27] IB/Verbs: IB Management Helpers

On Fri, Apr 24, 2015 at 10:42:26AM -0600, Jason Gunthorpe wrote:
> 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 */

The issue is that opa is _not_ a new "transport".  It is just like RoCEE which
supports the IB transport with some differences.

We need a way to explain what those differences are while keeping each section
of code as clean and clear as possible.  Many of us have spent a lot of time
trying to figure out what each section of the current code is doing when they
call "get_transport" and/or "get_link_layer".

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

FWIW we decided not to special case 2K and simply provide the max MAD size
which a driver supports.  This is much more flexible.  I think the semantics
are equivalent to your example here but I don't think we need a discussion
around a "cap_2k_mad" helper.

> if (cap_opa_mad_space() && mad->baseVersion == ... )
>  /* Decode OPA mads */
> if (cap_ib_mad_space() && mad->baseVersion == ... )
>  /* Decode IB mads */

Agreed.

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

No they are not and it is getting more complicated.

Ira

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