Message-ID: <b5630c17-b167-b161-bd71-c7674b7ba454@amazon.com>
Date:   Sun, 28 Mar 2021 22:46:01 +0200
From:   "Hsu, Chiahao" <andyhsu@...zon.com>
To:     Leon Romanovsky <leon@...nel.org>,
        Jürgen Groß <jgross@...e.com>
CC:     Andrew Lunn <andrew@...n.ch>, <netdev@...r.kernel.org>,
        <wei.liu@...nel.org>, <paul@....org>, <davem@...emloft.net>,
        <kuba@...nel.org>, <xen-devel@...ts.xenproject.org>
Subject: Re: [net-next 1/2] xen-netback: add module parameter to disable ctrl-ring



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)

Thanks.

Andy
> As long as all new features are disabled by default, it will be ok.
>
> Thanks
>
>>
>> Juergen
>
>
>
>

Powered by blists - more mailing lists