Re: [RFC PATCH 06/11] IB/Verbs: Use management helper has_sa() and cap_sa(), for sa-check

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Tue, Mar 31, 2015 at 08:51:13PM -0400, ira.weiny wrote:

> > Going forward we want to NAK stuff like this:
> > 
> >   if (rdma_ib_mgmt() || rdma_opa_mgmt())
> >   if (has_sa() || has_opa_foobar())
> 
> I'm confused.
> 
> Is the idea that you would NAK has_sa but be in favor of has_ib_sa?

It is the || I don't want to see. Feature tests should be one thing.

> I believe it is reasonable to flag OPA MAD support as a feature set through a
> single bit.  From this the MAD stack can know if OPA MAD base/class versions
> are allowed (or treated differently from future IB versions) and if it should
> processing OPA SM Class DR MADs differently.  I don't want devices to be
> required to supply a list of MAD Base/Class Versions they support.

That seems reasonable, but we'd gain a is_ib_smp and is_opa_smp test
to do that.

> For example, the MAD size is more generally (and perhaps better) communicated
> via an actual mad_size attribute rather than as part of the OPA MAD feature
> set.

Start with a bit and change when that makes no sense, MTUs as ints
make sense.

> Another example is the question of is it appropriate to wrap up the single READ
> SGL entry support within the "is iwarp" flag?

Again, stick with a single bit test until a HW vendors needs more,
then someone can clean it. At least they now know what to clean and
why.

Remember, this is in the kernel, we can change it when it outlives its
life.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html