Re: [PATCH] libibverbs: Force line-buffering in ibv_asyncwatch

On Jun 2, 2010, at 19:05 , Roland Dreier wrote: >> setlinebuf() is pretty intuitive to understand, compared to setvbuf(). > > I finally applied this; however in the end I decided to do > > setvbuf(stdout, NULL, _IOLBF, 0); > > instead of setlinebuf(), since in the past I've prefered more

Re: [PATCH V4 1/2] IB/core: Add support for enhanced atomic operations

On Apr 14, 2010, at 16:23 , Vladimir Sokolovsky wrote: > The additional operands are carried in the Extended Transport Header Is this a newly defined ETH which follows the AETH on the wire? Thanks, Håkon -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a

Re: [PATCH] ummunotify: Userspace support for MMU notifications

On Apr 13, 2010, at 20:02 , Peter Zijlstra wrote: > > Yeah, virtual<->physical maps can change through swapping, page > migration, memory compaction, huge-page aggregation (the latter two not > yet being upstream). Assuming this holds true, RDMA will not work. And with no RDMA, we do not need

Re: [PATCH] ummunotify: Userspace support for MMU notifications

On Apr 13, 2010, at 1:59 , Jason Gunthorpe wrote: > On Mon, Apr 12, 2010 at 04:03:59PM -0700, Andrew Morton wrote: > >>> As discussed in >>> and follow-up messages, libraries using RDMA would like to track >>> precisely when application

Re: [PATCH V3 0/2] Add support for enhanced atomic operations

On Mar 11, 2010, at 19:59 , Roland Dreier wrote: > I think we can worry about that if/when an HCA comes along that supports > global atomics for ordinary atomics but not enhanced atomics. With the proposed patches in place, how do you know if masked atomics are implemented or not? Guess apps need

Re: [PATCH V3 0/2] Add support for enhanced atomic operations

"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 Håkon Bugge haakon.bu...@sun.com +47 924 84 514 -- 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

Re: [PATCH V2 1/2] IB/core: Add support for enhanced atomic operations

> 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

Re: [PATCH 0/2] Add support for enhanced atomic operations

On Feb 2, 2010, at 16:54 , Hal Rosenstock wrote: > On Tue, Feb 2, 2010 at 5:44 AM, Vladimir Sokolovsky >> [snip] >> Masked Fetch and Add (MFetchAdd) >> The MFetchAdd Atomic operation extends the functionality of the standard IB >> FetchAdd by >> allowing the user to split the target into multiple

Re: data placement in-order guarantee ?

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 Håkon Bugge haakon.bu...@sun.com +47 924 84 514 -- To unsubscribe from this list: send the line "unsubscribe linux-

Re: ib_write_bw hanging when using max max_inline value

On Jan 24, 2010, at 6:26 , Or Gerlitz wrote: > attaching a debugger is typically helpful to see where a program talking > directly to the hardware hangs. If it happens on the slow pass, strace can be > useful as well. Did you take a look on the actual values set for this qp, > that it as sugge

ib_write_bw hanging when using max max_inline value

Hi, I modified ib_write_bw to support inline sizes beyond the default value of 400 (not sure why the program does not allow larger values though). When using the largest max_inline value supported by ConnectX (i.e. the creation of QP goes OK), the test program hangs when exchanging 920 bytes.

Re: [PATCH] libibverbs: Force line-buffering in ibv_asyncwatch

, compared to setvbuf(). -h On Jan 21, 2010, at 15:18 , Bart Van Assche wrote: > On Thu, Jan 21, 2010 at 2:40 PM, Håkon Bugge wrote: >> ibv_asyncwatch defaults to block-buffering when stdout is redirected to a >> file or pipe. This fix makes it more usable in scripted environments. &g

[PATCH] libibverbs: Force line-buffering in ibv_asyncwatch

ibv_asyncwatch defaults to block-buffering when stdout is redirected to a file or pipe. This fix makes it more usable in scripted environments. Signed-off-by: Hakon Bugge --- diff --git a/examples/asyncwatch.c b/examples/asyncwatch.c index e56b4dc..f9fe6ff 100644 --- a/examples/asyncwatch.c +++

ibv_asyncwatch and buffering

Hi, It seems like ibv_asyncwatch defaults to standard libc behavior wrt. to buffering. That is, if you pipe the output of ibv_asyncwatch, no output happens, as the stdout is redirected to a pipe and block buffering is used by default. One could a) use sprintf() and write() or b) force libc bu

RDMA Read sge errors

cases, but completion gives local length error. I am running on CentOS 5.3, Intel E5540, OFED 1.4.1, and ConnectX w/fw 2.6.000. Thanks, Håkon -- Håkon Bugge haakon.bu...@sun.com +47 924 84 514 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a