Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965077AbbD0TW5 (ORCPT ); Mon, 27 Apr 2015 15:22:57 -0400 Received: from mga09.intel.com ([134.134.136.24]:10903 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964912AbbD0TWy (ORCPT ); Mon, 27 Apr 2015 15:22:54 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,659,1422950400"; d="scan'208";a="701708407" Date: Mon, 27 Apr 2015 15:22:42 -0400 From: "ira.weiny" To: Liran Liss Cc: Michael Wang , Roland Dreier , Sean Hefty , Hal Rosenstock , "linux-rdma@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "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 , Jason Gunthorpe , Doug Ledford Subject: Re: [PATCH v5 00/27] IB/Verbs: IB Management Helpers Message-ID: <20150427192241.GB5347@phlsvsds.ph.intel.com> References: <5534B8C9.506@profitbricks.com> <55375C10.8070901@profitbricks.com> <5538A034.4030904@profitbricks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2076 Lines: 54 On Fri, Apr 24, 2015 at 02:44:29PM +0000, Liran Liss wrote: > > From: Michael Wang [mailto:yun.wang@profitbricks.com] > > > > [snip] > > > > > > Depends on who is "we". > > > For ULPs, you are probably right. > > > > > > However, core services (e.g., mad management, CM, SA) do care about > > various details. > > > In some cases, where it doesn't matter, this code will use management > > helpers. > > > In other cases, this code will inspect link, transport, and node attributes of > > rdma devices. > > > > > > For example, the CM code has specific code paths for IB, RoCE, and iWARP. > > > There is no other CM code; there is no reason to abstract 'CM'. This > > > code will have code paths that depend on various specific details. > > > > That's exactly what we want to stop, we have classified the CM to IB and > > IWARP now :-) > > > > We don't want to stop code branches that are not abstractions but rather depend > on the specific technology! > There is no generic "iWARP CM" - only one. > There is no generic "ROCE CM" - only one. > There is no generic "IB CM" - only one. How can you say this? Or perhaps I don't understand what you mean. While conceptually one could say that each technology has its own "CM" we are trying to have the same module (and code) implement them all (ie a generic CM for a node). Therefore, the CM code _is_ generic. As is the MAD code. This is the reason we have this problem. We are trying to reuse those modules for multiple technologies. > > At the CM high-level (i.e., whether an ib_dev port registers an IB client), you could consider > an rdma_has_cm() call, but this the only place in the code that this check will be called! > Hence, no need for a generic check. > > You want to stop abstract code that uses IB core infrastructure. Not sure what you mean here? Ira -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/