Re: [PATCH 4/7] devcg: Added rdma resource tracker object per task

On Tue, Sep 8, 2015 at 1:54 PM, Haggai Eran wrote: > On 08/09/2015 10:04, Parav Pandit wrote: >> On Tue, Sep 8, 2015 at 11:18 AM, Haggai Eran wrote: >>> On 07/09/2015 23:38, Parav Pandit wrote: @@ -2676,7 +2686,7 @@ static inline int

Re: [PATCH 5/7] devcg: device cgroup's extension for RDMA resource.

On 07/09/2015 23:38, Parav Pandit wrote: > +void devcgroup_rdma_uncharge_resource(struct ib_ucontext *ucontext, > + enum devcgroup_rdma_rt type, int num) > +{ > + struct dev_cgroup *dev_cg, *p; > + struct task_struct *ctx_task; > + > + if (!num) > +

Re: [PATCH 6/7] devcg: Added support to use RDMA device cgroup.

On 07/09/2015 23:38, Parav Pandit wrote: > +static void init_ucontext_lists(struct ib_ucontext *ucontext) > +{ > + INIT_LIST_HEAD(>pd_list); > + INIT_LIST_HEAD(>mr_list); > + INIT_LIST_HEAD(>mw_list); > + INIT_LIST_HEAD(>cq_list); > + INIT_LIST_HEAD(>qp_list); > +

Re: [PATCH 4/7] devcg: Added rdma resource tracker object per task

On Tue, Sep 8, 2015 at 11:18 AM, Haggai Eran wrote: > On 07/09/2015 23:38, Parav Pandit wrote: >> @@ -2676,7 +2686,7 @@ static inline int thread_group_empty(struct >> task_struct *p) >> * Protects ->fs, ->files, ->mm, ->group_info, ->comm, keyring >> * subscriptions and

Re: [PATCH 3/7] devcg: Added infrastructure for rdma device cgroup.

On Tue, Sep 8, 2015 at 11:01 AM, Haggai Eran wrote: > On 07/09/2015 23:38, Parav Pandit wrote: >> diff --git a/include/linux/device_cgroup.h b/include/linux/device_cgroup.h >> index 8b64221..cdbdd60 100644 >> --- a/include/linux/device_cgroup.h >> +++

Re: [PATCH 5/7] devcg: device cgroup's extension for RDMA resource.

On 07/09/2015 23:38, Parav Pandit wrote: > +/* RDMA resources from device cgroup perspective */ > +enum devcgroup_rdma_rt { > + DEVCG_RDMA_RES_TYPE_UCTX, > + DEVCG_RDMA_RES_TYPE_CQ, > + DEVCG_RDMA_RES_TYPE_PD, > + DEVCG_RDMA_RES_TYPE_AH, > + DEVCG_RDMA_RES_TYPE_MR, > +

Re: [PATCH 4/7] devcg: Added rdma resource tracker object per task

On 08/09/2015 10:04, Parav Pandit wrote: > On Tue, Sep 8, 2015 at 11:18 AM, Haggai Eran wrote: >> On 07/09/2015 23:38, Parav Pandit wrote: >>> @@ -2676,7 +2686,7 @@ static inline int thread_group_empty(struct >>> task_struct *p) >>> * Protects ->fs, ->files, ->mm,

Re: RDMA/CM and multiple QPs

On 9/6/2015 9:45 AM, Christoph Hellwig wrote: Hi All, right now RDMA/CM works on a QP basis, but seems very awakward if you want multiple QPs as part of a single logical device, which will be useful for a lot of modern protocols. For example we will need to check in the CM handler that we're

Re: [PATCH 5/7] devcg: device cgroup's extension for RDMA resource.

On Tue, Sep 8, 2015 at 2:06 PM, Haggai Eran wrote: > On 07/09/2015 23:38, Parav Pandit wrote: >> +void devcgroup_rdma_uncharge_resource(struct ib_ucontext *ucontext, >> + enum devcgroup_rdma_rt type, int num) >> +{ >> + struct dev_cgroup

Re: [PATCH 6/7] devcg: Added support to use RDMA device cgroup.

On Tue, Sep 8, 2015 at 2:10 PM, Haggai Eran wrote: > On 07/09/2015 23:38, Parav Pandit wrote: >> +static void init_ucontext_lists(struct ib_ucontext *ucontext) >> +{ >> + INIT_LIST_HEAD(>pd_list); >> + INIT_LIST_HEAD(>mr_list); >> + INIT_LIST_HEAD(>mw_list); >> +

Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

On 07/09/2015 23:38, Parav Pandit wrote: > Currently user space applications can easily take away all the rdma > device specific resources such as AH, CQ, QP, MR etc. Due to which other > applications in other cgroup or kernel space ULPs may not even get chance > to allocate any rdma resources. >

Re: [PATCH 5/7] devcg: device cgroup's extension for RDMA resource.

On Tue, Sep 8, 2015 at 1:52 PM, Haggai Eran wrote: > On 07/09/2015 23:38, Parav Pandit wrote: >> +/* RDMA resources from device cgroup perspective */ >> +enum devcgroup_rdma_rt { >> + DEVCG_RDMA_RES_TYPE_UCTX, >> + DEVCG_RDMA_RES_TYPE_CQ, >> +

RE: [PATCH] infiniband:core:Fix assumation that the function ib_send_cm_drep never fails in rdma_disconnect

> This fixes the incorrect assumation that the function ib_send_cm_drep > always runs successfully and never fails in the function rdma_disconnect > by making this call be assigned the variable used to return to callers > of rdma_disconnect in order to make sure that a error code is returned > if

RE: [PATCH for-next 0/5] set MPA revision to 2 and misc. fixes for iw_cxgb4

Signed-off-by: Steve Wise > -Original Message- > From: Hariprasad Shenai [mailto:haripra...@chelsio.com] > Sent: Monday, September 07, 2015 11:27 PM > To: dledf...@redhat.com > Cc: linux-rdma@vger.kernel.org; sw...@opengridcomputing.com; Hariprasad Shenai >

Re: RDMA/CM and multiple QPs

On 9/6/2015 11:15 AM, Bart Van Assche wrote: On 09/06/15 00:50, Christoph Hellwig wrote: Note that the SRP driver already in tree is a good example for this, although it doesn't use RDMA/CM and thus already operates on a per-ib_device level. The challenges with regard to adding RDMA/CM

Re: RDMA/CM and multiple QPs

On Tue, Sep 08, 2015 at 03:32:11PM +0300, Sagi Grimberg wrote: > The CM is responsible of establishing an RDMA channel. What you are > referring to is a concept of a session. I'm not entirely sure how we can > fit a model where the CM establishes a multi-channel session as the > CM request

Re: [PATCH 5/7] devcg: device cgroup's extension for RDMA resource.

On Tue, Sep 8, 2015 at 7:20 PM, Haggai Eran wrote: > On 08/09/2015 13:18, Parav Pandit wrote: >>> > >> + * RDMA resource limits are hierarchical, so the highest configured >> limit of >> + * the hierarchy is enforced. Allowing resource limit configuration to

Re: [PATCH 6/7] devcg: Added support to use RDMA device cgroup.

On 08/09/2015 13:22, Parav Pandit wrote: > On Tue, Sep 8, 2015 at 2:10 PM, Haggai Eran wrote: >> On 07/09/2015 23:38, Parav Pandit wrote: >>> +static void init_ucontext_lists(struct ib_ucontext *ucontext) >>> +{ >>> + INIT_LIST_HEAD(>pd_list); >>> +

Re: [PATCH 5/7] devcg: device cgroup's extension for RDMA resource.

On 08/09/2015 13:50, Parav Pandit wrote: > On Tue, Sep 8, 2015 at 2:06 PM, Haggai Eran wrote: >> On 07/09/2015 23:38, Parav Pandit wrote: >>> +void devcgroup_rdma_uncharge_resource(struct ib_ucontext *ucontext, >>> + enum devcgroup_rdma_rt

Re: [PATCH 5/7] devcg: device cgroup's extension for RDMA resource.

On 08/09/2015 13:18, Parav Pandit wrote: >> > >>> >> + * RDMA resource limits are hierarchical, so the highest configured >>> >> limit of >>> >> + * the hierarchy is enforced. Allowing resource limit configuration to >>> >> default >>> >> + * cgroup allows fair share to kernel space ULPs as

Re: RDMA/CM and multiple QPs

On 09/08/2015 06:57 AM, Tom Talpey wrote: On 9/6/2015 11:15 AM, Bart Van Assche wrote: On 09/06/15 00:50, Christoph Hellwig wrote: Note that the SRP driver already in tree is a good example for this, although it doesn't use RDMA/CM and thus already operates on a per-ib_device level. The

Re: [PULL REQUEST] Please pull rdma.git

On Tue, Sep 8, 2015 at 9:24 AM, Doug Ledford wrote: > > Matan Barak (5): > net: Add info for NETDEV_CHANGEUPPER event Why the hell is this coming in through the infiniband tree? Especially with the networking tree having done the same thing differently? I see that

Re: [PULL REQUEST] Please pull rdma.git

On Tue, Sep 8, 2015 at 5:21 PM, Linus Torvalds wrote: > > This needs a good explanation, because for now this pull request is dead to > me. Just to clarify: it's really the combination of: (a) you were told about this (b) you rebased your commit series after

Re: [PULL REQUEST] Please pull rdma.git

On Tue, Sep 8, 2015 at 7:50 PM, Doug Ledford wrote: > > Because the tree isn't buildable, let alone testable, without it. You're missing the ENTIRE POINT. > Well, I expected it to be handled without much effort on your part and > the existing network infrastructure to be

Re: [PULL REQUEST] Please pull rdma.git

On 09/08/2015 11:08 PM, Linus Torvalds wrote: > On Tue, Sep 8, 2015 at 7:50 PM, Doug Ledford wrote: >> >> Because the tree isn't buildable, let alone testable, without it. > > You're missing the ENTIRE POINT. > >> Well, I expected it to be handled without much effort on

Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

On Tue, Sep 8, 2015 at 8:53 PM, Tejun Heo wrote: > Hello, Parav. > > On Tue, Sep 08, 2015 at 02:08:16AM +0530, Parav Pandit wrote: >> Currently user space applications can easily take away all the rdma >> device specific resources such as AH, CQ, QP, MR etc. Due to which other >>

Re: [PULL REQUEST] Please pull rdma.git

On 09/08/2015 08:21 PM, Linus Torvalds wrote: > On Tue, Sep 8, 2015 at 9:24 AM, Doug Ledford wrote: >> >> Matan Barak (5): >> net: Add info for NETDEV_CHANGEUPPER event > > Why the hell is this coming in through the infiniband tree? Especially > with the networking

Re: [PULL REQUEST] Please pull rdma.git

On 09/08/2015 08:35 PM, Linus Torvalds wrote: > On Tue, Sep 8, 2015 at 5:21 PM, Linus Torvalds > wrote: >> >> This needs a good explanation, because for now this pull request is dead to >> me. > > Just to clarify: it's really the combination of: > > (a) you were

Re: [PULL REQUEST] Please pull rdma.git

On Tue, Sep 8, 2015 at 8:08 PM, Doug Ledford wrote: > > With a comment that said "I can carry this merge forward, no further > action is necessary on your part". That combined with my lack of deep > internal knowledge of what it is that Stephen is doing made me go "Ok, > he

[ANNOUNCE] OFED 3.18-1-rc1 release is available

Hi, OFED-3.18-1-rc1 is available at: https://openfabrics.org/downloads/OFED/ofed-3.18-1/OFED-3.18-1-rc1.tgz To get BUILD_ID run ofed_info Please report any issues in bugzilla http://bugs.openfabrics.org/bugzilla/ for OFED 3.18-1 Release notes:

RE: [PATCH] infiniband:core:Fix mutex locking to lock before unlocking in the function cma_ib_mc_handler

> This fixes mutex locking to lock before unlocking in the function > cma_ib_mc_handler for the mutex handler_mutex as part of the pointer > id_priv before unlocking it after the critical region for event handler > work and execution in order to have actual proper concurrent execution > protection

[PULL REQUEST] Please pull rdma.git

Hi Linus, This is a fairly sizeable set of changes. I've put them through a decent amount of testing prior to sending the pull request due to that. There are still a few fixups that I know are coming, but I wanted to go ahead and get the big, sizable chunk into your hands sooner rather than

RE: [PATCH] infiniband:Fix error handling in the function cm_init_av_by_path

> This fixes error handling in the function cm_init_av_by_path > to properly check if the internal call to the function > ib_init_ah_from_path has failed by returning a error code and > if so return immediately to the caller with this error code in > order to signal/allow the caller to handle the

Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

Hello, Parav. On Tue, Sep 08, 2015 at 02:08:16AM +0530, Parav Pandit wrote: > Currently user space applications can easily take away all the rdma > device specific resources such as AH, CQ, QP, MR etc. Due to which other > applications in other cgroup or kernel space ULPs may not even get chance

RE: [PATCH] infiniband:core:Fix error handling in the function join_handler

> diff --git a/drivers/infiniband/core/multicast.c > b/drivers/infiniband/core/multicast.c > index 2cb865c..9284337 100644 > --- a/drivers/infiniband/core/multicast.c > +++ b/drivers/infiniband/core/multicast.c > @@ -526,8 +526,9 @@ static void join_handler(int status, struct > ib_sa_mcmember_rec

[PATCH] IB/hfi1: fix pstateinfo from returning improperly byteswapped value

From: Ira Weiny Byteswap link_width_downgrade_*_active values before sending on the wire. In addition properly define the Port State Info structure. Reviewed-by: Dennis Dalessandro Reviewed-by: Christian Gomez