> 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"
> https://linu
> > 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 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?
> 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.
> 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 "unsubs
> 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 messa
> -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
> @@ -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 co
> 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
> +++ b/drivers/infinib
> 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
Acked-by: Sean Hefty
--
To unsubscribe from this list: se
> 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 r
> 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
14 matches
Mail list logo
