Re: [net-next 1/2] xen-netback: add module parameter to disable ctrl-ring

[Juergen Gross <jgross@xxxxxxxx>]

On 28.03.21 22:46, Hsu, Chiahao wrote:
> Leon Romanovsky 於 2021/3/22 08:13 寫道:
> > 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 Mon, Mar 22, 2021 at 08:01:17AM +0100, Jürgen Groß wrote:
> > > On 22.03.21 07:48, Leon Romanovsky wrote:
> > > > On Mon, Mar 22, 2021 at 06:58:34AM +0100, Jürgen Groß wrote:
> > > > > On 22.03.21 06:39, Leon Romanovsky wrote:
> > > > > > 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.
> > > > > 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.
> > > > >
> > > > > 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?
> > > When creating a guest on A the (unknown) feature will not be set to
> > > any value in the guest's config data. A migration stream not having any
> > > value for that feature on B should set it to "false".
> > >
> > > When creating a guest on B it will either have the feature value set
> > > explicitly in the guest config (either true or false), or it will get
> > > the server's default (this value should be configurable in a global
> > > config file, default for that global value would be "true").
> > >
> > > So with the guest created on B with feature specified as "false" (either
> > > for this guest only, or per global config), it will be migratable to
> > > machine A without problem. Migrating it back to B would work the same
> > > way as above. Trying to migrate a guest with feature set to "true" to
> > > B would not work, but this would be the host admin's fault due to not
> > > configuring the guest correctly.
> so the expected changes would be
>
> 1. remove feature-ctrl-ring & feature-dynamic-multicast-control from 
> netback_probe( )
> 2. consume the backend Xenstore nodes in connect( ) to see if Xen tools 
> set nodes(true/false) or not(unknown)
Yes. I think this is the way to go.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys

Attachment: OpenPGP_signature
Description: OpenPGP digital signature