[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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








 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.