I find Haggai's argument compelling, it is a very small amount of code
and data to add a sharing count, and a very large amount to duplicate
the whole service id map into cma.c.
I get wanting to share the listen list, but we end up with this:
drivers/infiniband/core/cm.c
The idea is to allow SIDR request to be sorted by the GID, when we will
have alias GIDs for IPoIB.
Please limit this series, or at least the early patches in this series, to
simply moving the de-mux out of the ib_cm and into the rdma_cm.
--
To unsubscribe from this list: send the line
Expose the service ID on an incoming CM or SIDR request to the event
handler. This will allow the RDMA CM module to de-multiplex connection
requests based on the information encoded in the service ID.
Signed-off-by: Haggai Eran hagg...@mellanox.com
Acked-by: Sean Hefty sean.he...@intel.com
drivers/infiniband/core/cm.c | 7 +++
include/rdma/ib_cm.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index c5f5f89e274a..46f99ec4080a 100644
--- a/drivers/infiniband/core/cm.c
+++
@@ -722,6 +725,7 @@ struct ib_cm_id *ib_create_cm_id(struct ib_device
*device,
INIT_LIST_HEAD(cm_id_priv-work_list);
atomic_set(cm_id_priv-work_count, -1);
atomic_set(cm_id_priv-refcount, 1);
+ cm_id_priv-listen_sharecount = 1;
This is setting the listen count before
-static int cma_save_net_info(struct rdma_cm_id *id, struct rdma_cm_id
*listen_id,
- struct ib_cm_event *ib_event)
+static u16 cma_port_from_service_id(__be64 service_id)
{
- struct cma_hdr *hdr;
+ return be64_to_cpu(service_id);
+}
Nit - Does the
Add helper functions to access the IDRs by port-space and port number.
Pass around the port-space enum in cma.c instead of using pointers to
port-space IDRs.
What is the motivation for this change?
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to
It remains to clean up ib_cm's ib_cm_listen interface now that
compare_data isn't used, but I'm not sure this belongs in this series.
This patch series is changing the behavior that the compare data solves.
Currently, the ib_cm handles all of the multiplexing for the rdma_cm -- that's
the
> This may have been stated before, but what is missing from this
> description
> is an explanation of why accepting an Ethernet over RDMA driver in the
> upstream kernel is considered useful. We already have an IPoIB driver,
> so
> why to add another driver to the kernel tree for communicating IP
> I didn't read patches yet, and prefer to ask it in advance. Does this
> new ULP work with all
> drivers/infiniband/hw/* devices as it is expected from ULP?
Like the way ipoib or srp work with all hw devices? What is the real point of
this question?
> > Even reading your statement twice did not make me any wiser.
> > You mentioned "better hardware resource usage". Compared to what? Is
> that
> > perhaps compared to IPoIB? Since Ethernet frames have an extra
> header and
> > are larger than IPoIB frames, how can larger frames result in better
> This goes on the network too? Also looks like it has endian problems.
I don't think OPA supports BE systems, and I think it uses LE on the wire for
at least some portions of its protocol.
> You are not making a subsystem. Don't overcomplicate things. A
> multi-part device device can just directly link.
The VNIC may be usable over multiple generations of HFIs, but I don't know if
that is the intent.
> It is acking that message from user was received by kernel and now
> processing. The message from kernel to user are anyway unreliable [1],
> so I don't understand on which handshake you are talking.
>
> [1] "reliable transmissions from kernel to user are impossible in any
> case"
>
14 matches
Mail list logo
