From patchwork Tue Dec 9 22:36:06 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ira Weiny X-Patchwork-Id: 5465431 Return-Path: X-Original-To: patchwork-linux-rdma@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id DDFBBBEEA8 for ; Tue, 9 Dec 2014 22:36:13 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 088AE201C8 for ; Tue, 9 Dec 2014 22:36:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4F5D3201C7 for ; Tue, 9 Dec 2014 22:36:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751774AbaLIWgK (ORCPT ); Tue, 9 Dec 2014 17:36:10 -0500 Received: from mga03.intel.com ([134.134.136.65]:32347 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751035AbaLIWgJ (ORCPT ); Tue, 9 Dec 2014 17:36:09 -0500 Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP; 09 Dec 2014 14:34:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="496301386" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by orsmga003.jf.intel.com with ESMTP; 09 Dec 2014 14:32:25 -0800 Received: from orsmsx157.amr.corp.intel.com (10.22.240.23) by ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Dec 2014 14:36:07 -0800 Received: from crsmsx104.amr.corp.intel.com (172.18.63.32) by ORSMSX157.amr.corp.intel.com (10.22.240.23) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Dec 2014 14:36:08 -0800 Received: from crsmsx101.amr.corp.intel.com ([169.254.1.95]) by CRSMSX104.amr.corp.intel.com ([172.18.63.32]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 16:36:07 -0600 From: "Weiny, Ira" To: Or Gerlitz CC: Or Gerlitz , "roland@kernel.org" , "linux-rdma@vger.kernel.org" Subject: RE: [RFC PATCH 03/16] ib/mad: Add check for jumbo MADs support on a device Thread-Topic: [RFC PATCH 03/16] ib/mad: Add check for jumbo MADs support on a device Thread-Index: AQHQCjgQL7UTkR/O3UGj6l4dR312Z5yBjo1ggAR184CAAd5O0A== Date: Tue, 9 Dec 2014 22:36:06 +0000 Message-ID: <2807E5FD2F6FDA4886F6618EAC48510E0CBD7A97@CRSMSX101.amr.corp.intel.com> References: <1415908465-24392-1-git-send-email-ira.weiny@intel.com> <1415908465-24392-4-git-send-email-ira.weiny@intel.com> <54770F44.2090909@mellanox.com> <2807E5FD2F6FDA4886F6618EAC48510E0CBD4F23@CRSMSX101.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.205.10] MIME-Version: 1.0 Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP > > On Mon, Dec 8, 2014 at 2:23 AM, Weiny, Ira wrote: > > >> I find it very annoying that upper level drivers replicate in > >> different ways elements from the IB device attributes returned by > >> ib_query_device. I met that in multiple drivers and upcoming designs > >> for which I do code review. Are you up to come up with a patch that > >> caches the device attributes on the device structure? > > > I don't follow what you are asking for. Could you give more details? > > 1. add a struct ib_device_attr field to struct ib_device > > 2. when the device registers itself with the IB core, go and run the > query_device verb with the param being pointer to that field I see where you are going. Then the MAD stack does not have to cache a "max_mad_size" value but rather looks in the ib_device structure "on the fly"... So, something like the diff below? What are the chances we end up with attributes which are not constant? If Roland would like to go this way I can rework my series based on the attributes being cached. -- Ira 17:15:59 > git di diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c index 18c1ece..db18795 100644 --- a/drivers/infiniband/core/device.c +++ b/drivers/infiniband/core/device.c @@ -322,6 +322,8 @@ int ib_register_device(struct ib_device *device, client->add(device); } + device->query_device(device, &device->attributes); + out: mutex_unlock(&device_mutex); return ret; diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h index 470a011..241a882 100644 --- a/include/rdma/ib_verbs.h +++ b/include/rdma/ib_verbs.h @@ -1630,6 +1630,7 @@ struct ib_device { u32 local_dma_lkey; u8 node_type; u8 phys_port_cnt; + struct ib_device_attr attributes; }; struct ib_client {