On Fri, Sep 23, 2011 at 02:15:30PM -0700, Wendy Cheng wrote:
> I have my own counters that restrict the read (and write) to 512 max.
> Both write and read are blocking (i.e. cq is polled after each
> read/write). I suspect I do not have the cq poll logic correct. The
> question here is .. is there
I have a test program that does RDMA read-write as the following:
node A: server listens and handles connection requests
setup a piece of memory initialized to "0"
node B: two processes parent & child
child:
1. setup a new channel with server, including a CQ with 1024 entries
The following patch series contains optimizations that benefit
qib verbs performance.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Store both the encoded and decoded mtu in the qp structure as a minor
optimization UC/RC receive routines.
Signed-off-by: Mike Marciniszyn
---
drivers/infiniband/hw/qib/qib_qp.c|4 +++-
drivers/infiniband/hw/qib/qib_rc.c|6 +++---
drivers/infiniband/hw/qib/qib_uc.c|4 ++--
The context init now saves a shift from rcvegrbufs_perchunk
rcvegrbufs_perchunk_shift using ilog2. A BUG_ON protects the
power of 2 assumption.
Signed-off-by: Mike Marciniszyn
---
drivers/infiniband/hw/qib/qib.h |8 ++--
drivers/infiniband/hw/qib/qib_driver.c |6 +++---
dr
Call irq_set_affinity_hint to provide user mode programs
like irqbalance the information to be able to distribute
qib interrupts appropriately.
The logic allocates all non-receive interrupts to the first
CPU local to the HCA. Receive interrupts are allocated round
robin starting with the second C
The default memcpy used by qib_copy_sge() ends up being a rep movsb on x86_64,
which is pretty slow.
This fix adds an x86_64 specific routine that 1) probes for X86_FEATURE_REP_GOOD
and 2) uses an inline asm routine builton rep movsq that testing has shown is
better than the builtin memcpy for all
Observation in qib_ruc_check_hdr() shows that the s_lock is not required
in the normal case. The r_lock is held in all cases, and protects
the qp fields that are read.
The s_lock will be needed to around the call to qib_migrate_qp() to
insure that the send engine sees a consistent set of fields.
The memset for zeroing the work completion had been unconditional.
This patch removes the memset and moves the zeroing into the work
completion with a more explicit field by field set. With this patch,
non-ONLY/non-LAST packets will avoid the overhead since they will
not generate a completion.
The heavy weight spinlock in qib_lookup_qpn() is replaced with
the RCU locking mechanism. The hash list itself is now accessed
via jhash functions vs. the mod.
The changes should benefit multiple receive contexts in different
processors by not contending for the lock to just read the hash
structu
A new field is added to qib_qp called timeout_jiffies. It
is initialized upon create and modify.
The field is now used vs. the computation based on qp->timeout.
Signed-off-by: Mike Marciniszyn
---
drivers/infiniband/hw/qib/qib_qp.c|9 -
drivers/infiniband/hw/qib/qib_rc.c|
On Fri, Sep 23, 2011 at 02:01:50PM -0400, Hal Rosenstock wrote:
> On 9/23/2011 1:55 PM, Jason Gunthorpe wrote:
> > On Fri, Sep 23, 2011 at 01:31:20PM -0400, Hal Rosenstock wrote:
> >
> >>> The only wonky bit
> >>> was that verbs was needed for subnet timeout because it isn't in
> >>> sysfs. Everyt
On Thu, Sep 22, 2011 at 6:48 PM, Yong Zhang wrote:
> So like I said above, you could take it if you want to.
Great, I queued this up for 3.2, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info
On 9/23/2011 1:55 PM, Jason Gunthorpe wrote:
> On Fri, Sep 23, 2011 at 01:31:20PM -0400, Hal Rosenstock wrote:
>
>>> The only wonky bit
>>> was that verbs was needed for subnet timeout because it isn't in
>>> sysfs. Everything else went according to the spec.
>>
>> I don't see how your algorithm c
On Fri, Sep 23, 2011 at 01:31:20PM -0400, Hal Rosenstock wrote:
> > The only wonky bit
> > was that verbs was needed for subnet timeout because it isn't in
> > sysfs. Everything else went according to the spec.
>
> I don't see how your algorithm can be compliant with just subnet timeout.
Really?
On 9/23/2011 12:57 PM, Jason Gunthorpe wrote:
> On Fri, Sep 23, 2011 at 08:57:12AM -0400, Hal Rosenstock wrote:
>
>>> Technically umad already needs to use verbs on Linux because that is
>>> the only way to get the subnet timeout value that is needed to compute
>>> the MAD RPC timeout. Currently u
> 1. Remove ibstat and use ibv_devinfo instead
> 2. Change ibstat to obtain the fdr10 information using ibverbs
> 3. Move the is_fdr10 functionality into OS specific files or code
> sections of ibstat
> 4. Change ibstat to obtain fdr10 data using MADs or some other OS
> inde
On Fri, Sep 23, 2011 at 08:57:12AM -0400, Hal Rosenstock wrote:
> > Technically umad already needs to use verbs on Linux because that is
> > the only way to get the subnet timeout value that is needed to compute
> > the MAD RPC timeout. Currently umad ignores this part of IBA ...
>
> Determining
So far, it seems that the choices are:
1. Remove ibstat and use ibv_devinfo instead
2. Change ibstat to obtain the fdr10 information using ibverbs
3. Move the is_fdr10 functionality into OS specific files or code sections of
ibstat
4. Change ibstat to obtain fdr10 data using MADs or some other OS
> > The only way to determine whether fdr10 is active or not is via the
> > vendor proprietary MAD. That info may be reflected in some other API
> > (and/or file) so that MAD does not need to be reissued. In a separate
> > thread on linux-rdma, there was discussion on a couple of different
> > ways
> Even if ibv_devinfo is updated to include the additional information,
> do we want to require libibverbs, etc. on any IB management machine
> just for this ? That's not the case today on IB management nodes.
IMO, it's acceptable for ibverbs to be the basic requirement for any IB
userspace appli
On Fri, Sep 23, 2011 at 9:28 AM, Hal Rosenstock
wrote:
> On Wed, Sep 21, 2011 at 3:06 PM, Hefty, Sean wrote:
>> commit 1344cb3feacafc462440dabfa5997c5205486d83 added support for FDR10 in a
>> way that is not compatible with Windows support. Windows does not use files
>> to read attribute infor
On Wed, Sep 21, 2011 at 3:06 PM, Hefty, Sean wrote:
> commit 1344cb3feacafc462440dabfa5997c5205486d83 added support for FDR10 in a
> way that is not compatible with Windows support. Windows does not use files
> to read attribute information.
>
> I will probably need to obtain the necessary info
On Wed, Sep 21, 2011 at 8:14 PM, Ira Weiny wrote:
> On Wed, 21 Sep 2011 15:32:54 -0700
> Ira Weiny wrote:
>
>> On Wed, 21 Sep 2011 15:23:45 -0700
>> "Hefty, Sean" wrote:
>>
>> > > Does this mean "ibstatus" does not work on Windows?
>> >
>> > We do not support any of the scripts on windows. As f
On Wed, Sep 21, 2011 at 6:35 PM, Jason Gunthorpe
wrote:
> On Wed, Sep 21, 2011 at 03:32:54PM -0700, Ira Weiny wrote:
>
>> To be clear I am not against using ibverbs on the linux side. It
>> sounds like that would be the best move going forward.
>
> Technically umad already needs to use verbs on L
Hi Al,
On Wed, Sep 21, 2011 at 2:25 PM, Albert Chu wrote:
> Hey Hal,
>
> Ira answered most of the important stuff already. But some extra
> details ...
>
>> Second the current alignment breaks libibmad. So it would be a lot
>> more code to support the miss-alignment and would probably have to b
26 matches
Mail list logo
