On 2020/3/16 21:04, Leon Romanovsky wrote: > On Mon, Mar 16, 2020 at 09:12:31AM -0300, Jason Gunthorpe 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? >> >> Behavior that effects the operation of a ULP should never be >> configured globally. The ULP must self-select this behavior >> pragmatically, only when it is safe. > > Indeed, very good point. > > I just want to add that for ULP it is very rare that module > parameters are the right choice either, because usually those parameters > change ULP behavior be suitable for specific workload. > > Thanks > >> >> Jason > I see, thanks again for your detailed explanation, it's very helpful for us. Weihang
