>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

_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Reply via email to