On Sun, 2005-02-13 at 23:45 -0800, Bill Thompson wrote:
Hope everyone had a nice time in Sonoma. Sorry I missed it...
Got a question:
Can someone take a SWAG at when an OpenIB stack (OpenSM, OpenMPI,
uDAPL, iSCSI, iSER, IPoIB, SDP, kDAPL) will be in RHE 4?
Now that could be CVS or
Hi,
From: Tom Duffy [EMAIL PROTECTED]
Subject: Re: FW: [openib-general] Minutes from DAPL BOF at OpenIB Workshop
Date: Thu, 10 Feb 2005 10:51:25 -0800
On Thu, 2005-02-10 at 18:46 +0100, Christoph Hellwig wrote:
Maybe you should lay down the requirement first.
I'll take a crack at it. Let
Hi,
From: Christoph Hellwig [EMAIL PROTECTED]
Subject: Re: FW: [openib-general] Minutes from DAPL BOF at OpenIB Workshop
Date: Sun, 13 Feb 2005 15:29:06 +0100
On Sun, Feb 13, 2005 at 03:25:24PM +0100, Christoph Hellwig wrote:
On Sun, Feb 13, 2005 at 10:37:12AM +0200, Dan Bar Dov wrote:
I
Hi Eitan,
With OpenSM, in general, is there an approach that is being used to
ensure the reserved fields at set to 0 on send ? I couldn't ascertain
this from the code and I do observe reserved fields set to non 0 on
send. One approach would be to clear the MAD when it is first obtained.
Another
Title: RE: OpenIB OpenSM and Reserved Fields on Transmit
The lowest level to catch all MAD buffer allocations is in the osm_vendor_get() call.
It could certainly zero out the mad buffer it provides.
Eitan Zahavi
Design Technology Director
Mellanox Technologies LTD
Tel:+972-4-9097208
On Mon, 2005-02-14 at 08:33, Eitan Zahavi wrote:
The lowest level to catch all MAD buffer allocations is in the
osm_vendor_get() call.
It could certainly zero out the mad buffer it provides.
Sounds like this is not being done currently. That's what I wanted to
confirm. Thanks.
-- Hal
Title: RE: [openib-general] Re: FW: summary of my understanding on our common work on openib.org
1. This attribute is not used also by gen1 code and we checked with customers.
2. It is not useful since on RQ there any logical flow will work with completions.
Tziporet
-Original
On Fri, 2005-02-11 at 21:58 -0800, Grant Grundler wrote:
And sdp_main.h violates one of the kernel include file rules:
include asm/ headers *after* linux/ headers.
Include asm/ headers *after* linux/ headers. This builds for me on x86,
x86_64, and sparc64.
Signed-off-by: Tom Duffy
Matt wrote Several developers have volunteered to work on uDAPL. The
DAT
collaborative is working to get a GPL/BSD version of uDAPL to OpenIB.
James and Arkady from NetApp gave a DAT talk. They mentioned needing 1
month to get the GPL code, and another month or two to fork the code
base. I'm
Grant The following patch makes _sdp_iocb_page_save() look like
Grant the code in mm/rmap.c. I have no clue if it's right or not.
Grant But it now builds on ia64. Not tested yet.
4-level page tables went in after 2.6.10, right? So I think we should
hang onto this patch and apply it
Roland Dreier wrote:
A few comments about documentation:
There seem to be two distinct requests in this thread. First, there
is a desire for a basic verbs example that can be used to get
started. I am writing code like this as I develop the userspace verbs
library, since I need basic tests to
Mike This would be really helpful to many people. I would also
Mike suggest that as the userspace verbs is written by you and
Mike others, to document and make available your testing code.
Mike This will get users a foothold.
Yes, as I said the example code will be part of the
Libor Do you know which architecture was the impetus for a 4th
Libor page table level?
x86-64 I believe. x86-64 actually always uses 4 levels in HW but
Linux had to make one of them trivial, which limited a single memory
map to 512 GB. Apparently some workloads that mmap'ed a lot of
On Fri, Feb 11, 2005 at 09:58:27PM -0800, Grant Grundler wrote:
On Fri, Feb 11, 2005 at 06:40:58PM -0800, Libor Michalek wrote:
If no one objects, a patch to clean up compile warnings on x86_64.
I haven't applied this patch yet - I read mail on the other side of
a firewall where my
On Mon, Feb 14, 2005 at 08:23:44AM -0800, Tom Duffy wrote:
On Fri, 2005-02-11 at 21:58 -0800, Grant Grundler wrote:
And sdp_main.h violates one of the kernel include file rules:
include asm/ headers *after* linux/ headers.
Include asm/ headers *after* linux/ headers. This builds for
formerly working opensm starts to get these:
[1108414727:000284173][411FF970] - umad_receiver: send completed with
error(method=1 attr=11) -- dropping.
[1108414727:000384171][411FF970] - umad_receiver: send completed with
error(method=1 attr=11) -- dropping.
[1108414727:000484169][411FF970] -
On Mon, Feb 14, 2005 at 12:36:38PM -0800, Grant Grundler wrote:
On Mon, Feb 14, 2005 at 11:29:44AM -0800, Libor Michalek wrote:
Good idea, in three places I got rid of the cast, and then used an inline
in two other places. Here's the updated patch.
cool - thanks. Can these two also be
On Fri, 2005-02-11 at 19:47 -0800, Tom Duffy wrote:
On Fri, 2005-02-11 at 18:40 -0800, Libor Michalek wrote:
If no one objects, a patch to clean up compile warnings on x86_64. Most
of the warnings are a result of print format mismatches, the most common
being the need to use %Zu for
Roland,
Please review this patch.
This patch has fixed a deadlock problem:
the caller calls ipoib_put_ah() while holding priv-lock. (In ipoib_free_ah()
the same lock is reacquired.) This also fixes the ipoib_flush_paths() calls
__patch_free() without holding priv-lock.
My email has problem to
Hi Arkady,
As I mentioned in the BOF, I have a person (Arlin Davis) that can help
with
developing a uDAPL provider for the openib.org verbs.
After discussing it more
with folks here, is seems to us that perhaps for the uDAPL user-mode
library, it be provided to openib.org under a dual BSD +
Shirley This patch has fixed a deadlock problem: the caller calls
Shirley ipoib_put_ah() while holding priv-lock. (In
Shirley ipoib_free_ah() the same lock is reacquired.) This also
Shirley fixes the ipoib_flush_paths() calls __patch_free()
Shirley without holding priv-lock.
21 matches
Mail list logo
