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=-6.2 required=3.0 tests=BAYES_00,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 E29F2C433C1 for ; Mon, 22 Mar 2021 06:49:20 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A00946196E for ; Mon, 22 Mar 2021 06:49:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A00946196E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.100003.190364 (Exim 4.92) (envelope-from ) id 1lOEMl-0003G3-B8; Mon, 22 Mar 2021 06:48:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 100003.190364; Mon, 22 Mar 2021 06:48:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lOEMl-0003Fw-7G; Mon, 22 Mar 2021 06:48:43 +0000 Received: by outflank-mailman (input) for mailman id 100003; Mon, 22 Mar 2021 06:48:41 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lOEMj-0003Fr-1k for xen-devel@lists.xenproject.org; Mon, 22 Mar 2021 06:48:41 +0000 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id fc377903-84b0-46bc-b925-3af9b1627445; Mon, 22 Mar 2021 06:48:40 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id DAA10614A5; Mon, 22 Mar 2021 06:48:38 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fc377903-84b0-46bc-b925-3af9b1627445 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1616395719; bh=aBATp9cF4F75lj0dyqnEuKbgcMuvl6XXRbrTzcy1hz8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jxLByM1eDq0pAWzRAwSsBEtuDaWYZqg6zod0MvQTrLNHpY8NTSNjhfdxcHiCxcly0 DQvAMqQD2ShMoUpfkDwdvPTp96vCTOQyyF5JNn/wSHhGwxZeLsrClVpece2ySaXawI 9PkHyUmoarBs6z/o6d5PNp531EJr0zEVQXexQChe8sA1IHKUtWghq6em8yj3+fdj38 zgiMLsTuOooSmiopAu7+/VWDYsgtH5oeVEN0wZFXwmRUVemE/khxfZ35KmlLTwSlW4 xQS8cccvEqeyLjNm11wnNaA/JB3l3/LOHvJ2RWO1sG9lws3q2FUmQMgtnHgX4oak0F zLXRmzzHY7zJA== Date: Mon, 22 Mar 2021 08:48:35 +0200 From: Leon Romanovsky To: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= Cc: "Hsu, Chiahao" , Andrew Lunn , netdev@vger.kernel.org, wei.liu@kernel.org, paul@xen.org, davem@davemloft.net, kuba@kernel.org, xen-devel@lists.xenproject.org Subject: Re: [net-next 1/2] xen-netback: add module parameter to disable ctrl-ring Message-ID: References: <64f5c7a8-cc09-3a7f-b33b-a64d373aed60@amazon.com> <12f643b5-7a35-d960-9b1f-22853aea4b4c@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: On Mon, Mar 22, 2021 at 06:58:34AM +0100, J=FCrgen Gro=DF wrote: > On 22.03.21 06:39, Leon Romanovsky wrote: > > On Sun, Mar 21, 2021 at 06:54:52PM +0100, Hsu, Chiahao wrote: > > >=20 > >=20 > > <...> > >=20 > > > > > Typically there should be one VM running netback on each host, > > > > > and having control over what interfaces or features it exposes is= also > > > > > important for stability. > > > > > How about we create a 'feature flags' modparam, each bits is spec= ified for > > > > > different new features? > > > > At the end, it will be more granular module parameter that user sti= ll > > > > will need to guess. > > > I believe users always need to know any parameter or any tool's flag = before > > > they use it. > > > For example, before user try to set/clear this ctrl_ring_enabled, they > > > should already have basic knowledge about this feature, > > > or else they shouldn't use it (the default value is same as before), = and > > > that's also why we use the 'ctrl_ring_enabled' as parameter name. > >=20 > > It solves only forward migration flow. Move from machine A with no > > option X to machine B with option X. It doesn't work for backward > > flow. Move from machine B to A back will probably break. > >=20 > > In your flow, you want that users will set all module parameters for > > every upgrade and keep those parameters differently per-version. >=20 > I think the flag should be a per guest config item. Adding this item to > the backend Xenstore nodes for netback to consume it should be rather > easy. >=20 > Yes, this would need a change in Xen tools, too, but it is the most > flexible way to handle it. And in case of migration the information > would be just migrated to the new host with the guest's config data. Yes, it will overcome global nature of module parameters, but how does it solve backward compatibility concern? Thanks >=20 >=20 > Juergen