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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/