Hi Doug,
Leon has finished review as well in [7].
Christoph Acked too in [8].
Can you please advise whether
(1) I should rebase and resend PatchV12?
(2) If so for which branch - master/4.9 or?
Tejun and Christoph mentioned that it might be late for 4.9.
Can we atleast merge to linux-rdma tree,
Hi Doug,
Leon has finished review as well in [7].
Christoph Acked too in [8].
Can you please advise whether
(1) I should rebase and resend PatchV12?
(2) If so for which branch - master/4.9 or?
Tejun and Christoph mentioned that it might be late for 4.9.
Can we atleast merge to linux-rdma tree,
Hi Christoph,
On Wed, Oct 5, 2016 at 12:07 PM, Christoph Hellwig wrote:
> FYI, the patches look fine to me:
>
> Acked-by: Christoph Hellwig
>
Thanks a lot for review.
Parav
Hi Christoph,
On Wed, Oct 5, 2016 at 12:07 PM, Christoph Hellwig wrote:
> FYI, the patches look fine to me:
>
> Acked-by: Christoph Hellwig
>
Thanks a lot for review.
Parav
Hello,
On Wed, Oct 05, 2016 at 02:22:57PM +0300, Leon Romanovsky wrote:
> On Wed, Oct 05, 2016 at 08:37:35AM +0200, Christoph Hellwig wrote:
> > FYI, the patches look fine to me:
> >
> > Acked-by: Christoph Hellwig
> >
> > but we're past the merge window for 4.9 now unfortunately.
>
Hello,
On Wed, Oct 05, 2016 at 02:22:57PM +0300, Leon Romanovsky wrote:
> On Wed, Oct 05, 2016 at 08:37:35AM +0200, Christoph Hellwig wrote:
> > FYI, the patches look fine to me:
> >
> > Acked-by: Christoph Hellwig
> >
> > but we're past the merge window for 4.9 now unfortunately.
>
> IMHO, it
On Wed, Oct 05, 2016 at 08:37:35AM +0200, Christoph Hellwig wrote:
> FYI, the patches look fine to me:
>
> Acked-by: Christoph Hellwig
>
> but we're past the merge window for 4.9 now unfortunately.
IMHO, it still can make it.
Thanks
signature.asc
Description: PGP signature
On Wed, Oct 05, 2016 at 08:37:35AM +0200, Christoph Hellwig wrote:
> FYI, the patches look fine to me:
>
> Acked-by: Christoph Hellwig
>
> but we're past the merge window for 4.9 now unfortunately.
IMHO, it still can make it.
Thanks
signature.asc
Description: PGP signature
FYI, the patches look fine to me:
Acked-by: Christoph Hellwig
but we're past the merge window for 4.9 now unfortunately.
FYI, the patches look fine to me:
Acked-by: Christoph Hellwig
but we're past the merge window for 4.9 now unfortunately.
Hi Doug,
I am still waiting for Leon to provide his comments if any on rdma cgroup.
>From other email context, he was on vacation last week.
While we wait for his comments, I wanted to know your view of this
patchset in 4.9 merge window.
To summarize the discussion that happened in two threads.
Hi Doug,
I am still waiting for Leon to provide his comments if any on rdma cgroup.
>From other email context, he was on vacation last week.
While we wait for his comments, I wanted to know your view of this
patchset in 4.9 merge window.
To summarize the discussion that happened in two threads.
Hi Tejun,
On Wed, Sep 21, 2016 at 7:56 PM, Tejun Heo wrote:
> Hello, Parav.
>
> On Wed, Sep 21, 2016 at 10:13:38AM +0530, Parav Pandit wrote:
>> We have completed review from Tejun, Christoph.
>> HFI driver folks also provided feedback for Intel drivers.
>> Matan's also doesn't
Hi Tejun,
On Wed, Sep 21, 2016 at 7:56 PM, Tejun Heo wrote:
> Hello, Parav.
>
> On Wed, Sep 21, 2016 at 10:13:38AM +0530, Parav Pandit wrote:
>> We have completed review from Tejun, Christoph.
>> HFI driver folks also provided feedback for Intel drivers.
>> Matan's also doesn't have any more
Hello, Parav.
On Wed, Sep 21, 2016 at 10:13:38AM +0530, Parav Pandit wrote:
> We have completed review from Tejun, Christoph.
> HFI driver folks also provided feedback for Intel drivers.
> Matan's also doesn't have any more comments.
>
> If possible, if you can also review, it will be helpful.
>
Hello, Parav.
On Wed, Sep 21, 2016 at 10:13:38AM +0530, Parav Pandit wrote:
> We have completed review from Tejun, Christoph.
> HFI driver folks also provided feedback for Intel drivers.
> Matan's also doesn't have any more comments.
>
> If possible, if you can also review, it will be helpful.
>
Hi Leon,
On Fri, Sep 16, 2016 at 12:26 AM, Leon Romanovsky wrote:
> On Wed, Sep 14, 2016 at 12:36:19PM +0530, Parav Pandit wrote:
>> Hi Dennis,
>>
>> Do you know how would HFI1 driver would work along with rdma cgroup?
>>
>> Hi Matan, Leon, Jason,
>> Apart from HFI1, is there
Hi Leon,
On Fri, Sep 16, 2016 at 12:26 AM, Leon Romanovsky wrote:
> On Wed, Sep 14, 2016 at 12:36:19PM +0530, Parav Pandit wrote:
>> Hi Dennis,
>>
>> Do you know how would HFI1 driver would work along with rdma cgroup?
>>
>> Hi Matan, Leon, Jason,
>> Apart from HFI1, is there any other concern?
Hi Denny,
On Mon, Sep 19, 2016 at 6:40 PM, Dalessandro, Dennis
wrote:
> On Wed, 2016-09-14 at 12:36 +0530, Parav Pandit wrote:
>> Hi Dennis,
>>
>> Do you know how would HFI1 driver would work along with rdma cgroup?
>
> Keep in mind HFI1 driver has two "modes" of
Hi Denny,
On Mon, Sep 19, 2016 at 6:40 PM, Dalessandro, Dennis
wrote:
> On Wed, 2016-09-14 at 12:36 +0530, Parav Pandit wrote:
>> Hi Dennis,
>>
>> Do you know how would HFI1 driver would work along with rdma cgroup?
>
> Keep in mind HFI1 driver has two "modes" of operation. We support
> verbs,
On Wed, 2016-09-14 at 12:36 +0530, Parav Pandit wrote:
> Hi Dennis,
>
> Do you know how would HFI1 driver would work along with rdma cgroup?
Keep in mind HFI1 driver has two "modes" of operation. We support
verbs, and would surely fall in line with whatever cgroups do for IB
core. For our psm
On Wed, 2016-09-14 at 12:36 +0530, Parav Pandit wrote:
> Hi Dennis,
>
> Do you know how would HFI1 driver would work along with rdma cgroup?
Keep in mind HFI1 driver has two "modes" of operation. We support
verbs, and would surely fall in line with whatever cgroups do for IB
core. For our psm
On Wed, Sep 14, 2016 at 12:36:19PM +0530, Parav Pandit wrote:
> Hi Dennis,
>
> Do you know how would HFI1 driver would work along with rdma cgroup?
>
> Hi Matan, Leon, Jason,
> Apart from HFI1, is there any other concern?
> Or Patch is good to go?
I didn't review it yet :(.
Sorry
>
> 4.8 dates
On Wed, Sep 14, 2016 at 12:36:19PM +0530, Parav Pandit wrote:
> Hi Dennis,
>
> Do you know how would HFI1 driver would work along with rdma cgroup?
>
> Hi Matan, Leon, Jason,
> Apart from HFI1, is there any other concern?
> Or Patch is good to go?
I didn't review it yet :(.
Sorry
>
> 4.8 dates
Hi Matan,
On Wed, Sep 14, 2016 at 1:44 PM, Matan Barak wrote:
> On 14/09/2016 10:06, Parav Pandit wrote:
>>
>> Hi Dennis,
>>
>> Do you know how would HFI1 driver would work along with rdma cgroup?
>>
>> Hi Matan, Leon, Jason,
>> Apart from HFI1, is there any other concern?
>
Hi Matan,
On Wed, Sep 14, 2016 at 1:44 PM, Matan Barak wrote:
> On 14/09/2016 10:06, Parav Pandit wrote:
>>
>> Hi Dennis,
>>
>> Do you know how would HFI1 driver would work along with rdma cgroup?
>>
>> Hi Matan, Leon, Jason,
>> Apart from HFI1, is there any other concern?
>
>
> I just wonder
On 14/09/2016 10:06, Parav Pandit wrote:
Hi Dennis,
Do you know how would HFI1 driver would work along with rdma cgroup?
Hi Matan, Leon, Jason,
Apart from HFI1, is there any other concern?
I just wonder how things like RSS will work. For example, a RSS QP
doesn't really have a queue (if I
On 14/09/2016 10:06, Parav Pandit wrote:
Hi Dennis,
Do you know how would HFI1 driver would work along with rdma cgroup?
Hi Matan, Leon, Jason,
Apart from HFI1, is there any other concern?
I just wonder how things like RSS will work. For example, a RSS QP
doesn't really have a queue (if I
Hi Dennis,
Do you know how would HFI1 driver would work along with rdma cgroup?
Hi Matan, Leon, Jason,
Apart from HFI1, is there any other concern?
Or Patch is good to go?
4.8 dates are close by (2 weeks) and there are two git trees involved
(that might cause merge error to Linus) so if there
Hi Dennis,
Do you know how would HFI1 driver would work along with rdma cgroup?
Hi Matan, Leon, Jason,
Apart from HFI1, is there any other concern?
Or Patch is good to go?
4.8 dates are close by (2 weeks) and there are two git trees involved
(that might cause merge error to Linus) so if there
On Sun, Sep 11, 2016 at 11:52:35AM -0600, Jason Gunthorpe wrote:
> On Sun, Sep 11, 2016 at 07:24:45PM +0200, Christoph Hellwig wrote:
> > > > > I've posted some initial work toward a) a while ago, and once we
> > >
> > > Did it get merged? Do you have a pointer?
> >
> >
On Sun, Sep 11, 2016 at 11:52:35AM -0600, Jason Gunthorpe wrote:
> On Sun, Sep 11, 2016 at 07:24:45PM +0200, Christoph Hellwig wrote:
> > > > > I've posted some initial work toward a) a while ago, and once we
> > >
> > > Did it get merged? Do you have a pointer?
> >
> >
On Sun, Sep 11, 2016 at 07:24:45PM +0200, Christoph Hellwig wrote:
> > > > I've posted some initial work toward a) a while ago, and once we
> >
> > Did it get merged? Do you have a pointer?
>
> http://www.spinics.net/lists/linux-rdma/msg31958.html
Right, I remember that. Certainly the right
On Sun, Sep 11, 2016 at 07:24:45PM +0200, Christoph Hellwig wrote:
> > > > I've posted some initial work toward a) a while ago, and once we
> >
> > Did it get merged? Do you have a pointer?
>
> http://www.spinics.net/lists/linux-rdma/msg31958.html
Right, I remember that. Certainly the right
On Sun, Sep 11, 2016 at 11:14:09AM -0600, Jason Gunthorpe wrote:
> > > We stil always have the common structure first. And at least for
> > > cgroups supports that's what matters.
> > >
> > > Re the actual structures - we'll really need to make sure we
> > >
> > > a) expose proper userspace abi
On Sun, Sep 11, 2016 at 11:14:09AM -0600, Jason Gunthorpe wrote:
> > > We stil always have the common structure first. And at least for
> > > cgroups supports that's what matters.
> > >
> > > Re the actual structures - we'll really need to make sure we
> > >
> > > a) expose proper userspace abi
On Sun, Sep 11, 2016 at 05:35:22PM +0300, Leon Romanovsky wrote:
> > We stil always have the common structure first. And at least for
> > cgroups supports that's what matters.
> >
> > Re the actual structures - we'll really need to make sure we
> >
> > a) expose proper userspace abi headers in
On Sun, Sep 11, 2016 at 05:35:22PM +0300, Leon Romanovsky wrote:
> > We stil always have the common structure first. And at least for
> > cgroups supports that's what matters.
> >
> > Re the actual structures - we'll really need to make sure we
> >
> > a) expose proper userspace abi headers in
On Sun, Sep 11, 2016 at 03:34:21PM +0200, Christoph Hellwig wrote:
> On Sat, Sep 10, 2016 at 11:01:51AM -0600, Jason Gunthorpe wrote:
> > Sadly, it isn't a step backwards, it is status quo - at least as far
> > as the uapi is concerned.
>
> Sort of, see below:
>
> > struct mlx5_create_cq {
> >
On Sun, Sep 11, 2016 at 03:34:21PM +0200, Christoph Hellwig wrote:
> On Sat, Sep 10, 2016 at 11:01:51AM -0600, Jason Gunthorpe wrote:
> > Sadly, it isn't a step backwards, it is status quo - at least as far
> > as the uapi is concerned.
>
> Sort of, see below:
>
> > struct mlx5_create_cq {
> >
On Sat, Sep 10, 2016 at 11:01:51AM -0600, Jason Gunthorpe wrote:
> Sadly, it isn't a step backwards, it is status quo - at least as far
> as the uapi is concerned.
Sort of, see below:
> struct mlx5_create_cq {
> struct ibv_create_cqibv_cmd;
> __u64
On Sat, Sep 10, 2016 at 11:01:51AM -0600, Jason Gunthorpe wrote:
> Sadly, it isn't a step backwards, it is status quo - at least as far
> as the uapi is concerned.
Sort of, see below:
> struct mlx5_create_cq {
> struct ibv_create_cqibv_cmd;
> __u64
On 10/09/2016 20:01, Jason Gunthorpe wrote:
On Sat, Sep 10, 2016 at 06:14:42PM +0200, Christoph Hellwig wrote:
OFVWG meetings have absolutely zero relevance for Linux development.
Well, to be fair there are a fair number of kernel developers on that
particular call..
More "flexibility" for
On 10/09/2016 20:01, Jason Gunthorpe wrote:
On Sat, Sep 10, 2016 at 06:14:42PM +0200, Christoph Hellwig wrote:
OFVWG meetings have absolutely zero relevance for Linux development.
Well, to be fair there are a fair number of kernel developers on that
particular call..
More "flexibility" for
On 10/09/2016 19:12, Christoph Hellwig wrote:
On Wed, Sep 07, 2016 at 01:25:13PM +0530, Parav Pandit wrote:
a) delay cgroups support until the grand rewrite is done
b) add it now and deal with the consequences later
Can we do (b) now and differ adding any HW resources to cgroup until
they
On 10/09/2016 19:12, Christoph Hellwig wrote:
On Wed, Sep 07, 2016 at 01:25:13PM +0530, Parav Pandit wrote:
a) delay cgroups support until the grand rewrite is done
b) add it now and deal with the consequences later
Can we do (b) now and differ adding any HW resources to cgroup until
they
On Sat, Sep 10, 2016 at 06:14:42PM +0200, Christoph Hellwig wrote:
> OFVWG meetings have absolutely zero relevance for Linux development.
Well, to be fair there are a fair number of kernel developers on that
particular call..
> More "flexibility" for drivers just means giving up on designing a
>
On Sat, Sep 10, 2016 at 06:14:42PM +0200, Christoph Hellwig wrote:
> OFVWG meetings have absolutely zero relevance for Linux development.
Well, to be fair there are a fair number of kernel developers on that
particular call..
> More "flexibility" for drivers just means giving up on designing a
>
On Wed, Sep 07, 2016 at 11:51:42AM +0300, Matan Barak wrote:
> All recent proposals of the new ABI schema deals with extending the
> flexibility of the current schema by letting drivers define their specific
> types, actions, attributes, etc. Even more than that, the dispatching
> starts from
On Wed, Sep 07, 2016 at 11:51:42AM +0300, Matan Barak wrote:
> All recent proposals of the new ABI schema deals with extending the
> flexibility of the current schema by letting drivers define their specific
> types, actions, attributes, etc. Even more than that, the dispatching
> starts from
On Wed, Sep 07, 2016 at 01:25:13PM +0530, Parav Pandit wrote:
> > a) delay cgroups support until the grand rewrite is done
> > b) add it now and deal with the consequences later
> >
> Can we do (b) now and differ adding any HW resources to cgroup until
> they are clearly called out.
>
On Wed, Sep 07, 2016 at 01:25:13PM +0530, Parav Pandit wrote:
> > a) delay cgroups support until the grand rewrite is done
> > b) add it now and deal with the consequences later
> >
> Can we do (b) now and differ adding any HW resources to cgroup until
> they are clearly called out.
>
On Thu, Sep 8, 2016 at 11:42 AM, Leon Romanovsky wrote:
> On Wed, Sep 07, 2016 at 08:37:23PM +0530, Parav Pandit wrote:
>> Did you get a chance to review the series?
>
> We need to decide on fundamental question before reviewing it, which is
> "how to fit rdmacg to new ABI
On Thu, Sep 8, 2016 at 11:42 AM, Leon Romanovsky wrote:
> On Wed, Sep 07, 2016 at 08:37:23PM +0530, Parav Pandit wrote:
>> Did you get a chance to review the series?
>
> We need to decide on fundamental question before reviewing it, which is
> "how to fit rdmacg to new ABI model".
>From last
On Wed, Sep 07, 2016 at 08:37:23PM +0530, Parav Pandit wrote:
> Hi Leon,
>
> >> Signed-off-by: Parav Pandit
> >> +static struct rdmacg_resource_pool *
> >> +get_cg_rpool_locked(struct rdma_cgroup *cg, struct rdmacg_device *device)
> >> +{
> >> + struct
On Wed, Sep 07, 2016 at 08:37:23PM +0530, Parav Pandit wrote:
> Hi Leon,
>
> >> Signed-off-by: Parav Pandit
> >> +static struct rdmacg_resource_pool *
> >> +get_cg_rpool_locked(struct rdma_cgroup *cg, struct rdmacg_device *device)
> >> +{
> >> + struct rdmacg_resource_pool *rpool;
> >> +
> >>
On 07/09/2016 10:55, Parav Pandit wrote:
Hi Matan,
On Thu, Sep 1, 2016 at 2:14 PM, Christoph Hellwig wrote:
On Thu, Sep 01, 2016 at 10:25:40AM +0300, Matan Barak wrote:
Well, if I recall, the reason doing so last time was in order to allow
flexible updating of ib_core
On 07/09/2016 10:55, Parav Pandit wrote:
Hi Matan,
On Thu, Sep 1, 2016 at 2:14 PM, Christoph Hellwig wrote:
On Thu, Sep 01, 2016 at 10:25:40AM +0300, Matan Barak wrote:
Well, if I recall, the reason doing so last time was in order to allow
flexible updating of ib_core independently, which is
Hi Leon,
>> Signed-off-by: Parav Pandit
>> +static struct rdmacg_resource_pool *
>> +get_cg_rpool_locked(struct rdma_cgroup *cg, struct rdmacg_device *device)
>> +{
>> + struct rdmacg_resource_pool *rpool;
>> +
>> + rpool = find_cg_rpool_locked(cg, device);
>> +
Hi Leon,
>> Signed-off-by: Parav Pandit
>> +static struct rdmacg_resource_pool *
>> +get_cg_rpool_locked(struct rdma_cgroup *cg, struct rdmacg_device *device)
>> +{
>> + struct rdmacg_resource_pool *rpool;
>> +
>> + rpool = find_cg_rpool_locked(cg, device);
>> + if (rpool)
>> +
On Wed, Sep 7, 2016 at 2:21 PM, Matan Barak wrote:
> On 07/09/2016 10:55, Parav Pandit wrote:
>>
>> Hi Matan,
>>
>> On Thu, Sep 1, 2016 at 2:14 PM, Christoph Hellwig wrote:
>>>
>>> On Thu, Sep 01, 2016 at 10:25:40AM +0300, Matan Barak wrote:
Well, if I
On Wed, Sep 7, 2016 at 2:21 PM, Matan Barak wrote:
> On 07/09/2016 10:55, Parav Pandit wrote:
>>
>> Hi Matan,
>>
>> On Thu, Sep 1, 2016 at 2:14 PM, Christoph Hellwig wrote:
>>>
>>> On Thu, Sep 01, 2016 at 10:25:40AM +0300, Matan Barak wrote:
Well, if I recall, the reason doing so last
Hi Matan,
On Thu, Sep 1, 2016 at 2:14 PM, Christoph Hellwig wrote:
> On Thu, Sep 01, 2016 at 10:25:40AM +0300, Matan Barak wrote:
>> Well, if I recall, the reason doing so last time was in order to allow
>> flexible updating of ib_core independently, which is obviously not a good
>>
Hi Matan,
On Thu, Sep 1, 2016 at 2:14 PM, Christoph Hellwig wrote:
> On Thu, Sep 01, 2016 at 10:25:40AM +0300, Matan Barak wrote:
>> Well, if I recall, the reason doing so last time was in order to allow
>> flexible updating of ib_core independently, which is obviously not a good
>> reason (to
On 01/09/2016 00:16, Tejun Heo wrote:
Hello,
On Wed, Aug 31, 2016 at 06:07:30PM +0300, Matan Barak wrote:
Currently, there are some discussions regarding the RDMA ABI. The current
proposed approach (after a lot of discussions in the OFVWG) is to have
driver dependent object types rather than
On 01/09/2016 00:16, Tejun Heo wrote:
Hello,
On Wed, Aug 31, 2016 at 06:07:30PM +0300, Matan Barak wrote:
Currently, there are some discussions regarding the RDMA ABI. The current
proposed approach (after a lot of discussions in the OFVWG) is to have
driver dependent object types rather than
On Thu, Sep 01, 2016 at 10:25:40AM +0300, Matan Barak wrote:
> Well, if I recall, the reason doing so last time was in order to allow
> flexible updating of ib_core independently, which is obviously not a good
> reason (to say the least).
>
> Since the new ABI will probably define new object
On Thu, Sep 01, 2016 at 10:25:40AM +0300, Matan Barak wrote:
> Well, if I recall, the reason doing so last time was in order to allow
> flexible updating of ib_core independently, which is obviously not a good
> reason (to say the least).
>
> Since the new ABI will probably define new object
On 31/08/2016 11:37, Parav Pandit wrote:
Added rdma cgroup controller that does accounting, limit enforcement
on rdma/IB verbs and hw resources.
Added rdma cgroup header file which defines its APIs to perform
charing/uncharing functionality. It also defined APIs for RDMA/IB
stack for device
On 31/08/2016 11:37, Parav Pandit wrote:
Added rdma cgroup controller that does accounting, limit enforcement
on rdma/IB verbs and hw resources.
Added rdma cgroup header file which defines its APIs to perform
charing/uncharing functionality. It also defined APIs for RDMA/IB
stack for device
Hello,
On Wed, Aug 31, 2016 at 06:07:30PM +0300, Matan Barak wrote:
> Currently, there are some discussions regarding the RDMA ABI. The current
> proposed approach (after a lot of discussions in the OFVWG) is to have
> driver dependent object types rather than the fixed set of IB object types
>
Hello,
On Wed, Aug 31, 2016 at 06:07:30PM +0300, Matan Barak wrote:
> Currently, there are some discussions regarding the RDMA ABI. The current
> proposed approach (after a lot of discussions in the OFVWG) is to have
> driver dependent object types rather than the fixed set of IB object types
>
On Wed, Aug 31, 2016 at 02:07:25PM +0530, Parav Pandit wrote:
> Added rdma cgroup controller that does accounting, limit enforcement
> on rdma/IB verbs and hw resources.
>
> Added rdma cgroup header file which defines its APIs to perform
> charing/uncharing functionality. It also defined APIs for
On Wed, Aug 31, 2016 at 02:07:25PM +0530, Parav Pandit wrote:
> Added rdma cgroup controller that does accounting, limit enforcement
> on rdma/IB verbs and hw resources.
>
> Added rdma cgroup header file which defines its APIs to perform
> charing/uncharing functionality. It also defined APIs for
74 matches
Mail list logo