[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