From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 87F29C31E40 for ; Mon, 12 Aug 2019 10:53:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 59CB5208C2 for ; Mon, 12 Aug 2019 10:53:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565607211; bh=f/aIF+KPNX60TGEXdUQYV9Q0SKGyB4NwlWdP9rPqL1g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=ICwJIxixZBJnla/4jzVI/w3YWPS/1ABmqP3EiY6cQDSAriP3OGkNbHL+SqpCGrmwt RRNO20UDLkn3yQY6l2WPpZD96qCbwhvWBkeoAHeqWx60IZwB7meyHhtcgr6KFJYuZY q97zdNCpzRAVd5qG15hCoqQkVUix9JFqRdjkUVu0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728068AbfHLKxa (ORCPT ); Mon, 12 Aug 2019 06:53:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:60390 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727920AbfHLKxa (ORCPT ); Mon, 12 Aug 2019 06:53:30 -0400 Received: from localhost (unknown [77.137.115.125]) (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 62C392085A; Mon, 12 Aug 2019 10:53:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565607210; bh=f/aIF+KPNX60TGEXdUQYV9Q0SKGyB4NwlWdP9rPqL1g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=1K6kDHVW+jytGpG6zTVSbm0sA2OZzKKEWdzF49ax4SX8QqvG3skUOsucaywkmitNK nbB2UL/aNeU6AEtYSSjEQPOUj4Xk+zeOT2+fx5dSxKc1mppgiKCSKVTyIkgv6up/Yl IJauKmDR5vksreQl6zqMewhV4JyRKLRFqsT+Ocv0= Date: Mon, 12 Aug 2019 13:53:24 +0300 From: Leon Romanovsky To: Jason Gunthorpe Cc: Doug Ledford , RDMA mailing list , Erez Alfasi Subject: Re: [PATCH rdma-next 2/6] RDMA/umem: Add ODP type indicator within ib_umem_odp Message-ID: <20190812105324.GA29138@mtr-leonro.mtl.com> References: <20190807103403.8102-1-leon@kernel.org> <20190807103403.8102-3-leon@kernel.org> <20190807114406.GC1571@mellanox.com> <20190807121335.GC32366@mtr-leonro.mtl.com> <20190807123510.GF1557@ziepe.ca> <20190807131239.GF32366@mtr-leonro.mtl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190807131239.GF32366@mtr-leonro.mtl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Wed, Aug 07, 2019 at 04:12:39PM +0300, Leon Romanovsky wrote: > On Wed, Aug 07, 2019 at 09:35:10AM -0300, Jason Gunthorpe wrote: > > On Wed, Aug 07, 2019 at 03:13:35PM +0300, Leon Romanovsky wrote: > > > On Wed, Aug 07, 2019 at 11:44:16AM +0000, Jason Gunthorpe wrote: > > > > On Wed, Aug 07, 2019 at 01:33:59PM +0300, Leon Romanovsky wrote: > > > > > From: Erez Alfasi > > > > > > > > > > ODP type can be divided into 2 subclasses: > > > > > Explicit and Implicit ODP. > > > > > > > > > > Adding a type enums and an odp type flag within > > > > > ib_umem_odp will give us an indication whether a > > > > > given MR is ODP implicit/explicit registered. > > > > > > > > > > Signed-off-by: Erez Alfasi > > > > > Signed-off-by: Leon Romanovsky > > > > > drivers/infiniband/core/umem.c | 1 + > > > > > include/rdma/ib_umem_odp.h | 14 ++++++++++++++ > > > > > include/uapi/rdma/ib_user_verbs.h | 5 +++++ > > > > > 3 files changed, 20 insertions(+) > > > > > > > > No for this patch, I've got a series cleaning up this > > > > implicit/explicit nonsense, and the result is much cleaner than this. > > > > > > It doesn't really clean anything, just stores implicit/explicit information. > > > > > > > > > > > This series will have to wait. > > > > > > The information exposed in this series is already available in uverbs, > > > so whatever cleanup will come, we still need to expose ODP MR type. > > > > > > This patch is tiny part of whole series, why should we block whole > > > series and iproute2? > > > > This whole approach is really ugly, I even object to the very idea of > > patch #1 > > How did patch #1 relate? It simply removed same code from drivers and > put it in one place. > > > > > The umem is an internal detail and should not be exposed out of the > > driver for nldev to use. > > We are exporting ODP MR property, users are not aware of umem thing > underneath at all. Jason ??? I don't want to send iproute2 and make noise if the kernel part is put on hold. Thanks > > Thanks > > > > > Jason