Re: [PATCH 3/7] IB/srpt: Change default behavior from using SRQ to not using SRQ

[Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2615 bytes --]

On Tue, Oct 10, 2017 at 11:13:22AM -0400, Doug Ledford wrote:
> On Tue, 2017-10-10 at 18:00 +0300, Leon Romanovsky wrote:
> > On Tue, Oct 10, 2017 at 10:34:19AM -0400, Doug Ledford wrote:
> > > On 10/10/2017 12:14 AM, Leon Romanovsky wrote:
> > > >
> > Doug,
> > But my question was "when" and not "how". When should I set this
> > parameter to true?
>
> Whenever you want.  When do you set the maximum TCP window size to 4MB?
>  If you have an issue with things being one way, you try another.
> Things like this are system specific and often there is no universal
> answer, especially since the answer here could very easily depend on
> things like how many targets you are connecting to, how fast those
> targets are, etc.

Bart clearly mentioned disadvantages of XRQ and left me wonder why user
needs to enable it anyway. This is what I'm asking and this is what I'm
hoping to see in the commit message.

I know little about SRP and by asking the questions, I'm trying to fill
the gaps.

>
> > >
> > > > In the commit message, you mentioned disadvantages of using SRQ
> > > > is a
> > > > default and among them - locks contention, which can be changed
> > > > in the
> > > > future. Won't it mean that users stuck with current default,
> > > > because
> > > > change of default will "break" their scripts?
> > >
> > > No, it won't.  If you change the default, you don't remove the
> > > variable,
> > > you just change what its setting is.  Then existing modprobe.d
> > > files
> > > become redundant, but nothing breaks.  People that don't want the
> > > new
> > > setting add a new file to the modprobe.d directory to change the
> > > option.
> >
> > Not accurate, now I won't set any parameter because I'm relying on
> > the
> > fact that the default is without SRQ. Once the default will be
> > changed,
> > it will break my assumption.
>
> So?  Your assumptions are never a reason to prevent ongoing
> development.  By this argument, we would never have been able to turn
> on SCSI Multi-queue by default because when it was first added to the
> kernel it was off by default and people might have made an assumption
> that we would later break when we turned it on by default.

I'm not fully understand the example, The transition to MQ was long
process and one of the difficulties was requirement to smoothly transit
all devices in such way that users won't be affected. This is why it was
disabled by default.

Thanks

>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>     GPG KeyID: B826A3330E572FDD
>     Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]