[PATCH libnvme] fabrics: don't pass sqflow_disable if the kernel does not support the option

[Daniel Wagner]

On Mon, Jul 24, 2023 at 10:49:31PM +0300, Sagi Grimberg wrote:
> > I've paired __nvmf_supported_options() with build_options(). We can
> > move the call to __nvmf_supported_options() further up if it helps.
> 
> We really should just have an interface to check specific options,
> because that is what consumers care about, not the entire opts set.
> 
> Inside you can do the open/read/close once and cache it in memory
> (although I think this is a really unneeded optimization).

There are some users with bigger setups where 8 connections are initiated. We
currently have 7 new options avaible which we are looking for. Thus at least 56
the open/read/close step in such a scenario. I found this a bit excessive hence
the optimization.

> > > Daniel? Any reason why we are caching these opts in an executable
> > > with a short lifetime? And apparently we need to be very precise when
> > > we rely on this cache to be stable.
> > 
> > Ah I see, in this case let's bring nvmf_check_cap() (although I couldn't find it
> > anywhere... I can remember I saw those patches)
> 
> I also remember making disable_sqflow check instead of a retry, so maybe
> it got left behind...

I couldn't find in my mail box or on lore. No idea what I did with it.
Sorry.

> > > If you prefer to cache it, at least do it in the start of every
> > > fabrics callback so we don't need to understand when this cache
> > > is valid...
> > 
> > I don't want to cache it, I just wanted to avoid the above mentioned
> > open/read/parse/close cycle for each build options.
> 
> So do you want to add the interface? Or should I? (assuming you agree
> on individual opt check) ?

Yes, no problems with an individual opt check. Just a sec...