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 381B8C5ACD7 for ; Wed, 18 Mar 2020 17:07:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 109BE20768 for ; Wed, 18 Mar 2020 17:07:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584551247; bh=y5A7BGbCC27R1O3f8EBbgrW6SajWQHehra/gxa7dPvw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=gXix3l3E7nZPyrBfzBh7i21w1Z1J5tlHYN14jxdMe0BjxH17CtY4gJ/lM3ECgsPpC Ee2FaNCFs7ndmFdUxXACWGl/HeeJD9Sa/Sp0lGLJfPW85coK5kU6cgOyHZlNtde0Vg hVRnDJNXlWBXsssykHANDJZx6zTKqCAg1SpiJRAI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727171AbgCRRH0 (ORCPT ); Wed, 18 Mar 2020 13:07:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:40880 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726855AbgCRRHZ (ORCPT ); Wed, 18 Mar 2020 13:07:25 -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 AD22120753; Wed, 18 Mar 2020 17:07:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584551245; bh=y5A7BGbCC27R1O3f8EBbgrW6SajWQHehra/gxa7dPvw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KNePhfFC2M08KULuxc1NqeYxJP0rABdxSG6ciuh8tupKnDJ4SOfGtc7nFEFbzFnRl g1gBI21sUbSXv9g/12aO+d9JvdqFypYKXGWqTE21gxBv8VGgeUW+APyam7XeyNNIAL mL0n7/XAkL/Eft5vbOrOSGVt5+Sbo5udlPBQhb+0= Date: Wed, 18 Mar 2020 19:07:21 +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: <20200318170721.GD126814@unreal> References: <20200318124329.52111-1-leon@kernel.org> <20200318125459.GI13183@mellanox.com> <20200318131450.GY3351@unreal> <20200318132100.GK13183@mellanox.com> <20200318135631.GA126497@unreal> <20200318140001.GL13183@mellanox.com> <20200318140932.GB126814@unreal> <20200318141208.GM13183@mellanox.com> <20200318142455.GC126814@unreal> <20200318143903.GN13183@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200318143903.GN13183@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 11:39:03AM -0300, Jason Gunthorpe wrote: > On Wed, Mar 18, 2020 at 04:24:55PM +0200, Leon Romanovsky wrote: > > > > I'm ok with this approach because it helps us to find those dead > > > > paths, but have last question, shouldn't this be achieved with > > > > proper documentation of every flag instead of adding CONFIG_..? > > > > > > How do you mean? > > > > > > The other half of this idea is to disable obsolete un tested code to > > > avoid potential bugs. Which requires CONFIG_? > > > > The second part is achievable by distros when they will decide to > > support starting from version X. The same decision is not so easy > > to do in the upstream. > > Upstream will probably carry the code for a long, long time, that > doesn't mean the distros don't get value by using a shorter time > window Sure > > > Let's take as an example this feature. It will be set as default from > > rdma-core v29 and the legacy code will be guarded by > > "if (CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION >= 29)". When will change > > CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION to be above 29? So we will > > delete such legacy code. > > First the distros will decide in their own kconfigs where they want to > set the value. > > Then the upstream kernel will decide some default value > > Then maybe we could talk about lowest values when enough of the user > community uses a higher value I think that you over-optimistic here, but let's hear other voices here. Thanks > > Jason