[PATCH] ipoib: Fix lockup of the tx queue

The ipoib UD QP reports send completions to priv-send_cq which is unarmed generally; it only gets armed when the number of outstanding send requests (e.g. those for which a completion was not polled yet) reaches the size of the tx queue. This arming (done using ib_req_notify_cq()) is done only in

[PATCH] RDMA/cxgb3: wait at least one schedule cycle during device removal.

During a hot-plug LLD removal event or an EEH error event, iw_cxgb3 must ensure that any/all threads that might be in a cxgb3 exported function concurrently must return from the function before iw_cxgb3 returns from its event processing. Do this by calling synchronize_net(). Signed-off-by: Steve

[PATCH] infiniband-diags perfquery too noisy.

When perfquery is run against fabrics that do not support PortXmitWait, it emits this warning for every port: ibwarn: [23225] dump_perfcounters: PortXmitWait not indicated so ignore this counter When running ibcheckerrors on a large fabric, this leads to a flood of warnings. The proposed patch

Re: rnfs: rq_respages pointer is bad

On Mon, 2010-03-01 at 21:35 -0600, Tom Tucker wrote: 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? The size of

Setting QP attributes with RDMA CM

Hi, I'm using the RDMA CM to set up a QP and I'm trying to figure out if I can suggest QP attributes to it before it transitions through all the states. My QP is coming up with rnr_retry = 0, and I'd like to set it higher. Is there any way to do this besides going back through RTR - RTS?

Re: Setting QP attributes with RDMA CM

Todd Strader wrote: I'm using the RDMA CM to set up a QP and I'm trying to figure out if I can suggest QP attributes to it before it transitions through all the states see rdma_connect(3) Or. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to

Re: SRP initiator and iSER initiator performance

Bart Van Assche, on 03/02/2010 09:59 AM wrote: On Mon, Mar 1, 2010 at 9:12 PM, Vladislav Bolkhovitin v...@vlnb.net 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

Re: SRP initiator and iSER initiator performance

Bart Van Assche, on 03/01/2010 11:38 PM wrote: On Mon, Mar 1, 2010 at 9:12 PM, Vladislav Bolkhovitin v...@vlnb.net mailto:v...@vlnb.net 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.

Re: Bug in OFED1.5 ib_ipoib: IPv6 doesn't interoperate between RHEL4 and other Linux distros

Mike- A number of fixes related to ipv6 address resolution by rdma_cm went in to ofed 1.5.1 that may be related to this. You may want to test 1.5.1 and see if it resolves your issue. As I recall link-local address are treated different that assigned ipv6 address so you might want to try using

Re: [ewg] nfsrdma fails to write big file,

Hi Tom, Vu, Tom Tucker wrote: Roland Dreier wrote: + /* +* Add room for frmr register and invalidate WRs +* Requests sometimes have two chunks, each chunk +* requires to have different frmr. The safest +*

Re: IPoIB issues

I've applied the patch and initial testing has not produced any transmit timeout errors. I'll be doing some heavier testing in the next couple days, but it looks good so far. Thanks for the quick turn-around! -JE On Wed, Mar 3, 2010 at 4:29 AM, Eli Cohen e...@dev.mellanox.co.il wrote: I just

Re: SRP initiator and iSER initiator performance

On Wed, Mar 3, 2010 at 9:23 PM, Vladislav Bolkhovitin v...@vlnb.net wrote: Bart Van Assche, on 03/01/2010 11:38 PM wrote: On Mon, Mar 1, 2010 at 9:12 PM, Vladislav Bolkhovitin v...@vlnb.net mailto:v...@vlnb.net wrote:    [ ... ]    It's good if my impression was wrong. But you've got