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 A01C7C433DB for ; Sun, 21 Mar 2021 17:23:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6BF7D61946 for ; Sun, 21 Mar 2021 17:23:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230270AbhCURWh (ORCPT ); Sun, 21 Mar 2021 13:22:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:39986 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230288AbhCURWZ (ORCPT ); Sun, 21 Mar 2021 13:22:25 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 370216192D; Sun, 21 Mar 2021 17:22:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1616347344; bh=grRbkHiGMiSHWVuRSSoESXsJfOIy2CjZklOAVeWnZfw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lcb9EomaSRSVie+gdKKsQwIdFn/WQrFhUrocsGftn4xKjEuAb/x2g77wzd/sVauDs Xf59ahHNOYLQTAYJHjLqLcNjgkmj2xPSNhKTxbbkSMlH8Y9CFF5dX3OPQqrBslq/XU u2hfZg+BnhopjlvQyqJ3V9RTjCZx7wbBvJeKybIojz/4SGkiB771j2DTjG11r2Aot1 6pCoJvR5rKCUl1n/lmG4h4jvnj/ixtCesI6+8yKLVrdDpIIUaGE11XpX3y4Aottgux dJdYY0ioXlP9jbOaS1+yU/x0hPPC8meih0pKze6ZXth0crA1GrmxwXr2mLuzt4ZCQW aC15QJ9UD3XQw== Date: Sun, 21 Mar 2021 19:22:21 +0200 From: Leon Romanovsky To: "Hsu, Chiahao" Cc: 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: <20210311225944.24198-1-andyhsu@amazon.com> <64f5c7a8-cc09-3a7f-b33b-a64d373aed60@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sun, Mar 21, 2021 at 05:31:08PM +0100, Hsu, Chiahao wrote: > > > Leon Romanovsky 於 2021/3/17 18:22 寫道: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > On Tue, Mar 16, 2021 at 04:22:21PM +0100, Hsu, Chiahao wrote: > > > > > > Leon Romanovsky 於 2021/3/14 11:04 寫道: > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > > > > > > > > > On Fri, Mar 12, 2021 at 09:36:59PM +0100, Andrew Lunn wrote: > > > > > On Fri, Mar 12, 2021 at 04:18:02PM +0100, Hsu, Chiahao wrote: > > > > > > Andrew Lunn 於 2021/3/12 15:52 寫道: > > > > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 11, 2021 at 10:59:44PM +0000, ChiaHao Hsu wrote: > > > > > > > > In order to support live migration of guests between kernels > > > > > > > > that do and do not support 'feature-ctrl-ring', we add a > > > > > > > > module parameter that allows the feature to be disabled > > > > > > > > at run time, instead of using hardcode value. > > > > > > > > The default value is enable. > > > > > > > Hi ChiaHao > > > > > > > > > > > > > > There is a general dislike for module parameters. What other mechanisms > > > > > > > have you looked at? Would an ethtool private flag work? > > > > > > > > > > > > > > Andrew > > > > > > Hi Andrew, > > > > > > > > > > > > I can survey other mechanisms, however before I start doing that, > > > > > > > > > > > > could you share more details about what the problem is with using module > > > > > > parameters? thanks. > > > > > It is not very user friendly. No two kernel modules use the same > > > > > module parameters. Often you see the same name, but different > > > > > meaning. There is poor documentation, you often need to read the > > > > > kernel sources it figure out what it does, etc. > > > > +1, It is also global parameter to whole system/devices that use this > > > > module, which is rarely what users want. > > > > > > > > Thanks > > > Hi, > > > I think I would say the current implementation(modparams) isappropriate > > > after reviewing it again. > > > > > > We are talking about 'feature leveling', a way to support live migrationof > > > guest > > > between kernels that do and do not support the features. So we want to > > > refrain > > > fromadding the features if guest would be migrated to the kernel which does > > > not support the feature. Everythingshould be done (in probe function) before > > > frontend connects, and this is why ethtool is not appropriate for this. > > It wouldn't be a surprise to you that feature discovery is not supposed > > to be done through module parameters. Instead of asking from user to > > randomly disable some feature, the system is expected to be backward > > compatible and robust enough to query the list of supported/needed > > features. > > > > Thanks > > > > > Thanks > > > > > > > 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 specified for > different new features? At the end, it will be more granular module parameter that user still will need to guess. Thanks >