On Sat, Mar 14, 2020 at 03:44:49AM +0000, liweihang wrote: > On 2020/3/13 20:18, Jason Gunthorpe wrote: > > On Fri, Mar 13, 2020 at 06:02:20AM +0000, liweihang wrote: > >> On 2020/3/13 1:27, Jason Gunthorpe wrote: > >>> On Thu, Mar 12, 2020 at 01:04:05PM -0400, Andrew Boyer wrote: > >>>> What would you say to a per-process env variable to disable locking in > >>>> a userspace provider? > >>> > >>> That is also a no. verbs now has 'thread domain' who's purpose is to > >>> allow data plane locks to be skipped. > >>> > >>> Generally new env vars in verbs are going to face opposition from > >>> me. > >>> > >>> Jason > >> > >> Thanks for your comments. Do you have some suggestions on how to > >> achieve lockless flows in kernel? Are there any similar interfaces > >> in kernel like the thread domain in userspace? > > > > It has never come up before > > > > Jason > > > > Thank you, Jason. Could you please explain why it's not encouraged to > use module parameters in kernel? > > What about the reason why we shouldn't add new environment variables > in userspace? Do they have the same reason? No, the are discouraged for different technical reasons. There are many reasons for not allowing them, but immediately comes into mind that environmental variables are not thread safe, silently inherited by fork() and have very interesting behavior in the scripts. This makes environmental variables are the worst configuration "tool" for the libraries. Module parameters are bad due to inability to deprecate them, difference between drivers that requires rewrite scripts/configs after driver/HW change, global nature of the change and really painful experience for the users if workload requires to change those defaults. Thanks > > Weihang
