From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965073AbbD0TKq (ORCPT ); Mon, 27 Apr 2015 15:10:46 -0400 Received: from mga01.intel.com ([192.55.52.88]:19527 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751359AbbD0TKn (ORCPT ); Mon, 27 Apr 2015 15:10:43 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,658,1422950400"; d="scan'208";a="701702866" Date: Mon, 27 Apr 2015 15:10:31 -0400 From: "ira.weiny" To: Jason Gunthorpe Cc: Liran Liss , "linux-rdma@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Michael Wang , Roland Dreier , Sean Hefty , Hal Rosenstock , "hal@dev.mellanox.co.il" , Tom Tucker , Steve Wise , Hoang-Nam Nguyen , "raisch@de.ibm.com" , Mike Marciniszyn , Eli Cohen , Faisal Latif , Jack Morgenstein , Or Gerlitz , Haggai Eran , Tom Talpey , Doug Ledford Subject: Re: [PATCH v5 00/27] IB/Verbs: IB Management Helpers Message-ID: <20150427191030.GA5347@phlsvsds.ph.intel.com> References: <5534B8C9.506@profitbricks.com> <20150422024123.GA18675@phlsvsds.ph.intel.com> <20150422164034.GB19500@obsidianresearch.com> <20150424164226.GB9305@obsidianresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150424164226.GB9305@obsidianresearch.com> User-Agent: Mutt/1.4.2.2i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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