On Fri, Apr 24, 2015 at 02:44:29PM +0000, Liran Liss wrote: > > From: Michael Wang [mailto:yun.w...@profitbricks.com] > > > > [snip] > > > > > > Depends on who is "we". > > > For ULPs, you are probably right. > > > > > > However, core services (e.g., mad management, CM, SA) do care about > > various details. > > > In some cases, where it doesn't matter, this code will use management > > helpers. > > > In other cases, this code will inspect link, transport, and node > > > attributes of > > rdma devices. > > > > > > For example, the CM code has specific code paths for IB, RoCE, and iWARP. > > > There is no other CM code; there is no reason to abstract 'CM'. This > > > code will have code paths that depend on various specific details. > > > > That's exactly what we want to stop, we have classified the CM to IB and > > IWARP now :-) > > > > We don't want to stop code branches that are not abstractions but rather > depend > on the specific technology! > There is no generic "iWARP CM" - only one. > There is no generic "ROCE CM" - only one. > There is no generic "IB CM" - only one.
How can you say this? Or perhaps I don't understand what you mean. While conceptually one could say that each technology has its own "CM" we are trying to have the same module (and code) implement them all (ie a generic CM for a node). Therefore, the CM code _is_ generic. As is the MAD code. This is the reason we have this problem. We are trying to reuse those modules for multiple technologies. > > At the CM high-level (i.e., whether an ib_dev port registers an IB client), > you could consider > an rdma_has_cm() call, but this the only place in the code that this check > will be called! > Hence, no need for a generic check. > > You want to stop abstract code that uses IB core infrastructure. Not sure what you mean here? 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/
