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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 7C75BC5ACD7 for ; Wed, 18 Mar 2020 13:14:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 518E32076E for ; Wed, 18 Mar 2020 13:14:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584537296; bh=ta1hfCd+0sQd+sJl2KIXWkhIBXI0EJLlJ016fhuxx3w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=oaUaIVs2GTErU9qphykmFloEZhDMfcvn0G284OcT7wSD0mFEAWyAt192wTfKU1eWd K2yOQtd5lTJhvgGGLLGkJTF/q8HFUnq3ZZaAaGi7jt9awyrPcYeLviLazp0y6/EHO0 qLrIbxHy8/YN0zVIB8FOifZV8sj9u6s4rBoIHMGQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727006AbgCRNOz (ORCPT ); Wed, 18 Mar 2020 09:14:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:58738 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726864AbgCRNOz (ORCPT ); Wed, 18 Mar 2020 09:14:55 -0400 Received: from localhost (unknown [213.57.247.131]) (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 06DB320768; Wed, 18 Mar 2020 13:14:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584537294; bh=ta1hfCd+0sQd+sJl2KIXWkhIBXI0EJLlJ016fhuxx3w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=w/CdCbNiJLEbvTPMM5t0vQoDAKiMwAcN5furViga24P0dYsQ9+UmkiWwmjXFDKjcV Mk6CPbMiTPZpzaCgozQqqCCIaiu7glywVOeLeEj6riQNEkLuC5p8cibSMJUpAD/O+8 tBfnaxvdCT9TCBHnMbqrjFsz8rwDpzRiI85B+oqk= Date: Wed, 18 Mar 2020 15:14:50 +0200 From: Leon Romanovsky To: Jason Gunthorpe Cc: Doug Ledford , linux-rdma@vger.kernel.org, Michael Guralnik , netdev@vger.kernel.org, Saeed Mahameed , Yishai Hadas Subject: Re: [PATCH rdma-next 0/4] Introduce dynamic UAR allocation mode Message-ID: <20200318131450.GY3351@unreal> References: <20200318124329.52111-1-leon@kernel.org> <20200318125459.GI13183@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200318125459.GI13183@mellanox.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Mar 18, 2020 at 09:54:59AM -0300, Jason Gunthorpe wrote: > On Wed, Mar 18, 2020 at 02:43:25PM +0200, Leon Romanovsky wrote: > > From: Leon Romanovsky > > > > From Yishai, > > > > This series exposes API to enable a dynamic allocation and management of a > > UAR which now becomes to be a regular uobject. > > > > Moving to that mode enables allocating a UAR only upon demand and drop the > > redundant static allocation of UARs upon context creation. > > > > In addition, it allows master and secondary processes that own the same command > > FD to allocate and manage UARs according to their needs, this can’t be achieved > > today. > > > > As part of this option, QP & CQ creation flows were adapted to support this > > dynamic UAR mode once asked by user space. > > > > Once this mode is asked by mlx5 user space driver on a given context, it will > > be mutual exclusive, means both the static and legacy dynamic modes for using > > UARs will be blocked. > > > > The legacy modes are supported for backward compatible reasons, looking > > forward we expect this new mode to be the default. > > We are starting to accumulate a lot of code that is now old-rdma-core > only. Agree > > I have been wondering if we should add something like > > #if CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION < 21 > #endif >From one side it will definitely help to see old code, but from another it will create many ifdef inside of the code with a very little chance of testing. Also we will continue to have the same problem to decide when we can delete this code. > > So we can keep track of what is actually a used code flow and what is > now hard to test legacy code. > > eg this config would also disable the write interface(), turn off > compat write interfaces as they are switched to use ioctl, etc, etc. What about if we introduce one ifdef, let's say CONFIG_INFINIBAND_LEGACY and put everything that will be declared as legacy to that bucket? And once every 5 (???) years delete everything from that bucket. > > Jason