On Sat, 2012-05-19 at 10:50 +, Bart Van Assche wrote:
> On 04/30/12 15:11, David Dillow wrote:
>
> > On Sun, 2012-04-22 at 16:01 +, Bart Van Assche wrote:
> >> On 03/29/12 16:59, Dave Dillow wrote:
> >>> I haven't chewed on the rest yet, but would like to see this one at
> >>> least in 3.4
On Wed, 2012-05-30 at 01:22 -0400, David Dillow wrote:
> On Mon, 2012-05-21 at 17:49 +0200, Bernd Schubert wrote:
> > David, below is a first version to convert SRP_RQ_SHIFT into a new
> > module option "srp_rq_size". I already tested it, but I also need to
> > re-read it myself.
> >
> > Author:
On Mon, 2012-05-21 at 17:49 +0200, Bernd Schubert wrote:
> David, below is a first version to convert SRP_RQ_SHIFT into a new
> module option "srp_rq_size". I already tested it, but I also need to
> re-read it myself.
>
> Author: Bernd Schubert
> Date: Mon May 21 10:25:01 2012 +0200
>
>
On Tue, 2012-05-29 at 17:07 -0400, Karandeep Chahal wrote:
> Subject: [PATCH] Infiniband srp fast failover patch.
This conflicts with Bart's patches to improve failover; it will be much
better to use his approach to block the target rather than remove it
wholesale -- we could have lost connectivit
> Did you try out the patches? was it helpful to address the problem
> you're facing?
I have not had time to test it yet
--
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/maj
Thank you for clarifying!
On 05/29/2012 03:27 PM, Karandeep Chahal wrote:
Hi Michael,
Yes, I tried reconnecting the targets and removing reinserting ib-srp.
Thanks
Karan
On 05/29/2012 05:51 PM, Michael Reed wrote:
Did you subsequently reconnect the target and confirm appropriate behavior?
Hi Michael,
Yes, I tried reconnecting the targets and removing reinserting ib-srp.
Thanks
Karan
On 05/29/2012 05:51 PM, Michael Reed wrote:
Did you subsequently reconnect the target and confirm appropriate behavior?
On 05/29/2012 02:07 PM, Karandeep Chahal wrote:
Subject: [PATCH] Infiniban
Did you subsequently reconnect the target and confirm appropriate behavior?
On 05/29/2012 02:07 PM, Karandeep Chahal wrote:
Subject: [PATCH] Infiniband srp fast failover patch. Currently ib_srp does
not do anything on receiving a DREQ from the target, it
only sends a response back. Furthe
Subject: [PATCH] Infiniband srp fast failover patch. Currently ib_srp does
not do anything on receiving a DREQ from the target, it
only sends a response back. Further it also does not
monitor port (down) events. I have patched srp to remove
scsi devices when a port down event is received or if
thanks! applied
--
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
> Updated user-kernel abi interface.
Thanks, applied, since this driver hasn't even been in an rc release yet.
But from now on you really need to treat your user-kernel ABI as frozen,
or at least bump your abi version when it changes. But breaking ABI
is really a pain for users, so please avoid
On Tue, May 29, 2012 at 8:45 PM, Roland Dreier wrote:
> In general I'm kind of sad about the way the hardware works: having
> to choose the incompatible 64-byte CQE format globally at startup
> means we're kind of stuck breaking userspace in some cases.
yes, indeed, that's the way CX3 works.
>
Hi,
When we try to establish a connection with NFS RDMA server, we get the
following messages with debug enabled -
[ 2937.577657] RPC: rpcrdma_conn_upcall: established:
192.168.1.13:20049 (ep 0x88012f980628 event 0x9)
[ 2937.597566] RPC: rpcrdma_conn_upcall: connected
[ 2937.
Hi List,
I am running some test cases to assess operation concurrency with Infiniband,
meaning how many actual outstanding operations my HCA (ConnectX-3 QDR) can
handle.
In my test case to evaluate fetch-and-add, I spawn multiple threads, each
owning its own QP inside the same PD and context a
On Tue, May 29, 2012 at 10:57 AM, Jason Gunthorpe
wrote:
>> Then around 3.8 or so we can have the kernel default to 64-byte CQEs
>> for HW that supports it.
>
> Can things also be tweaked so the old libmlx4 won't load at all on
> these kernels? Bump one of the abi_ver values or something?
The pat
On Tue, May 29, 2012 at 10:45:33AM -0700, Roland Dreier wrote:
> Then around 3.8 or so we can have the kernel default to 64-byte CQEs
> for HW that supports it.
Can things also be tweaked so the old libmlx4 won't load at all on
these kernels? Bump one of the abi_ver values or something?
Jason
--
On Tue, May 29, 2012 at 7:41 AM, Or Gerlitz wrote:
> Jack is now fixing that with the SRIOV IB patches he's working on,
> so please hold off with accepting this patch. I would still love to get
> feedback on
> the design re user space, etc compatibility and the patch in general.
OK, I'll hold off
On 5/24/2012 5:30 PM, Or Gerlitz wrote:
The patch makes sure that older guest drivers who follows the
QUERY_DEV_FUNC command (e.g as done in mlx4_core of Linux 3.3/3.4)
will notice that they need an update to be able to work with the
PPF since the returned pf_context_behaviour will not be zero an
On 04/13/2012 09:47 PM, Hefty, Sean wrote:
ibacm release 1.0.6 is now available from:
https://www.openfabrics.org/downloads/rdmacm/ibacm-1.0.6.tar.gz
Hi Sean,
I tried to run rpmbuild with ibacm-1.0.6 from
https://www.openfabrics.org/downloads/rdmacm/ofed/ibacm-1.0.6.tar.gz and it
fails on RH
when ran with make versioncheck the ocrdma_verbs.h ocrdma_main.c includes
version.h which are not needed.
drivers/infiniband/hw/ocrdma/ocrdma_main.c: 29 linux/version.h not needed.
drivers/infiniband/hw/ocrdma/ocrdma_verbs.h: 31 linux/version.h not needed.
Signed-off-by: Devendra Naga
---
drive
20 matches
Mail list logo
