[ofa-general] [PATCHv4 01/10] ib_core: Refine device personality from node type to port type

Sean Hefty sean.hefty at intel.com
Wed Aug 5 13:43:12 PDT 2009


>As a preparation to devices that, in general, support different transport
>protocol for each port, specifically RDMAoE, this patch defines transport type
>for each of a device's ports. As a result rdma_node_get_transport() has been
>unexported and is used internally by the implementation of the new API,
>rdma_port_get_transport() which gives the transport protocol of the queried
>port. All references to rdma_node_get_transport() are changed to to use
>rdma_port_get_transport(). Also, ib_port_attr is extended to contain enum
>rdma_transport_type.

Can resources (PDs, CQs, MRs, etc.) between the different transports be shared?
Does QP failover between transports work?

>diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
>index 5130fc5..f930f1d 100644
>--- a/drivers/infiniband/core/cm.c
>+++ b/drivers/infiniband/core/cm.c
>@@ -3678,9 +3678,7 @@ static void cm_add_one(struct ib_device *ib_device)
> 	unsigned long flags;
> 	int ret;
> 	u8 i;
>-
>-	if (rdma_node_get_transport(ib_device->node_type) != RDMA_TRANSPORT_IB)
>-		return;

Did you consider modifying rdma_node_get_transport_s_() and returning a bitmask
of the supported transports available on the device?  I'm wondering if something
like this makes sense, to allow skipping devices that are not of interest to a
particular module.  This would be in addition to the rdma_port_get_transport
call.

There's just a lot of new checks to handle the transport on a port by port
basis.

- Sean




More information about the general mailing list