* Re: [PATCH rdma-core 1/2] ibverbs: Allow vendor data response in create_ah command
From: Jason Gunthorpe @ 2016-12-01 16:40 UTC (permalink / raw)
To: Yishai Hadas
Cc: Yishai Hadas, dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, monis-VPRAkNaXOzVWk0Htik3J/w,
majd-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <c9eb6ee8-e3ca-a540-82f5-0b3580b00c78-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
On Thu, Dec 01, 2016 at 06:30:05PM +0200, Yishai Hadas wrote:
> >> int ibv_cmd_create_ah(struct ibv_pd *pd, struct ibv_ah *ah,
> >>- struct ibv_ah_attr *attr)
> >>+ struct ibv_ah_attr *attr,
> >>+ struct ibv_create_ah_resp *resp,
> >>+ size_t resp_size)
> >
> >NAK without changing the name of this function..
> >
> >We need to decide if we want to have comapt for ibv_cmd_ driver facing
> >entry points, or discard that idea now that we only have one tree.
>
> The idea was that moving to one tree can drop the need to maintain 2
> different symbols, all vendors around where changed to use the new command.
> As this API is not used directly by an applications I don't see a real need
> for 2 APIs.
I'm fine with that, but we still need to change the dynamic link
symbol name when the signature is changed to ensure dynamlic linking
of wrong providers fails.
This might just be as simple as moving ibv_cmd_create_ah from
IBVERBS_1.0 to IBVERBS_1.4 in the .map file. Please test and confirm.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH rdma-core 1/2] ibverbs: Allow vendor data response in create_ah command
From: Yishai Hadas @ 2016-12-01 16:30 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Yishai Hadas, dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, monis-VPRAkNaXOzVWk0Htik3J/w,
majd-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <20161201160058.GA22216-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On 12/1/2016 6:00 PM, Jason Gunthorpe wrote:
> On Thu, Dec 01, 2016 at 04:25:52PM +0200, Yishai Hadas wrote:
>> From: Moni Shoua <monis-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>>
>> Let caller pass response buffer and response size to ibv_cmd_create_ah
>> to enable kernel driver to return some private vendor data.
>>
>> Signed-off-by: Moni Shoua <monis-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>> Reviewed-by: Yishai Hadas <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>> libibverbs/cmd.c | 11 ++++++-----
>> libibverbs/driver.h | 4 +++-
>> providers/hfi1verbs/verbs.c | 4 +++-
>> providers/ipathverbs/verbs.c | 4 +++-
>> providers/ocrdma/ocrdma_verbs.c | 4 +++-
>> providers/rxe/rxe.c | 4 +++-
>> 6 files changed, 21 insertions(+), 10 deletions(-)
>>
>> diff --git a/libibverbs/cmd.c b/libibverbs/cmd.c
>> index 06a017b..eaf7164 100644
>> +++ b/libibverbs/cmd.c
>> @@ -1492,12 +1492,13 @@ int ibv_cmd_post_srq_recv(struct ibv_srq *srq, struct ibv_recv_wr *wr,
>> }
>>
>> int ibv_cmd_create_ah(struct ibv_pd *pd, struct ibv_ah *ah,
>> - struct ibv_ah_attr *attr)
>> + struct ibv_ah_attr *attr,
>> + struct ibv_create_ah_resp *resp,
>> + size_t resp_size)
>
> NAK without changing the name of this function..
>
> We need to decide if we want to have comapt for ibv_cmd_ driver facing
> entry points, or discard that idea now that we only have one tree.
>
The idea was that moving to one tree can drop the need to maintain 2
different symbols, all vendors around where changed to use the new
command. As this API is not used directly by an applications I don't see
a real need for 2 APIs.
I don't believe that we should support legacy provider library *not*
from this tree to run with libibverbs *from* that tree, all expect to
come in one package.
Maybe let Doug and other people comment on as well.
> In this case it would be easy to provide two symbol versions for this
> change so maybe that is what you should do..
It can be done, however as pointed above it seems redundant, going in
that approach won't give us the chance to enjoy from the consolidate
rdma user space in those areas.
.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH rdma-core 1/2] ibverbs: Allow vendor data response in create_ah command
From: Jason Gunthorpe @ 2016-12-01 16:00 UTC (permalink / raw)
To: Yishai Hadas
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, monis-VPRAkNaXOzVWk0Htik3J/w,
majd-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <1480602353-8600-2-git-send-email-yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
On Thu, Dec 01, 2016 at 04:25:52PM +0200, Yishai Hadas wrote:
> From: Moni Shoua <monis-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>
> Let caller pass response buffer and response size to ibv_cmd_create_ah
> to enable kernel driver to return some private vendor data.
>
> Signed-off-by: Moni Shoua <monis-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Yishai Hadas <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> libibverbs/cmd.c | 11 ++++++-----
> libibverbs/driver.h | 4 +++-
> providers/hfi1verbs/verbs.c | 4 +++-
> providers/ipathverbs/verbs.c | 4 +++-
> providers/ocrdma/ocrdma_verbs.c | 4 +++-
> providers/rxe/rxe.c | 4 +++-
> 6 files changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/libibverbs/cmd.c b/libibverbs/cmd.c
> index 06a017b..eaf7164 100644
> +++ b/libibverbs/cmd.c
> @@ -1492,12 +1492,13 @@ int ibv_cmd_post_srq_recv(struct ibv_srq *srq, struct ibv_recv_wr *wr,
> }
>
> int ibv_cmd_create_ah(struct ibv_pd *pd, struct ibv_ah *ah,
> - struct ibv_ah_attr *attr)
> + struct ibv_ah_attr *attr,
> + struct ibv_create_ah_resp *resp,
> + size_t resp_size)
NAK without changing the name of this function..
We need to decide if we want to have comapt for ibv_cmd_ driver facing
entry points, or discard that idea now that we only have one tree.
In this case it would be easy to provide two symbol versions for this
change so maybe that is what you should do..
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH rdma-core 2/2] mlx5: Create and destroy address handle with kernel assistance
From: Yishai Hadas @ 2016-12-01 14:25 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, yishaih-VPRAkNaXOzVWk0Htik3J/w,
monis-VPRAkNaXOzVWk0Htik3J/w, majd-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <1480602353-8600-1-git-send-email-yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
From: Moni Shoua <monis-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Depending on kernel support and when link layer is Ethernet, call kernel
when asked to create an address handle. Kernel will return destination
mac which is required to create the address handle. The alternative,
when kernel support is missing, is to use netlink which is less
efficient. Destroying an address handle also needs kernel assistance to
clean resources that were allocated during address handle creation.
Signed-off-by: Moni Shoua <monis-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Yishai Hadas <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
providers/mlx5/mlx5-abi.h | 7 +++++++
providers/mlx5/mlx5.h | 2 ++
providers/mlx5/verbs.c | 28 +++++++++++++++++++++++-----
3 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/providers/mlx5/mlx5-abi.h b/providers/mlx5/mlx5-abi.h
index 4b5b577..800915d 100644
--- a/providers/mlx5/mlx5-abi.h
+++ b/providers/mlx5/mlx5-abi.h
@@ -91,6 +91,13 @@ struct mlx5_alloc_ucontext_resp {
__u64 hca_core_clock_offset;
};
+struct mlx5_create_ah_resp {
+ struct ibv_create_ah_resp ibv_resp;
+ __u32 response_length;
+ __u8 dmac[ETHERNET_LL_SIZE];
+ __u8 reserved[6];
+};
+
struct mlx5_alloc_pd_resp {
struct ibv_alloc_pd_resp ibv_resp;
__u32 pdn;
diff --git a/providers/mlx5/mlx5.h b/providers/mlx5/mlx5.h
index cb65429..cf314fc 100644
--- a/providers/mlx5/mlx5.h
+++ b/providers/mlx5/mlx5.h
@@ -217,6 +217,7 @@ enum mlx5_rsc_type {
enum {
MLX5_USER_CMDS_SUPP_UHW_QUERY_DEVICE = 1 << 0,
+ MLX5_USER_CMDS_SUPP_UHW_CREATE_AH = 1 << 1,
};
struct mlx5_resource {
@@ -470,6 +471,7 @@ struct mlx5_av {
struct mlx5_ah {
struct ibv_ah ibv_ah;
struct mlx5_av av;
+ bool kern_ah;
};
struct mlx5_rwq {
diff --git a/providers/mlx5/verbs.c b/providers/mlx5/verbs.c
index e288ebf..7107a5b 100644
--- a/providers/mlx5/verbs.c
+++ b/providers/mlx5/verbs.c
@@ -1636,11 +1636,21 @@ struct ibv_ah *mlx5_create_ah(struct ibv_pd *pd, struct ibv_ah_attr *attr)
}
if (is_eth) {
- uint16_t vid;
+ if (ctx->cmds_supp_uhw & MLX5_USER_CMDS_SUPP_UHW_CREATE_AH) {
+ struct mlx5_create_ah_resp resp = {};
- if (ibv_resolve_eth_l2_from_gid(pd->context, attr, ah->av.rmac,
- &vid))
- goto err;
+ if (ibv_cmd_create_ah(pd, &ah->ibv_ah, attr, &resp.ibv_resp, sizeof(resp)))
+ goto err;
+
+ ah->kern_ah = true;
+ memcpy(ah->av.rmac, resp.dmac, ETHERNET_LL_SIZE);
+ } else {
+ uint16_t vid;
+
+ if (ibv_resolve_eth_l2_from_gid(pd->context, attr,
+ ah->av.rmac, &vid))
+ goto err;
+ }
}
return &ah->ibv_ah;
@@ -1651,8 +1661,16 @@ err:
int mlx5_destroy_ah(struct ibv_ah *ah)
{
- free(to_mah(ah));
+ struct mlx5_ah *mah = to_mah(ah);
+ int err;
+
+ if (mah->kern_ah) {
+ err = ibv_cmd_destroy_ah(ah);
+ if (err)
+ return err;
+ }
+ free(mah);
return 0;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH rdma-core 1/2] ibverbs: Allow vendor data response in create_ah command
From: Yishai Hadas @ 2016-12-01 14:25 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, yishaih-VPRAkNaXOzVWk0Htik3J/w,
monis-VPRAkNaXOzVWk0Htik3J/w, majd-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <1480602353-8600-1-git-send-email-yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
From: Moni Shoua <monis-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Let caller pass response buffer and response size to ibv_cmd_create_ah
to enable kernel driver to return some private vendor data.
Signed-off-by: Moni Shoua <monis-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Yishai Hadas <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
libibverbs/cmd.c | 11 ++++++-----
libibverbs/driver.h | 4 +++-
providers/hfi1verbs/verbs.c | 4 +++-
providers/ipathverbs/verbs.c | 4 +++-
providers/ocrdma/ocrdma_verbs.c | 4 +++-
providers/rxe/rxe.c | 4 +++-
6 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/libibverbs/cmd.c b/libibverbs/cmd.c
index 06a017b..eaf7164 100644
--- a/libibverbs/cmd.c
+++ b/libibverbs/cmd.c
@@ -1492,12 +1492,13 @@ int ibv_cmd_post_srq_recv(struct ibv_srq *srq, struct ibv_recv_wr *wr,
}
int ibv_cmd_create_ah(struct ibv_pd *pd, struct ibv_ah *ah,
- struct ibv_ah_attr *attr)
+ struct ibv_ah_attr *attr,
+ struct ibv_create_ah_resp *resp,
+ size_t resp_size)
{
struct ibv_create_ah cmd;
- struct ibv_create_ah_resp resp;
- IBV_INIT_CMD_RESP(&cmd, sizeof cmd, CREATE_AH, &resp, sizeof resp);
+ IBV_INIT_CMD_RESP(&cmd, sizeof cmd, CREATE_AH, resp, resp_size);
cmd.user_handle = (uintptr_t) ah;
cmd.pd_handle = pd->handle;
cmd.attr.dlid = attr->dlid;
@@ -1515,9 +1516,9 @@ int ibv_cmd_create_ah(struct ibv_pd *pd, struct ibv_ah *ah,
if (write(pd->context->cmd_fd, &cmd, sizeof cmd) != sizeof cmd)
return errno;
- (void) VALGRIND_MAKE_MEM_DEFINED(&resp, sizeof resp);
+ (void) VALGRIND_MAKE_MEM_DEFINED(resp, resp_size);
- ah->handle = resp.handle;
+ ah->handle = resp->handle;
ah->context = pd->context;
return 0;
diff --git a/libibverbs/driver.h b/libibverbs/driver.h
index ea3dade..c170169 100644
--- a/libibverbs/driver.h
+++ b/libibverbs/driver.h
@@ -233,7 +233,9 @@ int ibv_cmd_post_recv(struct ibv_qp *ibqp, struct ibv_recv_wr *wr,
int ibv_cmd_post_srq_recv(struct ibv_srq *srq, struct ibv_recv_wr *wr,
struct ibv_recv_wr **bad_wr);
int ibv_cmd_create_ah(struct ibv_pd *pd, struct ibv_ah *ah,
- struct ibv_ah_attr *attr);
+ struct ibv_ah_attr *attr,
+ struct ibv_create_ah_resp *resp,
+ size_t resp_size);
int ibv_cmd_destroy_ah(struct ibv_ah *ah);
int ibv_cmd_attach_mcast(struct ibv_qp *qp, const union ibv_gid *gid, uint16_t lid);
int ibv_cmd_detach_mcast(struct ibv_qp *qp, const union ibv_gid *gid, uint16_t lid);
diff --git a/providers/hfi1verbs/verbs.c b/providers/hfi1verbs/verbs.c
index 06ddbb7..d39a4d0 100644
--- a/providers/hfi1verbs/verbs.c
+++ b/providers/hfi1verbs/verbs.c
@@ -678,12 +678,14 @@ int hfi1_post_srq_recv(struct ibv_srq *ibsrq, struct ibv_recv_wr *wr,
struct ibv_ah *hfi1_create_ah(struct ibv_pd *pd, struct ibv_ah_attr *attr)
{
struct ibv_ah *ah;
+ struct ibv_create_ah_resp resp;
ah = malloc(sizeof *ah);
if (ah == NULL)
return NULL;
- if (ibv_cmd_create_ah(pd, ah, attr)) {
+ memset(&resp, 0, sizeof(resp));
+ if (ibv_cmd_create_ah(pd, ah, attr, &resp, sizeof(resp))) {
free(ah);
return NULL;
}
diff --git a/providers/ipathverbs/verbs.c b/providers/ipathverbs/verbs.c
index 35b2162..2145b15 100644
--- a/providers/ipathverbs/verbs.c
+++ b/providers/ipathverbs/verbs.c
@@ -653,12 +653,14 @@ int ipath_post_srq_recv(struct ibv_srq *ibsrq, struct ibv_recv_wr *wr,
struct ibv_ah *ipath_create_ah(struct ibv_pd *pd, struct ibv_ah_attr *attr)
{
struct ibv_ah *ah;
+ struct ibv_create_ah_resp resp;
ah = malloc(sizeof *ah);
if (ah == NULL)
return NULL;
- if (ibv_cmd_create_ah(pd, ah, attr)) {
+ memset(&resp, 0, sizeof(resp));
+ if (ibv_cmd_create_ah(pd, ah, attr, &resp, sizeof(resp))) {
free(ah);
return NULL;
}
diff --git a/providers/ocrdma/ocrdma_verbs.c b/providers/ocrdma/ocrdma_verbs.c
index 7e066dc..dce833b 100644
--- a/providers/ocrdma/ocrdma_verbs.c
+++ b/providers/ocrdma/ocrdma_verbs.c
@@ -2099,6 +2099,7 @@ struct ibv_ah *ocrdma_create_ah(struct ibv_pd *ibpd, struct ibv_ah_attr *attr)
int ahtbl_idx;
struct ocrdma_pd *pd;
struct ocrdma_ah *ah;
+ struct ibv_create_ah_resp resp;
pd = get_ocrdma_pd(ibpd);
ah = malloc(sizeof *ah);
@@ -2111,7 +2112,8 @@ struct ibv_ah *ocrdma_create_ah(struct ibv_pd *ibpd, struct ibv_ah_attr *attr)
if (ahtbl_idx < 0)
goto tbl_err;
attr->dlid = ahtbl_idx;
- status = ibv_cmd_create_ah(ibpd, &ah->ibv_ah, attr);
+ memset(&resp, 0, sizeof(resp));
+ status = ibv_cmd_create_ah(ibpd, &ah->ibv_ah, attr, &resp, sizeof(resp));
if (status)
goto cmd_err;
diff --git a/providers/rxe/rxe.c b/providers/rxe/rxe.c
index d23ef3d..1dd30ea 100644
--- a/providers/rxe/rxe.c
+++ b/providers/rxe/rxe.c
@@ -781,6 +781,7 @@ static struct ibv_ah *rxe_create_ah(struct ibv_pd *pd, struct ibv_ah_attr *attr)
struct rxe_ah *ah;
struct rxe_av *av;
union ibv_gid sgid;
+ struct ibv_create_ah_resp resp;
err = ibv_query_gid(pd->context, attr->port_num, attr->grh.sgid_index,
&sgid);
@@ -803,7 +804,8 @@ static struct ibv_ah *rxe_create_ah(struct ibv_pd *pd, struct ibv_ah_attr *attr)
rdma_gid2ip(&av->sgid_addr._sockaddr, &sgid);
rdma_gid2ip(&av->dgid_addr._sockaddr, &attr->grh.dgid);
- if (ibv_cmd_create_ah(pd, &ah->ibv_ah, attr)) {
+ memset(&resp, 0, sizeof(resp));
+ if (ibv_cmd_create_ah(pd, &ah->ibv_ah, attr, &resp, sizeof(resp))) {
free(ah);
return NULL;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH rdma-core 0/2] Optimize RoCE address handle creation for userspace
From: Yishai Hadas @ 2016-12-01 14:25 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, yishaih-VPRAkNaXOzVWk0Htik3J/w,
monis-VPRAkNaXOzVWk0Htik3J/w, majd-VPRAkNaXOzVWk0Htik3J/w
This patch set from Moni is the supplementary part of the kernel series that
was lastly sent upstream.
Creating a UD address handler when link layer is Ethernet requires resolving
the remote L3 address (GID) to a L2 address (MAC/VLAN).
Until now the way to resolve GID (which is the remote IP or a function of it)
to a MAC was with an interface supplied by libnl. The implementation of this
interface is heavy and fails on large load of requests to create an address
handle.
This series of patches enables user drivers that care for it to optimize the
resolution of L3 to L2 addresses with uverbs interface.
The series was tested successfully with CX4 in both kernel which doesn't have
this support and with a kernel which includes the above support.
Pull request was sent:
https://github.com/linux-rdma/rdma-core/pull/42
Yishai
Moni Shoua (2):
ibverbs: Allow vendor data response in create_ah command
mlx5: Create and destroy address handle with kernel assistance
libibverbs/cmd.c | 11 ++++++-----
libibverbs/driver.h | 4 +++-
providers/hfi1verbs/verbs.c | 4 +++-
providers/ipathverbs/verbs.c | 4 +++-
providers/mlx5/mlx5-abi.h | 7 +++++++
providers/mlx5/mlx5.h | 2 ++
providers/mlx5/verbs.c | 28 +++++++++++++++++++++++-----
providers/ocrdma/ocrdma_verbs.c | 4 +++-
providers/rxe/rxe.c | 4 +++-
9 files changed, 53 insertions(+), 15 deletions(-)
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH] IB/rdmavt: Only put mmap_info ref if it exists
From: Estrin, Alex @ 2016-12-01 13:29 UTC (permalink / raw)
To: Doug Ledford, jtoppins-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
Jim Foraker, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Dalessandro, Dennis
In-Reply-To: <b67230ae-baf0-c932-4acd-b414a33c158f-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hi Doug,
Would you please consider to pull this patch in?
It would be nice to have that fix in 4.9, if possible.
Thanks.
Acked-by: Alex Estrin <alex.estrin-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> On 11/01/2016 04:44 PM, Jim Foraker wrote:
> > rvt_create_qp() creates qp->ip only when a qp creation request comes from
> > userspace (udata is not NULL). If we exceed the number of available
> > queue pairs however, the error path always attempts to put a kref to this
> > structure. If the requestor is inside the kernel, this leads to a crash.
> >
> > We fix this by checking that qp->ip is not NULL before caling kref_put().
> >
>
> Fixes: 515667f8f8b4 ("IB/rdmavt: Add create queue pair functionality")
>
> > Signed-off-by: Jim Foraker <foraker1-i2BcT+NCU+M@public.gmane.org>
>
> Acked-by: Jonathan Toppins <jtoppins-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH rdma-next 01/10] IB/core: Add raw packet protocol
From: Tom Talpey @ 2016-12-01 13:06 UTC (permalink / raw)
To: Hefty, Sean, Steve Wise, 'Jason Gunthorpe',
'Liran Liss'
Cc: 'Doug Ledford', 'Leon Romanovsky',
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
'Steve Wise', Marciniszyn, Mike, Dalessandro, Dennis,
'Lijun Ou', 'Wei Hu(Xavier)', Latif, Faisal,
'Yishai Hadas', 'Selvin Xavier',
'Devesh Sharma', 'Mitesh Ahuja',
'Christian Benvenuti', 'Dave Goodell',
'Moni Shoua', 'Or Gerlitz'
In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373AB0BA1B7-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
On 11/30/2016 12:30 PM, Hefty, Sean wrote:
>>>>> - this doesn't change anything. Also, AHs are already
>>>>> port-specific. So, I don't see any issue in this regard.
>>>>
>>>> The current scheme infers the protocol of the AH from the current
>>>> configuration of the port, which is a crazy API when the port's
>>>> protocol can change on the fly.
>>>
>>> Maybe the solution is to make the protocol selection explicit
>> throughout the
>> APIs
>>> and associate it with a QP, rather than attempting to list all
>> transport
>> protocols that
>>> a port can support.
>>
>> Do you mean requiring the application to pick the protocol?
>
> Yes - it seems necessary to support devices with RoCE and iWarp running on the same port.
Sockets require this, the API requires a protocol family (PF_xxx)
and socket type (SOCK_xxx) that direct the endpoint to become TCP,
UDP, etc.
On the other hand, RDMA APIs to date have considered RDMA to be the
transport, and therefore they have hidden the underlying protocol.
You just request an "RDMA" endpoint from a specific adapter, and get
what it returns.
I'd agree that the application picks the protocol, but I'd also
argue that the API should have a "wildcard" mode which allows the
current behavior. It could be a simple extension to just add a
selector parameter.
The tricky part is what to do with passive endpoints. If a wildcard
is specified, should a multiprotocol adapter create listens on all
protocols? Also, what of protocols which auto-negotiate? It's my
understanding that some RoCE adapters will attempt to autodetect
whether their peer is RoCEv1 or RoCEv2 capable, and adjust their
protocol to suit.
Tom.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Versions of packages included in rdma-core
From: Philipp Thomas @ 2016-12-01 12:05 UTC (permalink / raw)
To: Leon Romanovsky
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Stefan Fent,
Johannes Thumshirn
In-Reply-To: <20161201112413.GE4497-2ukJVAZIZ/Y@public.gmane.org>
* Leon Romanovsky (leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org) [20161201 12:24]:
> Yes, there is an easy path :)
> commit 2172d3c6d73e336743d6a08ca4e9c618595c2bc5
> Merge: 0083ff6 27d8654 e8c50a2 6d6ace8 560afd8 94aaf19 0de1a98 9c4dc56
> f8cc421 f7340fc ef7827c f2d901b dfa0d02 cfd7546 364b7da 663098b 2f00a5b
> 83d9ee5
> Author: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> Date: Tue Sep 20 11:42:56 2016 -0600
>
> Initial commit
Yay!!! That's exactly what I was searching for, much appreciated!
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH rdma-next V1 4/4] IB/mlx5: Update the rate limit according to user setting for RAW QP
From: Leon Romanovsky @ 2016-12-01 11:43 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Bodong Wang
In-Reply-To: <1480592596-20126-1-git-send-email-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
From: Bodong Wang <bodong-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
- Add MODIFY_QP_EX CMD to extend modify_qp.
- Rate limit will be updated in the following state transactions: RTR2RTS,
RTS2RTS. The limit will be removed when SQ is in RST and ERR state.
Signed-off-by: Bodong Wang <bodong-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Matan Barak <matanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
drivers/infiniband/hw/mlx5/main.c | 3 +-
drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 +
drivers/infiniband/hw/mlx5/qp.c | 74 ++++++++++++++++++++++++++++++++----
3 files changed, 69 insertions(+), 9 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
index fba8cab..4d22cce 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -3030,7 +3030,8 @@ static void *mlx5_ib_add(struct mlx5_core_dev *mdev)
dev->ib_dev.uverbs_ex_cmd_mask =
(1ull << IB_USER_VERBS_EX_CMD_QUERY_DEVICE) |
(1ull << IB_USER_VERBS_EX_CMD_CREATE_CQ) |
- (1ull << IB_USER_VERBS_EX_CMD_CREATE_QP);
+ (1ull << IB_USER_VERBS_EX_CMD_CREATE_QP) |
+ (1ull << IB_USER_VERBS_EX_CMD_MODIFY_QP);
dev->ib_dev.query_device = mlx5_ib_query_device;
dev->ib_dev.query_port = mlx5_ib_query_port;
diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h b/drivers/infiniband/hw/mlx5/mlx5_ib.h
index 854748b..907d749 100644
--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
+++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
@@ -387,6 +387,7 @@ struct mlx5_ib_qp {
struct list_head qps_list;
struct list_head cq_recv_list;
struct list_head cq_send_list;
+ u32 rate_limit;
};
struct mlx5_ib_cq_buf {
diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
index d1e9218..5e89fb25 100644
--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -77,12 +77,14 @@ struct mlx5_wqe_eth_pad {
enum raw_qp_set_mask_map {
MLX5_RAW_QP_MOD_SET_RQ_Q_CTR_ID = 1UL << 0,
+ MLX5_RAW_QP_RATE_LIMIT = 1UL << 1,
};
struct mlx5_modify_raw_qp_param {
u16 operation;
u32 set_mask; /* raw_qp_set_mask_map */
+ u32 rate_limit;
u8 rq_q_ctr_id;
};
@@ -2442,8 +2444,14 @@ static int modify_raw_packet_qp_rq(struct mlx5_ib_dev *dev,
}
static int modify_raw_packet_qp_sq(struct mlx5_core_dev *dev,
- struct mlx5_ib_sq *sq, int new_state)
+ struct mlx5_ib_sq *sq,
+ int new_state,
+ const struct mlx5_modify_raw_qp_param *raw_qp_param)
{
+ struct mlx5_ib_qp *ibqp = sq->base.container_mibqp;
+ u32 old_rate = ibqp->rate_limit;
+ u32 new_rate = old_rate;
+ u16 rl_index = 0;
void *in;
void *sqc;
int inlen;
@@ -2459,10 +2467,44 @@ static int modify_raw_packet_qp_sq(struct mlx5_core_dev *dev,
sqc = MLX5_ADDR_OF(modify_sq_in, in, ctx);
MLX5_SET(sqc, sqc, state, new_state);
+ if (raw_qp_param->set_mask & MLX5_RAW_QP_RATE_LIMIT) {
+ if (new_state != MLX5_SQC_STATE_RDY)
+ pr_warn("%s: Rate limit can only be changed when SQ is moving to RDY\n",
+ __func__);
+ else
+ new_rate = raw_qp_param->rate_limit;
+ }
+
+ if (old_rate != new_rate) {
+ if (new_rate) {
+ err = mlx5_rl_add_rate(dev, new_rate, &rl_index);
+ if (err) {
+ pr_err("Failed configuring rate %u: %d\n",
+ new_rate, err);
+ goto out;
+ }
+ }
+
+ MLX5_SET64(modify_sq_in, in, modify_bitmask, 1);
+ MLX5_SET(sqc, sqc, packet_pacing_rate_limit_index, rl_index);
+ }
+
err = mlx5_core_modify_sq(dev, sq->base.mqp.qpn, in, inlen);
- if (err)
+ if (err) {
+ /* Remove new rate from table if failed */
+ if (new_rate &&
+ old_rate != new_rate)
+ mlx5_rl_remove_rate(dev, new_rate);
goto out;
+ }
+ /* Only remove the old rate after new rate was set */
+ if ((old_rate &&
+ (old_rate != new_rate)) ||
+ (new_state != MLX5_SQC_STATE_RDY))
+ mlx5_rl_remove_rate(dev, old_rate);
+
+ ibqp->rate_limit = new_rate;
sq->state = new_state;
out:
@@ -2477,6 +2519,8 @@ static int modify_raw_packet_qp(struct mlx5_ib_dev *dev, struct mlx5_ib_qp *qp,
struct mlx5_ib_raw_packet_qp *raw_packet_qp = &qp->raw_packet_qp;
struct mlx5_ib_rq *rq = &raw_packet_qp->rq;
struct mlx5_ib_sq *sq = &raw_packet_qp->sq;
+ int modify_rq = !!qp->rq.wqe_cnt;
+ int modify_sq = !!qp->sq.wqe_cnt;
int rq_state;
int sq_state;
int err;
@@ -2494,10 +2538,18 @@ static int modify_raw_packet_qp(struct mlx5_ib_dev *dev, struct mlx5_ib_qp *qp,
rq_state = MLX5_RQC_STATE_RST;
sq_state = MLX5_SQC_STATE_RST;
break;
- case MLX5_CMD_OP_INIT2INIT_QP:
- case MLX5_CMD_OP_INIT2RTR_QP:
case MLX5_CMD_OP_RTR2RTS_QP:
case MLX5_CMD_OP_RTS2RTS_QP:
+ if (raw_qp_param->set_mask ==
+ MLX5_RAW_QP_RATE_LIMIT) {
+ modify_rq = 0;
+ sq_state = sq->state;
+ } else {
+ return raw_qp_param->set_mask ? -EINVAL : 0;
+ }
+ break;
+ case MLX5_CMD_OP_INIT2INIT_QP:
+ case MLX5_CMD_OP_INIT2RTR_QP:
if (raw_qp_param->set_mask)
return -EINVAL;
else
@@ -2507,13 +2559,13 @@ static int modify_raw_packet_qp(struct mlx5_ib_dev *dev, struct mlx5_ib_qp *qp,
return -EINVAL;
}
- if (qp->rq.wqe_cnt) {
- err = modify_raw_packet_qp_rq(dev, rq, rq_state, raw_qp_param);
+ if (modify_rq) {
+ err = modify_raw_packet_qp_rq(dev, rq, rq_state, raw_qp_param);
if (err)
return err;
}
- if (qp->sq.wqe_cnt) {
+ if (modify_sq) {
if (tx_affinity) {
err = modify_raw_packet_tx_affinity(dev->mdev, sq,
tx_affinity);
@@ -2521,7 +2573,7 @@ static int modify_raw_packet_qp(struct mlx5_ib_dev *dev, struct mlx5_ib_qp *qp,
return err;
}
- return modify_raw_packet_qp_sq(dev->mdev, sq, sq_state);
+ return modify_raw_packet_qp_sq(dev->mdev, sq, sq_state, raw_qp_param);
}
return 0;
@@ -2776,6 +2828,12 @@ static int __mlx5_ib_modify_qp(struct ib_qp *ibqp,
raw_qp_param.rq_q_ctr_id = mibport->q_cnt_id;
raw_qp_param.set_mask |= MLX5_RAW_QP_MOD_SET_RQ_Q_CTR_ID;
}
+
+ if (attr_mask & IB_QP_RATE_LIMIT) {
+ raw_qp_param.rate_limit = attr->rate_limit;
+ raw_qp_param.set_mask |= MLX5_RAW_QP_RATE_LIMIT;
+ }
+
err = modify_raw_packet_qp(dev, qp, &raw_qp_param, tx_affinity);
} else {
err = mlx5_core_qp_modify(dev->mdev, op, optpar, context,
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH rdma-next V1 3/4] IB/uverbs: Extend modify_qp and support packet pacing
From: Leon Romanovsky @ 2016-12-01 11:43 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Bodong Wang
In-Reply-To: <1480592596-20126-1-git-send-email-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
From: Bodong Wang <bodong-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
An new uverbs command ib_uverbs_ex_modify_qp is added to support more QP
attributes. User driver should choose to call the legacy/extended API
based on input mask.
IB_USER_LAST_QP_ATTR_MASK is added to indicated the maximum bit position
which supports legacy ib_uverbs_modify_qp.
IB_USER_LEGACY_LAST_QP_ATTR_MASK indicates the maximum bit position
which supports ib_uverbs_ex_modify_qp, the value of this mask should be
updated if new mask is added later.
Along with this change, rate_limit is supported by the extended command,
user driver could use it to control packet packing.
Signed-off-by: Bodong Wang <bodong-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Matan Barak <matanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
drivers/infiniband/core/uverbs.h | 1 +
drivers/infiniband/core/uverbs_cmd.c | 192 ++++++++++++++++++++++------------
drivers/infiniband/core/uverbs_main.c | 1 +
include/uapi/rdma/ib_user_verbs.h | 21 ++++
4 files changed, 146 insertions(+), 69 deletions(-)
diff --git a/drivers/infiniband/core/uverbs.h b/drivers/infiniband/core/uverbs.h
index df26a74..455034a 100644
--- a/drivers/infiniband/core/uverbs.h
+++ b/drivers/infiniband/core/uverbs.h
@@ -289,5 +289,6 @@ IB_UVERBS_DECLARE_EX_CMD(modify_wq);
IB_UVERBS_DECLARE_EX_CMD(destroy_wq);
IB_UVERBS_DECLARE_EX_CMD(create_rwq_ind_table);
IB_UVERBS_DECLARE_EX_CMD(destroy_rwq_ind_table);
+IB_UVERBS_DECLARE_EX_CMD(modify_qp);
#endif /* UVERBS_H */
diff --git a/drivers/infiniband/core/uverbs_cmd.c b/drivers/infiniband/core/uverbs_cmd.c
index cb3f515a..b8fff8b 100644
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -2328,94 +2328,86 @@ static int modify_qp_mask(enum ib_qp_type qp_type, int mask)
}
}
-ssize_t ib_uverbs_modify_qp(struct ib_uverbs_file *file,
- struct ib_device *ib_dev,
- const char __user *buf, int in_len,
- int out_len)
+static int modify_qp(struct ib_uverbs_file *file,
+ struct ib_uverbs_ex_modify_qp *cmd, struct ib_udata *udata)
{
- struct ib_uverbs_modify_qp cmd;
- struct ib_udata udata;
- struct ib_qp *qp;
- struct ib_qp_attr *attr;
- int ret;
-
- if (copy_from_user(&cmd, buf, sizeof cmd))
- return -EFAULT;
-
- INIT_UDATA(&udata, buf + sizeof cmd, NULL, in_len - sizeof cmd,
- out_len);
+ struct ib_qp_attr *attr;
+ struct ib_qp *qp;
+ int ret;
attr = kmalloc(sizeof *attr, GFP_KERNEL);
if (!attr)
return -ENOMEM;
- qp = idr_read_qp(cmd.qp_handle, file->ucontext);
+ qp = idr_read_qp(cmd->base.qp_handle, file->ucontext);
if (!qp) {
ret = -EINVAL;
goto out;
}
- attr->qp_state = cmd.qp_state;
- attr->cur_qp_state = cmd.cur_qp_state;
- attr->path_mtu = cmd.path_mtu;
- attr->path_mig_state = cmd.path_mig_state;
- attr->qkey = cmd.qkey;
- attr->rq_psn = cmd.rq_psn;
- attr->sq_psn = cmd.sq_psn;
- attr->dest_qp_num = cmd.dest_qp_num;
- attr->qp_access_flags = cmd.qp_access_flags;
- attr->pkey_index = cmd.pkey_index;
- attr->alt_pkey_index = cmd.alt_pkey_index;
- attr->en_sqd_async_notify = cmd.en_sqd_async_notify;
- attr->max_rd_atomic = cmd.max_rd_atomic;
- attr->max_dest_rd_atomic = cmd.max_dest_rd_atomic;
- attr->min_rnr_timer = cmd.min_rnr_timer;
- attr->port_num = cmd.port_num;
- attr->timeout = cmd.timeout;
- attr->retry_cnt = cmd.retry_cnt;
- attr->rnr_retry = cmd.rnr_retry;
- attr->alt_port_num = cmd.alt_port_num;
- attr->alt_timeout = cmd.alt_timeout;
-
- memcpy(attr->ah_attr.grh.dgid.raw, cmd.dest.dgid, 16);
- attr->ah_attr.grh.flow_label = cmd.dest.flow_label;
- attr->ah_attr.grh.sgid_index = cmd.dest.sgid_index;
- attr->ah_attr.grh.hop_limit = cmd.dest.hop_limit;
- attr->ah_attr.grh.traffic_class = cmd.dest.traffic_class;
- attr->ah_attr.dlid = cmd.dest.dlid;
- attr->ah_attr.sl = cmd.dest.sl;
- attr->ah_attr.src_path_bits = cmd.dest.src_path_bits;
- attr->ah_attr.static_rate = cmd.dest.static_rate;
- attr->ah_attr.ah_flags = cmd.dest.is_global ? IB_AH_GRH : 0;
- attr->ah_attr.port_num = cmd.dest.port_num;
-
- memcpy(attr->alt_ah_attr.grh.dgid.raw, cmd.alt_dest.dgid, 16);
- attr->alt_ah_attr.grh.flow_label = cmd.alt_dest.flow_label;
- attr->alt_ah_attr.grh.sgid_index = cmd.alt_dest.sgid_index;
- attr->alt_ah_attr.grh.hop_limit = cmd.alt_dest.hop_limit;
- attr->alt_ah_attr.grh.traffic_class = cmd.alt_dest.traffic_class;
- attr->alt_ah_attr.dlid = cmd.alt_dest.dlid;
- attr->alt_ah_attr.sl = cmd.alt_dest.sl;
- attr->alt_ah_attr.src_path_bits = cmd.alt_dest.src_path_bits;
- attr->alt_ah_attr.static_rate = cmd.alt_dest.static_rate;
- attr->alt_ah_attr.ah_flags = cmd.alt_dest.is_global ? IB_AH_GRH : 0;
- attr->alt_ah_attr.port_num = cmd.alt_dest.port_num;
+ attr->qp_state = cmd->base.qp_state;
+ attr->cur_qp_state = cmd->base.cur_qp_state;
+ attr->path_mtu = cmd->base.path_mtu;
+ attr->path_mig_state = cmd->base.path_mig_state;
+ attr->qkey = cmd->base.qkey;
+ attr->rq_psn = cmd->base.rq_psn;
+ attr->sq_psn = cmd->base.sq_psn;
+ attr->dest_qp_num = cmd->base.dest_qp_num;
+ attr->qp_access_flags = cmd->base.qp_access_flags;
+ attr->pkey_index = cmd->base.pkey_index;
+ attr->alt_pkey_index = cmd->base.alt_pkey_index;
+ attr->en_sqd_async_notify = cmd->base.en_sqd_async_notify;
+ attr->max_rd_atomic = cmd->base.max_rd_atomic;
+ attr->max_dest_rd_atomic = cmd->base.max_dest_rd_atomic;
+ attr->min_rnr_timer = cmd->base.min_rnr_timer;
+ attr->port_num = cmd->base.port_num;
+ attr->timeout = cmd->base.timeout;
+ attr->retry_cnt = cmd->base.retry_cnt;
+ attr->rnr_retry = cmd->base.rnr_retry;
+ attr->alt_port_num = cmd->base.alt_port_num;
+ attr->alt_timeout = cmd->base.alt_timeout;
+ attr->rate_limit = cmd->rate_limit;
+
+ memcpy(attr->ah_attr.grh.dgid.raw, cmd->base.dest.dgid, 16);
+ attr->ah_attr.grh.flow_label = cmd->base.dest.flow_label;
+ attr->ah_attr.grh.sgid_index = cmd->base.dest.sgid_index;
+ attr->ah_attr.grh.hop_limit = cmd->base.dest.hop_limit;
+ attr->ah_attr.grh.traffic_class = cmd->base.dest.traffic_class;
+ attr->ah_attr.dlid = cmd->base.dest.dlid;
+ attr->ah_attr.sl = cmd->base.dest.sl;
+ attr->ah_attr.src_path_bits = cmd->base.dest.src_path_bits;
+ attr->ah_attr.static_rate = cmd->base.dest.static_rate;
+ attr->ah_attr.ah_flags = cmd->base.dest.is_global ?
+ IB_AH_GRH : 0;
+ attr->ah_attr.port_num = cmd->base.dest.port_num;
+
+ memcpy(attr->alt_ah_attr.grh.dgid.raw, cmd->base.alt_dest.dgid, 16);
+ attr->alt_ah_attr.grh.flow_label = cmd->base.alt_dest.flow_label;
+ attr->alt_ah_attr.grh.sgid_index = cmd->base.alt_dest.sgid_index;
+ attr->alt_ah_attr.grh.hop_limit = cmd->base.alt_dest.hop_limit;
+ attr->alt_ah_attr.grh.traffic_class = cmd->base.alt_dest.traffic_class;
+ attr->alt_ah_attr.dlid = cmd->base.alt_dest.dlid;
+ attr->alt_ah_attr.sl = cmd->base.alt_dest.sl;
+ attr->alt_ah_attr.src_path_bits = cmd->base.alt_dest.src_path_bits;
+ attr->alt_ah_attr.static_rate = cmd->base.alt_dest.static_rate;
+ attr->alt_ah_attr.ah_flags = cmd->base.alt_dest.is_global ?
+ IB_AH_GRH : 0;
+ attr->alt_ah_attr.port_num = cmd->base.alt_dest.port_num;
if (qp->real_qp == qp) {
- ret = ib_resolve_eth_dmac(qp, attr, &cmd.attr_mask);
+ ret = ib_resolve_eth_dmac(qp, attr, &cmd->base.attr_mask);
if (ret)
goto release_qp;
ret = qp->device->modify_qp(qp, attr,
- modify_qp_mask(qp->qp_type, cmd.attr_mask), &udata);
+ modify_qp_mask(qp->qp_type,
+ cmd->base.attr_mask),
+ udata);
} else {
- ret = ib_modify_qp(qp, attr, modify_qp_mask(qp->qp_type, cmd.attr_mask));
+ ret = ib_modify_qp(qp, attr,
+ modify_qp_mask(qp->qp_type,
+ cmd->base.attr_mask));
}
- if (ret)
- goto release_qp;
-
- ret = in_len;
-
release_qp:
put_qp_read(qp);
@@ -2425,6 +2417,68 @@ ssize_t ib_uverbs_modify_qp(struct ib_uverbs_file *file,
return ret;
}
+ssize_t ib_uverbs_modify_qp(struct ib_uverbs_file *file,
+ struct ib_device *ib_dev,
+ const char __user *buf, int in_len,
+ int out_len)
+{
+ struct ib_uverbs_ex_modify_qp cmd = {};
+ struct ib_udata udata;
+ int ret;
+
+ if (copy_from_user(&cmd.base, buf, sizeof(cmd.base)))
+ return -EFAULT;
+
+ if (cmd.base.attr_mask &
+ ~((IB_USER_LEGACY_LAST_QP_ATTR_MASK << 1) - 1))
+ return -EOPNOTSUPP;
+
+ INIT_UDATA(&udata, buf + sizeof(cmd.base), NULL,
+ in_len - sizeof(cmd.base), out_len);
+
+ ret = modify_qp(file, &cmd, &udata);
+ if (ret)
+ return ret;
+
+ return in_len;
+}
+
+int ib_uverbs_ex_modify_qp(struct ib_uverbs_file *file,
+ struct ib_device *ib_dev,
+ struct ib_udata *ucore,
+ struct ib_udata *uhw)
+{
+ struct ib_uverbs_ex_modify_qp cmd = {};
+ int ret;
+
+ /*
+ * Last bit is reserved for extending the attr_mask by
+ * using another field.
+ */
+ BUILD_BUG_ON(IB_USER_LAST_QP_ATTR_MASK == (1 << 31));
+
+ if (ucore->inlen < sizeof(cmd.base))
+ return -EINVAL;
+
+ ret = ib_copy_from_udata(&cmd, ucore, min(sizeof(cmd), ucore->inlen));
+ if (ret)
+ return ret;
+
+ if (cmd.base.attr_mask &
+ ~((IB_USER_LAST_QP_ATTR_MASK << 1) - 1))
+ return -EOPNOTSUPP;
+
+ if (ucore->inlen > sizeof(cmd)) {
+ if (ib_is_udata_cleared(ucore, sizeof(cmd),
+ ucore->inlen - sizeof(cmd)))
+ return -EOPNOTSUPP;
+ }
+
+ ret = modify_qp(file, &cmd, uhw);
+
+ return ret;
+}
+
ssize_t ib_uverbs_destroy_qp(struct ib_uverbs_file *file,
struct ib_device *ib_dev,
const char __user *buf, int in_len,
diff --git a/drivers/infiniband/core/uverbs_main.c b/drivers/infiniband/core/uverbs_main.c
index 44b1104..cde7a56 100644
--- a/drivers/infiniband/core/uverbs_main.c
+++ b/drivers/infiniband/core/uverbs_main.c
@@ -137,6 +137,7 @@ static int (*uverbs_ex_cmd_table[])(struct ib_uverbs_file *file,
[IB_USER_VERBS_EX_CMD_DESTROY_WQ] = ib_uverbs_ex_destroy_wq,
[IB_USER_VERBS_EX_CMD_CREATE_RWQ_IND_TBL] = ib_uverbs_ex_create_rwq_ind_table,
[IB_USER_VERBS_EX_CMD_DESTROY_RWQ_IND_TBL] = ib_uverbs_ex_destroy_rwq_ind_table,
+ [IB_USER_VERBS_EX_CMD_MODIFY_QP] = ib_uverbs_ex_modify_qp,
};
static void ib_uverbs_add_one(struct ib_device *device);
diff --git a/include/uapi/rdma/ib_user_verbs.h b/include/uapi/rdma/ib_user_verbs.h
index 25225eb..ea59bd5 100644
--- a/include/uapi/rdma/ib_user_verbs.h
+++ b/include/uapi/rdma/ib_user_verbs.h
@@ -37,6 +37,7 @@
#define IB_USER_VERBS_H
#include <linux/types.h>
+#include <rdma/ib_verbs.h>
/*
* Increment this value if any changes that break userspace ABI
@@ -93,6 +94,7 @@ enum {
IB_USER_VERBS_EX_CMD_QUERY_DEVICE = IB_USER_VERBS_CMD_QUERY_DEVICE,
IB_USER_VERBS_EX_CMD_CREATE_CQ = IB_USER_VERBS_CMD_CREATE_CQ,
IB_USER_VERBS_EX_CMD_CREATE_QP = IB_USER_VERBS_CMD_CREATE_QP,
+ IB_USER_VERBS_EX_CMD_MODIFY_QP = IB_USER_VERBS_CMD_MODIFY_QP,
IB_USER_VERBS_EX_CMD_CREATE_FLOW = IB_USER_VERBS_CMD_THRESHOLD,
IB_USER_VERBS_EX_CMD_DESTROY_FLOW,
IB_USER_VERBS_EX_CMD_CREATE_WQ,
@@ -545,6 +547,14 @@ enum {
IB_UVERBS_CREATE_QP_SUP_COMP_MASK = IB_UVERBS_CREATE_QP_MASK_IND_TABLE,
};
+enum {
+ IB_USER_LEGACY_LAST_QP_ATTR_MASK = IB_QP_DEST_QPN
+};
+
+enum {
+ IB_USER_LAST_QP_ATTR_MASK = IB_QP_RATE_LIMIT
+};
+
struct ib_uverbs_ex_create_qp {
__u64 user_handle;
__u32 pd_handle;
@@ -684,9 +694,20 @@ struct ib_uverbs_modify_qp {
__u64 driver_data[0];
};
+struct ib_uverbs_ex_modify_qp {
+ struct ib_uverbs_modify_qp base;
+ __u32 rate_limit;
+ __u32 reserved;
+};
+
struct ib_uverbs_modify_qp_resp {
};
+struct ib_uverbs_ex_modify_qp_resp {
+ __u32 comp_mask;
+ __u32 response_length;
+};
+
struct ib_uverbs_destroy_qp {
__u64 response;
__u32 qp_handle;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH rdma-next V1 2/4] IB/core: Support rate limit for packet pacing
From: Leon Romanovsky @ 2016-12-01 11:43 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Bodong Wang
In-Reply-To: <1480592596-20126-1-git-send-email-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
From: Bodong Wang <bodong-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Add new member rate_limit to ib_qp_attr which holds the packet pacing rate
in kbps, 0 means unlimited.
IB_QP_RATE_LIMIT is added to ib_attr_mask and could be used by RAW
QPs when changing QP state from RTR to RTS, RTS to RTS.
Signed-off-by: Bodong Wang <bodong-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Matan Barak <matanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
drivers/infiniband/core/verbs.c | 2 ++
include/rdma/ib_verbs.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c
index 8368764..3e688b3 100644
--- a/drivers/infiniband/core/verbs.c
+++ b/drivers/infiniband/core/verbs.c
@@ -1014,6 +1014,7 @@ static const struct {
IB_QP_QKEY),
[IB_QPT_GSI] = (IB_QP_CUR_STATE |
IB_QP_QKEY),
+ [IB_QPT_RAW_PACKET] = IB_QP_RATE_LIMIT,
}
}
},
@@ -1047,6 +1048,7 @@ static const struct {
IB_QP_QKEY),
[IB_QPT_GSI] = (IB_QP_CUR_STATE |
IB_QP_QKEY),
+ [IB_QPT_RAW_PACKET] = IB_QP_RATE_LIMIT,
}
},
[IB_QPS_SQD] = {
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 5ad43a4..a065361 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1102,6 +1102,7 @@ enum ib_qp_attr_mask {
IB_QP_RESERVED2 = (1<<22),
IB_QP_RESERVED3 = (1<<23),
IB_QP_RESERVED4 = (1<<24),
+ IB_QP_RATE_LIMIT = (1<<25),
};
enum ib_qp_state {
@@ -1151,6 +1152,7 @@ struct ib_qp_attr {
u8 rnr_retry;
u8 alt_port_num;
u8 alt_timeout;
+ u32 rate_limit;
};
enum ib_wr_opcode {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH rdma-next V1 1/4] IB/mlx5: Report mlx5 packet pacing capabilities when querying device
From: Leon Romanovsky @ 2016-12-01 11:43 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Bodong Wang
In-Reply-To: <1480592596-20126-1-git-send-email-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
From: Bodong Wang <bodong-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Enable mlx5 based hardware to report packet pacing capabilities
from kernel to user space. Packet pacing allows to limit the rate to any
number between the maximum and minimum, based on user settings.
The capabilities are exposed to user space through query_device by uhw.
The following capabilities are reported:
1. The maximum and minimum rate limit in kbps supported by packet pacing.
2. Bitmap showing which QP types are supported by packet pacing operation.
Signed-off-by: Bodong Wang <bodong-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Reviewed-by: Matan Barak <matanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
drivers/infiniband/hw/mlx5/main.c | 13 +++++++++++++
include/uapi/rdma/mlx5-abi.h | 13 +++++++++++++
2 files changed, 26 insertions(+)
diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
index 1e47999..fba8cab 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -669,6 +669,19 @@ static int mlx5_ib_query_device(struct ib_device *ibdev,
1 << MLX5_CAP_GEN(dev->mdev, log_max_rq);
}
+ if (field_avail(typeof(resp), packet_pacing_caps, uhw->outlen)) {
+ if (MLX5_CAP_QOS(mdev, packet_pacing) &&
+ MLX5_CAP_GEN(mdev, qos)) {
+ resp.packet_pacing_caps.qp_rate_limit_max =
+ MLX5_CAP_QOS(mdev, packet_pacing_max_rate);
+ resp.packet_pacing_caps.qp_rate_limit_min =
+ MLX5_CAP_QOS(mdev, packet_pacing_min_rate);
+ resp.packet_pacing_caps.supported_qpts |=
+ 1 << IB_QPT_RAW_PACKET;
+ }
+ resp.response_length += sizeof(resp.packet_pacing_caps);
+ }
+
if (uhw->outlen) {
err = ib_copy_to_udata(uhw, &resp, resp.response_length);
diff --git a/include/uapi/rdma/mlx5-abi.h b/include/uapi/rdma/mlx5-abi.h
index f5d0f4e..4e9338d 100644
--- a/include/uapi/rdma/mlx5-abi.h
+++ b/include/uapi/rdma/mlx5-abi.h
@@ -124,11 +124,24 @@ struct mlx5_ib_rss_caps {
__u8 reserved[7];
};
+struct mlx5_packet_pacing_caps {
+ __u32 qp_rate_limit_min;
+ __u32 qp_rate_limit_max; /* In kpbs */
+
+ /* Corresponding bit will be set if qp type from
+ * 'enum ib_qp_type' is supported, e.g.
+ * supported_qpts |= 1 << IB_QPT_RAW_PACKET
+ */
+ __u32 supported_qpts;
+ __u32 reserved;
+};
+
struct mlx5_ib_query_device_resp {
__u32 comp_mask;
__u32 response_length;
struct mlx5_ib_tso_caps tso_caps;
struct mlx5_ib_rss_caps rss_caps;
+ struct mlx5_packet_pacing_caps packet_pacing_caps;
};
struct mlx5_ib_create_cq {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH rdma-next V1 0/4] Add packet pacing support for IB verbs
From: Leon Romanovsky @ 2016-12-01 11:43 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
Packet pacing is a feature to control packet injection rate in
arbitrary rates. One typical use case is for streaming vendors to
control the bandwidth of different customers based on service coverage.
Packet pacing is a rate limiting and shaping for a QP (SQ for RAW QP),
set and change the rate is done by modifying QP. This series of patch
made the following high level changes:
1. Report rate limit capabilities through user data. Reported
capabilities include: The maximum and minimum rate limit in kbps
supported by packet pacing; Bitmap showing which QP types are
supported by packet pacing operation.
2. Extend modify QP interface for growing attributes. Add rate limit
support to the extended interface.
3. Enable mlx5-based hardware to be able to update the rate limit for
RAW QP packet.
Rate limit could also be achieved by using path record data(static_rate),
however, compare to packet pacing, the drawbacks are:
- The rate field is only u8, and uses IB standard rate enumerations.
Users have very limited options. Packet pacing supports arbitrary
rates with a resolution of 1kbps.
- Path record data doesn't apply to Raw Ethernet QPs, because these are
not 1:1 connected as RC, nor use address handles as UD.
The rate_limit configuration came from the application like required BW
for the streaming and not from the fabric (SM). Both of these features
are limiting the rate but coming from a different entities and required
separate fields. The actual limit should be the minimum of both of them
(if both features apply).
This patch series depend on the following patches:
Add port counter support for raw packet QP
[1] http://www.spinics.net/lists/linux-rdma/msg39607.html
Available in the "topic/packet_pacing" topic branch of this git repo:
git://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git
Or for browsing:
https://git.kernel.org/cgit/linux/kernel/git/leon/linux-rdma.git/log/?h=topic/packet_pacing
Thanks.
Changes from V0:
1. New bit masks IB_USER_LEGACY_LAST_QP_ATTR_MASK and
IB_USER_LAST_QP_ATTR_MASK are added to detect non-supported masks for
legacy/ex commands.
2. The ib_uverbs_ex_modify_qp should call uhw rather than ucore at the end.
Bodong Wang (4):
IB/mlx5: Report mlx5 packet pacing capabilities when querying device
IB/core: Support rate limit for packet pacing
IB/uverbs: Extend modify_qp and support packet pacing
IB/mlx5: Update the rate limit according to user setting for RAW QP
drivers/infiniband/core/uverbs.h | 1 +
drivers/infiniband/core/uverbs_cmd.c | 192 ++++++++++++++++++++++------------
drivers/infiniband/core/uverbs_main.c | 1 +
drivers/infiniband/core/verbs.c | 2 +
drivers/infiniband/hw/mlx5/main.c | 16 ++-
drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 +
drivers/infiniband/hw/mlx5/qp.c | 74 +++++++++++--
include/rdma/ib_verbs.h | 2 +
include/uapi/rdma/ib_user_verbs.h | 21 ++++
include/uapi/rdma/mlx5-abi.h | 13 +++
10 files changed, 245 insertions(+), 78 deletions(-)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Versions of packages included in rdma-core
From: Leon Romanovsky @ 2016-12-01 11:24 UTC (permalink / raw)
To: Philipp Thomas
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Stefan Fent,
Johannes Thumshirn
In-Reply-To: <20161201100308.7zg4x557as7ruwge-TXhXIaCUHZEYitT5tn2FcQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3429 bytes --]
On Thu, Dec 01, 2016 at 11:03:08AM +0100, Philipp Thomas wrote:
> Hi Leon,
>
> * Leon Romanovsky (leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org) [20161201 09:18]:
>
> > We imported everything published in their respective git repositories.
> But as it looks there isn't a log entry that marks the import. This makes it
> hard to compare what we have in SLES to rdma-core to determine whether we do
> the switch for the next service pack or wait for the next major SLES
> version.
>
> > Did you try to use git log --follow relevant_file?
>
> I didn't know that. But that would mean I would have to compare the git logs
> of all imported packages to see where they star t to differ :( I had hoped
> for an easier way, oh well...
Yes, there is an easy path :)
➜ rdma-core git:(master) git show 2172d3c6d73e
commit 2172d3c6d73e336743d6a08ca4e9c618595c2bc5
Merge: 0083ff6 27d8654 e8c50a2 6d6ace8 560afd8 94aaf19 0de1a98 9c4dc56
f8cc421 f7340fc ef7827c f2d901b dfa0d02 cfd7546 364b7da 663098b 2f00a5b
83d9ee5
Author: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Date: Tue Sep 20 11:42:56 2016 -0600
Initial commit
This was built from the original upstream repositories:
ibacm https://github.com/ofiwg/ibacm.git 6b3303c6d88b40d11e86953e773e14bc9e6d79c7
iwpmd git://git.openfabrics.org/~tnikolova/libiwpm a42bdc977a832071404eaf307b81e0e31f8a4e64
libcxgb3 git://git.openfabrics.org/~swise/libcxgb3.git 12b68e5d8e2e0b89a73f90af6e8a06bb7a748271
libcxgb4 git://git.openfabrics.org/~swise/libcxgb4.git fab9b66438ef19d692d6ce6d7dd346043454696c
libhfi1verbs https://github.com/01org/opa-libhfi1verbs.git c8df83205622a21d7062ac68cc8c4238953bba7d
libi40iw git://git.openfabrics.org/~tnikolova/libi40iw/.git 9d35609f79d6a235e23182e9ceadf3605b2682da
libibcm git://git.openfabrics.org/~shefty/libibcm.git b04920e8bfe0689a2fe67815321dcf646fd48a7e
libibumad git://git.openfabrics.org/~halr/libibumad.git 0765c870a6ddc16a57b68d981a2ff108c178dc93
libibverbs git://git.kernel.org/pub/scm/libs/infiniband/libibverbs.git 3b3973377f0dbccb11323b86e267308052cc4458
libipathverbs https://github.com/01org/libipathverbs.git 8291d485f3a5544b43974e7be88f3646f35ae07c
libmlx4 git://git.openfabrics.org/~yishaih/libmlx4.git 8aee6a7d2104395fb967fb52564adbb2dc2b83c4
libmlx5 git://git.openfabrics.org/~yishaih/libmlx5.git 0f2c49cfdb86b01af5387f34ee20960b258998f8
libmthca git://git.kernel.org/pub/scm/libs/infiniband/libmthca.git 6f4dd7451ddef120247e13fa6cb8e1df69c3ddf9
libnes git://git.openfabrics.org/~tnikolova/libnes/.git 51f4aa8ced48a241cfccb6e318cc58e44ab260bc
libocrdma git://git.openfabrics.org/~emulex/libocrdma.git 41f6bbb3fe8129678c233da439d872b3fe9f75dc
librdmacm https://github.com/ofiwg/librdmacm.git 37ae092e626d9cc58a888eedca44f21ccdd7632a
librxe https://github.com/SoftRoCE/librxe-dev.git 227e3c49b6e423c066e1e1887fe30c8261f63cbd
srp_daemon git://git.openfabrics.org/~bvanassche/srptools.git 4ce3074a1f94f93c9b629437e89312d919d323fc
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
>
> Philipp
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: Versions of packages included in rdma-core
From: Philipp Thomas @ 2016-12-01 10:03 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA; +Cc: Stefan Fent, Johannes Thumshirn
In-Reply-To: <20161201081826.GD4497-2ukJVAZIZ/Y@public.gmane.org>
Hi Leon,
* Leon Romanovsky (leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org) [20161201 09:18]:
> We imported everything published in their respective git repositories.
But as it looks there isn't a log entry that marks the import. This makes it
hard to compare what we have in SLES to rdma-core to determine whether we do
the switch for the next service pack or wait for the next major SLES
version.
> Did you try to use git log --follow relevant_file?
I didn't know that. But that would mean I would have to compare the git logs
of all imported packages to see where they star t to differ :( I had hoped
for an easier way, oh well...
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Versions of packages included in rdma-core
From: Leon Romanovsky @ 2016-12-01 8:18 UTC (permalink / raw)
To: Philipp Thomas; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161201080430.jrcketnrljckdbix-TXhXIaCUHZEYitT5tn2FcQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 766 bytes --]
On Thu, Dec 01, 2016 at 09:04:30AM +0100, Philipp Thomas wrote:
> In order to assess the impact of moving to rdma-core I'm trying to find out
> which individual versions were used when merging the seperate parts of
> rdma-core but up until now I haven't found any info. So I would be gratefull
> for any help.
Hi Philipp,
We imported everything published in their respective git repositories.
Did you try to use git log --follow relevant_file?
Thanks
>
> cu
> Philipp
>
> PS: PLease keep me in CC as I'm not yet subscribed to the list.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] infiniband: mthca: Replace pci_pool_alloc by pci_pool_zalloc
From: Yuval Shaia @ 2016-12-01 8:12 UTC (permalink / raw)
To: Souptick Joarder
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w, Hal Rosenstock,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Rameshwar Sahu
In-Reply-To: <CAFqt6zYAM8CUsBmTxU9KGw3Xum9oWzJTs3azizuvvhGkPJ1kTQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Dec 01, 2016 at 11:36:24AM +0530, Souptick Joarder wrote:
> On Mon, Nov 28, 2016 at 6:21 PM, Souptick Joarder <jrdr.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > In mthca_create_ah(), pci_pool_alloc() followed by memset will be
> > replaced by pci_pool_zalloc()
> >
> > Signed-off-by: Souptick joarder <jrdr.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > ---
> > drivers/infiniband/hw/mthca/mthca_av.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/infiniband/hw/mthca/mthca_av.c b/drivers/infiniband/hw/mthca/mthca_av.c
> > index bcac294..c202c89 100644
> > --- a/drivers/infiniband/hw/mthca/mthca_av.c
> > +++ b/drivers/infiniband/hw/mthca/mthca_av.c
> > @@ -186,7 +186,7 @@ int mthca_create_ah(struct mthca_dev *dev,
> >
> > on_hca_fail:
> > if (ah->type == MTHCA_AH_PCI_POOL) {
> > - ah->av = pci_pool_alloc(dev->av_table.pool,
> > + ah->av = pci_pool_zalloc(dev->av_table.pool,
> > GFP_ATOMIC, &ah->avdma);
> > if (!ah->av)
> > return -ENOMEM;
> > @@ -196,7 +196,6 @@ int mthca_create_ah(struct mthca_dev *dev,
> >
> > ah->key = pd->ntmr.ibmr.lkey;
> >
> > - memset(av, 0, MTHCA_AV_SIZE);
> >
> > av->port_pd = cpu_to_be32(pd->pd_num | (ah_attr->port_num << 24));
> > av->g_slid = ah_attr->src_path_bits;
> > --
> > 1.9.1
> >
>
> Any comment on this patch?
I believe the same comments as for "mellanox :mlx4: Replace pci_pool_alloc
by pci_pool_zalloc", i.e. indentation of GFP_ATOMIC (AFAIK it can join the
line above) and removal of unneeded empty line.
Besides these two cosmetics comments the patch seems to be fine.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Versions of packages included in rdma-core
From: Philipp Thomas @ 2016-12-01 8:04 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In order to assess the impact of moving to rdma-core I'm trying to find out
which individual versions were used when merging the seperate parts of
rdma-core but up until now I haven't found any info. So I would be gratefull
for any help.
cu
Philipp
PS: PLease keep me in CC as I'm not yet subscribed to the list.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 02/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) Bus driver
From: Vishwanathapura, Niranjana @ 2016-12-01 7:41 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: ira.weiny, Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Dennis Dalessandro
In-Reply-To: <20161129162113.GC742-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Tue, Nov 29, 2016 at 09:21:13AM -0700, Jason Gunthorpe wrote:
>On Mon, Nov 28, 2016 at 10:29:38PM -0800, Vishwanathapura, Niranjana wrote:
>> On Thu, Nov 24, 2016 at 09:15:45AM -0700, Jason Gunthorpe wrote:
>> >>And will move the hfi_vnic module under
>> >>???drivers/infiniband/ulp/hfi_vnic???.
>> >
>> >I would prefer drivers/net/ethernet
>> >
>> >This is clearly not a ULP since it doesn't use verbs.
>> >
>>
>> I understand it is not using verbs, but the control path (ib_device client)
>> is using verbs (IB MAD).
>> Our prefernce is to keep it somewhere under drivers/infiniband. Summarizing
>> reasons again here,
>>
>> - VNIC control driver (ib_device client) is an IB MAD agent.
>> - It is purly a software construct, encapsualtes ethernet packets in
>> Omni-path packet and depends on hfi1 driver here for HW access.
>
>Is the majority of the code MAD focused or net stack focused?
>
>I'm not sure it matters, it isn't like we can review Intel's
>proprietary mad stuff anyhow. :\
>
>Jason
That is an intersting measure. In hfi_vnic driver, I would say, >60% of the
code is MAD focused, mainly interfacing with the IB MAD agent.
It also includes populating/parsing those MAD packets. At the least it is not
supporting the driver to be put under net folder.
Even in the remaining <40%, half of it is involved with encapsulating ethernet
frames with Omni-path header (does this makes it belong under
drivers/infiniband/hw?).
The net stack interface part is pretty standard, hence is not much of code.
I do see the reason to put it under net folder, but I am seeing more reason for
it to be somewhere under drivers/infiniband.
Niranjana
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 02/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) Bus driver
From: Vishwanathapura, Niranjana @ 2016-12-01 7:39 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Hefty, Sean, Weiny, Ira, Doug Ledford,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Dalessandro, Dennis
In-Reply-To: <20161129165009.GA3167-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Tue, Nov 29, 2016 at 09:50:09AM -0700, Jason Gunthorpe wrote:
>On Tue, Nov 29, 2016 at 04:44:37PM +0000, Hefty, Sean wrote:
>> > 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.
>
>If Intel wants to build a HFI subystem within RDMA with multiple
>drivers then sure, but they are not there yet, and we don't even know
>what that could look like. So it is better to leave it simple for now.
>
>Jason
Sorry for the delay, I was weighing in couple options.
We envisioned vnic as a pure software construct and hence should be independent
(like ipoib). ie., both hfi_vnic and hfi1 should be independently loadable
(like ipoib) despite hfi_vnic being dependent on hfi1 here for HW access.
There doesn't seem to be much value of hfi_vnic being a 'ib client', if it
still has compilation and module dependency on hfi1 module.
The more I think of it, having vnic ops added to ib device structure (option
(b)) makes it cleaner (no dependency). We can probably consider extending 'ib
device' in hfi1 in order for hfi_vnic to get to the vnic ops. But (b) makes it
simpler.
Though Jason's suggestion could be a temporary measure for this patch series,
the above approach is what I would like to target here.
Niranjana
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH rdma-next 1/4] IB/mlx4: Fix out-of-range array index in destroy qp flow
From: Leon Romanovsky @ 2016-12-01 7:02 UTC (permalink / raw)
To: Bart Van Assche
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jack Morgenstein
In-Reply-To: <BLUPR02MB16836D6466A901D088E1FE65818F0-Y8PPn9RqzNfZ9ihocuPUdanrV9Ap65cLvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]
On Thu, Dec 01, 2016 at 05:35:42AM +0000, Bart Van Assche wrote:
> On 11/30/16 21:31, Leon Romanovsky wrote:
> > On Mon, Nov 28, 2016 at 08:29:55AM -0800, Bart Van Assche wrote:
> >> On 11/28/2016 12:31 AM, Leon Romanovsky wrote:
> >>> I'm extra cautions with stable tags and prefer to finalize my stable
> >>> checker in my submissions scripts first, before adding it manually and
> >>> I have plans to use it next kernel release.
> >>
> >> Thanks for explaining your workflow. However, the question remains whether
> >> or not stable tags should be added to the patches in this series?
> >
> > It can be added but I don't see any real advantage of it. Do you know
> > about real users who run RDMA stack from stable trees and don't rely on
> > distro kernel and/or OFED?
>
> Hello Leon,
>
> Many users who build an iSER or SRP storage target themselves use a
> recent stable kernel without OFED.
Hello Bart,
I'll take into account these users in my future submissions. Meanwhile this
series can be easily picked by various automatic scripts which stable
maintainers are running.
Thanks.
>
> Bart.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] i40iw: Set TOS field in IP header
From: Or Gerlitz @ 2016-12-01 6:17 UTC (permalink / raw)
To: Henry Orosco, Shiraz Saleem
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
e1000-rdma-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20161130210934.18088-1-henry.orosco-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On Wed, Nov 30, 2016 at 11:09 PM, Henry Orosco <henry.orosco-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
[...]
> Set the TOS field in IP header with the value passed in from application.
How is TOS propagated from applications? is that through the verbs
API, which function/param?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] infiniband: mthca: Replace pci_pool_alloc by pci_pool_zalloc
From: Souptick Joarder @ 2016-12-01 6:06 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w, Hal Rosenstock
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Rameshwar Sahu
In-Reply-To: <20161128125126.GA32365@gnr743-HP-ZBook-15>
On Mon, Nov 28, 2016 at 6:21 PM, Souptick Joarder <jrdr.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> In mthca_create_ah(), pci_pool_alloc() followed by memset will be
> replaced by pci_pool_zalloc()
>
> Signed-off-by: Souptick joarder <jrdr.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/infiniband/hw/mthca/mthca_av.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/infiniband/hw/mthca/mthca_av.c b/drivers/infiniband/hw/mthca/mthca_av.c
> index bcac294..c202c89 100644
> --- a/drivers/infiniband/hw/mthca/mthca_av.c
> +++ b/drivers/infiniband/hw/mthca/mthca_av.c
> @@ -186,7 +186,7 @@ int mthca_create_ah(struct mthca_dev *dev,
>
> on_hca_fail:
> if (ah->type == MTHCA_AH_PCI_POOL) {
> - ah->av = pci_pool_alloc(dev->av_table.pool,
> + ah->av = pci_pool_zalloc(dev->av_table.pool,
> GFP_ATOMIC, &ah->avdma);
> if (!ah->av)
> return -ENOMEM;
> @@ -196,7 +196,6 @@ int mthca_create_ah(struct mthca_dev *dev,
>
> ah->key = pd->ntmr.ibmr.lkey;
>
> - memset(av, 0, MTHCA_AV_SIZE);
>
> av->port_pd = cpu_to_be32(pd->pd_num | (ah_attr->port_num << 24));
> av->g_slid = ah_attr->src_path_bits;
> --
> 1.9.1
>
Any comment on this patch?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH rdma-next 1/4] IB/mlx4: Fix out-of-range array index in destroy qp flow
From: Bart Van Assche @ 2016-12-01 5:35 UTC (permalink / raw)
To: Leon Romanovsky
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jack Morgenstein
In-Reply-To: <20161201053105.GA4497@leon.nu>
On 11/30/16 21:31, Leon Romanovsky wrote:
> On Mon, Nov 28, 2016 at 08:29:55AM -0800, Bart Van Assche wrote:
>> On 11/28/2016 12:31 AM, Leon Romanovsky wrote:
>>> I'm extra cautions with stable tags and prefer to finalize my stable
>>> checker in my submissions scripts first, before adding it manually and
>>> I have plans to use it next kernel release.
>>
>> Thanks for explaining your workflow. However, the question remains whether
>> or not stable tags should be added to the patches in this series?
>
> It can be added but I don't see any real advantage of it. Do you know
> about real users who run RDMA stack from stable trees and don't rely on
> distro kernel and/or OFED?
Hello Leon,
Many users who build an iSER or SRP storage target themselves use a
recent stable kernel without OFED.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox