[openib-general] [PATCH] extend ib_device node_type to include iWarp
Roland Dreier
rdreier at cisco.com
Tue Jan 31 15:39:07 PST 2006
Sean> Any issues committing this? This does change ipoib, mthca,
Sean> along with a slew of core files. I'll submit separate
Sean> patches for the ehca and ipath drivers, but they should
Sean> continue to work without changes.
Reading this patch over, I'm not convinced that it makes sense to
separate the node type and transport into bitfields. The notion of
CA/switch/router is IB-specific; iWARP has only RNICs, right?
Since there are only four choices of node type, why not just do
something direct like:
enum rdma_node_type {
RDMA_NODE_IB_CA = 1,
RDMA_NODE_IB_SWITCH,
RDMA_NODE_IB_ROUTER,
RDMA_NODE_RNIC
};
enum rdma_transport_type {
RDMA_TRANSPORT_IB,
RDMA_TRANSPORT_IWARP
};
static inline enum rdma_transport_type
rdma_node_get_transport(enum rdma_node_type node) {
switch (node) {
case RDMA_NODE_IB_CA:
case RDMA_NODE_IB_SWITCH:
case RDMA_NODE_IB_ROUTER:
return RDMA_TRANSPORT_IB;
case RDMA_TRANSPORT_IWARP:
return RDMA_TRANSPORT_IWARP;
default:
BUG();
}
(and I'm quite consciously switching over to use "rdma_" naming
instead of "ib_" naming, since otherwise it's a little odd to worry
about non-IB transports).
Perhaps I'm being too picky here but it just seems ugly to me for
iWARP drivers to do something like
device->node_type = IB_NODE_CA | IB_NODE_IWARP;
or even
device->node_type = RDMA_NODE_CA | RDMA_NODE_IWARP;
and I don't see why we want to allow for impossible things like an
iWARP switch.
- R.
More information about the general
mailing list