On 2020/3/15 2:07, Leon Romanovsky wrote: > 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? > > I don't know why my previous answer didn't appear in the ML, hope that > this will arrive. > > The technical reasons to avoid environmental variables and kernel module > parameters are not the same, but very similar. > > Environmental variables are not thread safe (in POSIX), inherited with > fork() and behaves differently in scripts. All this together makes them > as very bad user visible configuration interface. > > Kernel module parameters are not welcomed due to their global nature, > difference between various drivers which makes hard for users to change > HW/scripts, almost impossible to deprecate e.t.c. > > Thanks > I have received both of your responses :) Thanks for your detailed and clear explanation. Weihang
