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

From: ira.weiny
Date: Mon Apr 27 2015 - 16:58:46 EST


On Fri, Apr 24, 2015 at 02:53:37PM +0000, Liran Liss wrote:
> > From: ira.weiny [mailto:ira.weiny@xxxxxxxxx]
> > [snip]
> >
> > > >
> > > > 2)The name rdma_tech_* is lame.
> > > > rdma_transport_*(), adhering to the above (*) remark, is much better.
> > > > For example, both IB and ROCE *do* use the same transport.
> > >
> > > I especially want to second this. I haven't really been happy with
> > > the
> > > rdma_tech_* names at all.
> > >
> >
> > I am sure Michael is open to alternative names. I know I am. The problem is
> > that we can't figure out what "IBoE" is. It is not a transport, even though
> > query_transport is now returning it as one. :-P
>
> IBOE is used in part of the kernel symbols that refer to RoCE. That's it.
> ROCE HCA links have the following characteristics:
> - Ethernet link layer
> - IB transport
> - CA node type
>
> And, if needed in the future:
> - ROCEv1 and ROCEv2 protocol stacks

Let me rephrase that[*].

We don't know what to "call" "IBoE" vs "IBoIB" vs "iWarp Verbs over iWarp" vs
"IBoOPA", etc.

The problem with your argument (no matter what name we use, "Transport",
"tech", "protocol") etc is that support for various features are implied rather
than explicit.

Your argument that RoCE is just "IB transport" over Ethernet (while technically
correct) is not relevant for the problem we are trying to solve.

The ib_mad, ib_cm, rdma_cm, and ib_sa modules are attempting to support many
different device type (on a port basis). The functionality they provide is
dependent on so much more that the notion of "transport" and "link layer".

The purpose of this patch series was to create the specific helper functions
based on the support the core modules need to explicitly determine what they
should do for a port. Furthermore, the implementation of those features was to
be based on the current implementation (which happens to use the transport and
link layer) to ensure we don't break everything.

Once we could agree on items like the feature set and the names of the helper
calls we could then alter the implementation to remove the implied nature of
this support.

>
> >
> > I think the idea behind the "tech" name was that it is a technology "family".
> > I can't think of a better name.

I see "protocol" and "specification" being discussed. Those are probably
decent.

Ira

[*] We all know what RoCE (IBoE) _is_...
--
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/