Message ID | 20190213172310.1681-1-leon@kernel.org (mailing list archive) |
---|---|
Headers | show
Return-Path: <linux-rdma-owner@kernel.org> Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 72FA51399 for <patchwork-linux-rdma@patchwork.kernel.org>; Wed, 13 Feb 2019 17:23:25 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 563FB2D936 for <patchwork-linux-rdma@patchwork.kernel.org>; Wed, 13 Feb 2019 17:23:25 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4AD112E3FA; Wed, 13 Feb 2019 17:23:25 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id ABE922E3DD for <patchwork-linux-rdma@patchwork.kernel.org>; Wed, 13 Feb 2019 17:23:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389476AbfBMRXW (ORCPT <rfc822;patchwork-linux-rdma@patchwork.kernel.org>); Wed, 13 Feb 2019 12:23:22 -0500 Received: from mail.kernel.org ([198.145.29.99]:53518 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392927AbfBMRXW (ORCPT <rfc822;linux-rdma@vger.kernel.org>); Wed, 13 Feb 2019 12:23:22 -0500 Received: from localhost (unknown [77.138.135.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B94632175B; Wed, 13 Feb 2019 17:23:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1550078600; bh=ghARFaJI4iYwujC9lOCp2XMhZSoS9KFLEzU7a1JCoHo=; h=From:To:Cc:Subject:Date:From; b=mScKtHAybMcMY3Ey6G13GisXdsAyNeyIbbv3q76YBnkg4cTBc0Cm1W4KzIwXhEa4t BjZDF7BWi+mT8580ifz6RG4Z8BZUPkIMhEzg0LOg/w+0WFklFBPJewfpfQHBnQGwhj Xh6UPWqB4jCFx04cGtuI2BFA8sLDWcABawdVzT2s= From: Leon Romanovsky <leon@kernel.org> To: Doug Ledford <dledford@redhat.com>, Jason Gunthorpe <jgg@mellanox.com> Cc: Leon Romanovsky <leonro@mellanox.com>, RDMA mailing list <linux-rdma@vger.kernel.org>, Parav Pandit <parav@mellanox.com> Subject: [PATCH rdma-next 0/8] Register infiniband class as net namespace aware class Date: Wed, 13 Feb 2019 19:23:02 +0200 Message-Id: <20190213172310.1681-1-leon@kernel.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: <linux-rdma.vger.kernel.org> X-Mailing-List: linux-rdma@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP |
Series |
Register infiniband class as net namespace aware class
|
expand
|
From: Leon Romanovsky <leonro@mellanox.com> From Parav, Currently 'infiniband' class is registered as net namespace agnostic class due to which all rdma devices are visible in all net namespaces. Due to which net namespace filter needs to be applied on per sysfs entry such as GID or GID attribute for RoCE. This is fine as long as there is one rdma device shared among multiple net namespaces. However, when there are multiple rdma devices, it is desired to see only one or more rdma devices per net namespace. With different link layer types, there are various use case and mode exists. At minimum there are two use cases. (a) a shared rdma device among multiple net namespaces (b) rdma device bound to a particular net namespace In preparation to support backward compatiblity to existing use cases and also to support future (rdma device bound to net namespace), 1. Prepare rdma infiniband class to be net namespace aware; So that when rdma device is bound to a net namespace in future, it can be restricted to a single net namespace. This requires a class to be net namespace aware. By doing so, a standard kernel framework of sysfs can be utilized to isolate devices in net namespaces. This is similar to how net class is net namespace aware following standard kernel architecture. 2. Replicate the sysfs tree in non init_net namespaces for backward compatibility, so that existing applications continue to operate in shared mode. This functionality is achieved by ib_core implementing a compat ib_core_device which replicates the device and sysfs entries in non init_net namespaces. It is desired to not create a full ib_device, therefore an internal ib_core_device object is created which represents only needed device tree and sysfs entries. A diagram, details and its objectives are captured in Documentation/infiniband/core_devices.txt. Thanks BTW, It has same extra space between for_each iterator and bracket, as was pointed by Bart. Parav Pandit (8): RDMA/core: Use simpler device_del() instead of device_unregister() RDMA/core: Introduce and use ib_setup_port_attrs() RDMA/core: Introduce ib_core_device to hold device RDMA/core: Move device addition deletion to device.c RDMA/core: Restrict sysfs entries view to init_net RDMA/core: Implement compat device/sysfs tree in net namespace RDMA/core: Add Documentation for ib_core_device RDMA/core: Support core port attributes in non init_net Documentation/infiniband/core_devices.txt | 146 ++++++++++ drivers/infiniband/core/core_priv.h | 9 + drivers/infiniband/core/device.c | 333 +++++++++++++++++++++- drivers/infiniband/core/sysfs.c | 81 +++--- include/rdma/ib_verbs.h | 31 +- 5 files changed, 547 insertions(+), 53 deletions(-) create mode 100644 Documentation/infiniband/core_devices.txt -- 2.19.1