Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-linus
This will get my current pile for the 2.6.34 merge w
On Mon, Mar 1, 2010 at 9:12 PM, Vladislav Bolkhovitin wrote:
> [ ... ]
> It's good if my impression was wrong. But you've got suspiciously low IOPS
> numbers. On your hardware you should have much more. Seems you experienced a
> bottleneck on the initiator somewhere above the drivers level (fio? s
Hi David:
That looks like a bug to me and it looks like what you propose is the
correct fix. My only reservation is that if you are correct then how did
this work at all without data corruption for large writes on x86_64?
I'm on the road right now, so I can't dig too deep until Wednesday, but
Roland:
I'll put together a patch based on 5 with a comment that indicates why I
think 5 is the number. Since Vu has verified this behaviorally as well,
I'm comfortable that our understanding of the code is sound. I'm on the
road right now, so it won't be until tomorrow though.
Thanks,
Tom
When using connected mode, ipoib_cm_create_tx() kmallocs a
struct ipoib_cm_tx which contains pointers to ipoib_neigh and
ipoib_path. If the paths are flushed or the struct neighbour is
destroyed, the pointers held by struct ipoib_cm_tx can reference
freed memory.
Signed-off-by: Ralph Campbell
---
Tom
I have been chasing an rnfs related Oops in svc_process(). I have found
the source of the Oops but I am not sure of my fix. I am seeing the
problem on ppc64, kernel 2.6.32, I have not tried other arch yet.
The source of the problem is in rdma_read_complete(), I am finding that
rqstp->rq_res
> -Original Message-
> From: Tom Tucker [mailto:t...@opengridcomputing.com]
> Sent: Saturday, February 27, 2010 8:23 PM
> To: Vu Pham
> Cc: Roland Dreier; linux-rdma@vger.kernel.org; Mahesh Siddheshwar;
> e...@lists.openfabrics.org
> Subject: Re: [ewg] nfsrdma fails to write big file,
>
Bart Van Assche, on 02/27/2010 10:27 PM wrote:
On Mon, Jan 11, 2010 at 7:44 PM, Vladislav Bolkhovitin wrote:
[ ... ]
SRP initiator seems to be not too well optimized for the best performance. ISER
initiator is noticeably better in this area.
(replying to an e-mail of one month ago)
I'm not
> Still in-development, but it should be ready very soon. We will be the
> first in-kernel user of atomics, as well as masked atomics. This tree
> does not support masked atomics yet because it is based on ofed 1.5.1.
> When 1.5.2 is officially released, I'll rebase, add mask support, and
> plan on
Sasha Khapyorsky wrote:
> On 16:51 Wed 17 Feb , Doron Shohamd wrote:
>> add new command 'reload' in order to reload net topology file
>
> The same can be achieved by restarting ibsim. So what is the purpose of
> such "reload on the fly" functionality?
Restarting ibsim on the fly closes all cl
10 matches
Mail list logo
