[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