netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: "Hsu, Chiahao" <andyhsu@amazon.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	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
Date: Mon, 22 Mar 2021 07:39:11 +0200	[thread overview]
Message-ID: <YFgtf6NBPMjD/U89@unreal> (raw)
In-Reply-To: <12f643b5-7a35-d960-9b1f-22853aea4b4c@amazon.com>

On Sun, Mar 21, 2021 at 06:54:52PM +0100, Hsu, Chiahao wrote:
> 

<...>

> > > 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.
> 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.

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.

In your flow, you want that users will set all module parameters for
every upgrade and keep those parameters differently per-version.

Thanks

> 
> Thanks
> > Thanks
> > 
> 

  parent reply	other threads:[~2021-03-22  5:39 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-11 22:59 [net-next 1/2] xen-netback: add module parameter to disable ctrl-ring ChiaHao Hsu
2021-03-12  7:32 ` Paul Durrant
2021-03-12 14:52 ` Andrew Lunn
2021-03-12 15:18   ` Hsu, Chiahao
2021-03-12 20:36     ` Andrew Lunn
2021-03-14 10:04       ` Leon Romanovsky
2021-03-16 15:22         ` Hsu, Chiahao
2021-03-17 17:22           ` Leon Romanovsky
2021-03-21 16:31             ` Hsu, Chiahao
2021-03-21 17:22               ` Leon Romanovsky
2021-03-21 17:54                 ` Hsu, Chiahao
2021-03-21 20:29                   ` Andrew Lunn
2021-03-21 21:00                     ` Hsu, Chiahao
2021-03-22  5:39                   ` Leon Romanovsky [this message]
2021-03-22  5:58                     ` Jürgen Groß
2021-03-22  6:48                       ` Leon Romanovsky
2021-03-22  7:01                         ` Jürgen Groß
2021-03-22  7:13                           ` Leon Romanovsky
2021-03-28 20:46                             ` Hsu, Chiahao
2021-03-29  5:03                               ` Juergen Gross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YFgtf6NBPMjD/U89@unreal \
    --to=leon@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=andyhsu@amazon.com \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=paul@xen.org \
    --cc=wei.liu@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).