On Fri, Sep 11, 2015 at 9:34 AM, Tejun Heo wrote:
> Hello, Parav.
>
> On Fri, Sep 11, 2015 at 09:09:58AM +0530, Parav Pandit wrote:
>> The fact is that user level application uses hardware resources.
>> Verbs layer is software abstraction for it. Drivers are hiding how
>> they implement this QP or
On 09/11/2015 12:04 AM, Tejun Heo wrote:
> Hello, Parav.
>
> On Fri, Sep 11, 2015 at 09:09:58AM +0530, Parav Pandit wrote:
>> The fact is that user level application uses hardware resources.
>> Verbs layer is software abstraction for it. Drivers are hiding how
>> they implement this QP or CQ or wh
Hello, Parav.
On Fri, Sep 11, 2015 at 09:09:58AM +0530, Parav Pandit wrote:
> The fact is that user level application uses hardware resources.
> Verbs layer is software abstraction for it. Drivers are hiding how
> they implement this QP or CQ or whatever hardware resource they
> project via API la
On Fri, Sep 11, 2015 at 1:52 AM, Tejun Heo wrote:
> Hello, Parav.
>
> On Thu, Sep 10, 2015 at 11:16:49PM +0530, Parav Pandit wrote:
>> >> These resources include are- QP (queue pair) to transfer data, CQ
>> >> (Completion queue) to indicate completion of data transfer operation,
>> >> MR (memory
During the recent rework of the mcast handling in ipoib, the join
task for regular and send-only joins were merged. In the old code,
the comments indicated that the ipoib driver didn't send enough
information to auto-create IB multicast groups when the join was a
send-only join. The reality is th
Hello, Parav.
On Thu, Sep 10, 2015 at 11:16:49PM +0530, Parav Pandit wrote:
> >> These resources include are- QP (queue pair) to transfer data, CQ
> >> (Completion queue) to indicate completion of data transfer operation,
> >> MR (memory region) to represent user application memory as source or
>
Sorry if you find that I am imposing, but there were not much inputs
on below thoughts in this email chain for abstraction, so iterating
again to see if there is different view now.
I understood the Christoph's requirement is relatively lean where
block-mq's MQ can be bound to CPU and/or to RDMA Q
> > In past there has been similar comment to have dedicated cgroup
> > controller for RDMA instead of merging with device cgroup.
> > I am ok with both the approach, however I prefer to utilize device
> > controller instead of spinning of new controller for new devices
> > category.
> > I anticipa
On Thu, Sep 10, 2015 at 10:19 PM, Tejun Heo wrote:
> Hello, Parav.
>
> On Wed, Sep 09, 2015 at 09:27:40AM +0530, Parav Pandit wrote:
>> This is one old white paper, but most of the reasoning still holds true on
>> RDMA.
>> http://h10032.www1.hp.com/ctg/Manual/c00257031.pdf
>
> Just read it. Much
On 09/10/2015 11:17 AM, Or Gerlitz wrote:
> On 9/5/2015 2:43 AM, Doug Ledford wrote:
>> On 09/03/2015 10:56 AM, Haggai Eran wrote:
>>> This series adds userspace support for on-demand paging. The first
>>> patch adds
>>> support for the new extended query device verb. Patch 2 adds the
>>> capabilit
Hello, Parav.
On Wed, Sep 09, 2015 at 09:27:40AM +0530, Parav Pandit wrote:
> This is one old white paper, but most of the reasoning still holds true on
> RDMA.
> http://h10032.www1.hp.com/ctg/Manual/c00257031.pdf
Just read it. Much appreciated.
...
> These resources include are- QP (queue pa
On 9/9/2015 7:11 PM, Doug Ledford wrote:
On 09/09/2015 12:10 PM, Linus Torvalds wrote:
On Wed, Sep 9, 2015 at 8:44 AM, Linus Torvalds
wrote:
Ok. I've merged it in my tree now, it's just waiting for the usual compile-test.
Compile-test finished, and pushed out.
Can somebody check that my
> 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 not getting a different ib_device if we
> want to a
On 9/5/2015 2:43 AM, Doug Ledford wrote:
On 09/03/2015 10:56 AM, Haggai Eran wrote:
This series adds userspace support for on-demand paging. The first patch adds
support for the new extended query device verb. Patch 2 adds the capability and
interface bits related to on-demand paging, and patch
On 9/10/2015 4:29 PM, Christoph Hellwig wrote:
On Thu, Sep 10, 2015 at 12:50:33PM +0300, Sagi Grimberg wrote:
What I'm more interested in is a way to tell the CM that I only
want routes that are using this ib_device that I got from the first
lookup as all others are useless for me.
I'm not su
On Thu, Sep 10, 2015 at 12:50:33PM +0300, Sagi Grimberg wrote:
> >What I'm more interested in is a way to tell the CM that I only
> >want routes that are using this ib_device that I got from the first
> >lookup as all others are useless for me.
> >
>
> I'm not sure I understand what you are aiming
From: Vladimir Koushnir
Date: Wed, 9 Sep 2015 14:29:38 +0300
-D and -list saquery options are operational only
when -N option is explicitly invoked (default option)
This patch allows using -D or --list options when no other option is
invoked.
Signed-off-by: Vladimir Koushnir
Signed-off-by: Hal
What I'm more interested in is a way to tell the CM that I only
want routes that are using this ib_device that I got from the first
lookup as all others are useless for me.
I'm not sure I understand what you are aiming for? if you connect to
a single address multiple times you will get the same
On 9/9/2015 6:20 PM, Doug Ledford wrote:
On 09/05/2015 03:59 PM, Or Gerlitz wrote:
--> they must not put any
additional bits on the wire
Maybe. For base level interop, sure, but for enhanced service in a homogeneous
environment, not necessarily true.
--> RC isn't an option
Not following he
19 matches
Mail list logo