Re: [PATCH v5 00/27] IB/Verbs: IB Management Helpers

[ira.weiny]

On Fri, Apr 24, 2015 at 10:42:26AM -0600, Jason Gunthorpe wrote:
> On Fri, Apr 24, 2015 at 03:00:15PM +0000, Liran Liss wrote:
> 
> > Currently, the only code in the kernel that has an SMI interface is IB.
> > When OPA is introduced, add the proper helper.
> 
> We already have tests checking for SMI is supported so QP0 can be
> created, this is to support ROCEE
>  
> > All I am saying is that there will always be code paths that are
> > technology- and standards-specific.  For example, the low-level MAD
> > processing code *must* do stuff like:
> 
> > if (rdma_is_transport_ib())
> > 	/* IB-spec compliant stuff */
> > else if (rdma_is_transport_opa())
> > 	/* OPA stuff */

The issue is that opa is _not_ a new "transport".  It is just like RoCEE which
supports the IB transport with some differences.

We need a way to explain what those differences are while keeping each section
of code as clean and clear as possible.  Many of us have spent a lot of time
trying to figure out what each section of the current code is doing when they
call "get_transport" and/or "get_link_layer".

> 
> Why should we open code that? It is back to what I said - that doesn't
> help the reader. Which of the few differences between OPA and IB MADs
> is that code trying to deal with?
> 
> Heck, what are the differences? Do you know? Do I know?
> 
> If you don't know what the differences are, you can't realistically
> work on the MAD layer anymore, because you might break OPA.
> 
> Whereas, If I see:
> 
> if (cap_2k_mad())
>  /* Special handling for OPA 2k mad support */

FWIW we decided not to special case 2K and simply provide the max MAD size
which a driver supports.  This is much more flexible.  I think the semantics
are equivalent to your example here but I don't think we need a discussion
around a "cap_2k_mad" helper.

> if (cap_opa_mad_space() && mad->baseVersion == ... )
>  /* Decode OPA mads */
> if (cap_ib_mad_space() && mad->baseVersion == ... )
>  /* Decode IB mads */

Agreed.

> 
> The I *know* what to look for when writing new code.
> 
> That is the problem we are trying to address here. iWarp has already
> created it, we addressed it using 'rdma_is_transport_iwarp' and I
> don't think those results were very satisfying.

No they are not and it is getting more complicated.

Ira

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/