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

["Hsu, Chiahao" <andyhsu@xxxxxxxxxx>]

Leon Romanovsky 於 2021/3/21 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 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.
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.
Thanks
> Thanks