Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: ANNOUNCE: First usable version of userspace verbs
>
> mst> but I also changed the clock sampling to use the realtime
> mst> clock from -lrt, since it gives a more consistent timing
> mst> results on my system.
>
> By the way
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: ANNOUNCE: First usable version of userspace verbs
>
> mst> but I also changed the clock sampling to use the realtime
> mst> clock from -lrt, since it gives a more consistent timing
> mst> results on my system.
>
> By the way
On Mon, Feb 28, 2005 at 11:55:54PM +0200, Yaron Haviv wrote:
> From: Libor Michalek
> >
> > SDP does implement a subset of the proposed functionality for
> > resolving IP addresses to PathRecords which can then be used in
> > a CM REQ request, plus some basic caching. All the code is isolated
>
On Wed, Mar 02, 2005 at 01:38:50AM +0200, Yaron Haviv wrote:
> Even if your approach to DAPL was right you still have address
> translation service in SDP, and would need one for NFS/RDMA, and another
> one to iSER and another one for Lustre, etc' (even if they are coded
> directly to the verbs) No
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:openib-general-
> [EMAIL PROTECTED] On Behalf Of Christoph Hellwig
> Sent: Wednesday, March 02, 2005 12:06 AM
> To: openib-general@openib.org
> Subject: [openib-general] putting in dead wood for DAPL and
> similarabomination
>
> Please
mst> but I also changed the clock sampling to use the realtime
mst> clock from -lrt, since it gives a more consistent timing
mst> results on my system.
By the way, what exactly are you using? clock_gettime() with
CLOCK_REALTIME? Do you know what the difference from gettimeofday is?
Thanks, applied.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Christoph> Please don't put in things like the address translation
Christoph> service or memory windows for DAPL folks. The IB code
Christoph> in the kernel already has far too much unused stuff and
Christoph> adding more will not go past reviews for kernel
Christoph> inclusion
Michael> I have implemented a small test for the rdma
Michael> functionality. I based it on the pingpong test, the main
Michael> change being polling on data instead of completions (but
Michael> I also changed the clock sampling to use the realtime
Michael> clock from -lrt, sin
[ putting back on list ]
On Wed, 2005-03-02 at 00:29 +0200, Yaron Haviv wrote:
> Did you try RARP with IPoIB ?
I have not.
> I thought that there is some issue that it doesn't work
Currently, the rarpd only works with ethernet, but I don't see why this
couldn't be fixed.
> Also I hope you can
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: ANNOUNCE: First usable version of userspace verbs
>
> I'm happy to announce the initial availability of userspace verbs
> support for brave testers.
>
> To try this out, check out the roland-uverbs subversion branch:
>
> svn co https:/
On Tue, 2005-03-01 at 08:07 +0200, Yaron Haviv wrote:
> The one thing that ATS provide and is not possible with ARP is reverse
> resolution GID->IP, any ideas how to achieve that without ATS ?
RARP.
-tduffy
signature.asc
Description: This is a digitally signed message part
_
Please don't put in things like the address translation service or
memory windows for DAPL folks. The IB code in the kernel already
has far too much unused stuff and adding more will not go past reviews
for kernel inclusions - as will DAPL itself exactly because of such
utter stupidities. Similar
NFS/RDMA doesn't require memory windows but it will make use of
them if they are available.
-james
On Tue, 1 Mar 2005, Roland Dreier wrote:
James> I ask because the DAT API contains interfaces that allow
James> users to interact with memory windows.
Are there any real applications that use
Roland Dreier wrote:
Sean> Getting from receiving the first segment of an RMPP MAD to
Sean> this value is non-trivial, and doing so before the sender
Sean> times out is even more difficult. Is there spec compliant
Sean> implementation of this in existence? If so, I'd be
Sean>
Sean> Getting from receiving the first segment of an RMPP MAD to
Sean> this value is non-trivial, and doing so before the sender
Sean> times out is even more difficult. Is there spec compliant
Sean> implementation of this in existence? If so, I'd be
Sean> interested in seeing
Roland Dreier wrote:
Sean> * For the total transaction timeout, the equation given to
Sean> calculate the value would probably require 1000+ lines of
Sean> code, and the default value given is 40 seconds, which seems
Sean> long. Any opinions on what approach to take here? I can
Sean> * For the total transaction timeout, the equation given to
Sean> calculate the value would probably require 1000+ lines of
Sean> code, and the default value given is 40 seconds, which seems
Sean> long. Any opinions on what approach to take here? I can
Sean> either go wit
Hal Rosenstock wrote:
Hi Sean,
On Tue, 2005-03-01 at 13:34, Sean Hefty wrote:
Also, does anyone know of any existing RMPP implementations outside of
the SourceForge IB stack?
Voltaire has one in its gen1 stack.
(Resending to list)
Can you send me a link to the directory?
- Sean
__
Hi Sean,
On Tue, 2005-03-01 at 13:34, Sean Hefty wrote:
> Also, does anyone know of any existing RMPP implementations outside of
> the SourceForge IB stack?
Voltaire has one in its gen1 stack.
-- Hal
___
openib-general mailing list
openib-general@ope
Sean Hefty wrote:
I'm studying the RMPP implementation requirements for reassembly, and
there are a couple of issues/questions.
Also, does anyone know of any existing RMPP implementations outside of
the SourceForge IB stack?
- Sean
___
openib-general m
I'm studying the RMPP implementation requirements for reassembly, and
there are a couple of issues/questions.
* What is an appropriate window size for the receiver to use? My
initial thought was to use 1/8th of the receive queue size, but this
would be easy to change.
* For the total transact
This gets rid of the new sparse warnings like:
/build1/tduffy/openib-work/linux-2.6.10-openib/drivers/infiniband/core/mad.c:50:14:
warning: symbol 'ib_mad_cache' was not declared. Should it be static?
Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>
Index: drivers/infiniband/core/agent.c
==
On Tue, 2005-03-01 at 09:58 -0800, Libor Michalek wrote:
> That's odd. It doesn't make much sense to have a seperate header file
> for a single structure which is used in the same place as sdp_buff.h and
> four constants. Here's a patch to get rid of the file.
That's one way to get rid of the tu
On Tue, Mar 01, 2005 at 09:46:26AM -0800, Tom Duffy wrote:
> On Tue, 2005-03-01 at 09:43 -0800, [EMAIL PROTECTED] wrote:
> > Modified: gen2/trunk/src/linux-kernel/infiniband/ulp/sdp/sdp_buff_p.h
> > ===
> > --- gen2/trunk/src/linux-ker
lnx_stream_ops should be static. Also, fix one more static name in
sdp_proc.c
Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>
Index: drivers/infiniband/ulp/sdp/sdp_inet.c
===
--- drivers/infiniband/ulp/sdp/sdp_inet.c (revision 19
On Tue, 2005-03-01 at 09:43 -0800, [EMAIL PROTECTED] wrote:
> Modified: gen2/trunk/src/linux-kernel/infiniband/ulp/sdp/sdp_buff_p.h
> ===
> --- gen2/trunk/src/linux-kernel/infiniband/ulp/sdp/sdp_buff_p.h
> 2005-02-28 23:43:10 UT
Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>
Index: drivers/infiniband/ulp/ipoib/ipoib_ib.c
===
--- drivers/infiniband/ulp/ipoib/ipoib_ib.c (revision 1927)
+++ drivers/infiniband/ulp/ipoib/ipoib_ib.c (working copy)
@@ -40,7 +4
At 11:17 PM 2/28/2005, Eric W. Biederman wrote:
"Yaron Haviv"
<[EMAIL PROTECTED]> writes:
> > -Original Message-
> > From: [EMAIL PROTECTED]
[
mailto:openib-general-
> > [EMAIL PROTECTED] On Behalf Of Roland Dreier
> > Sent: Monday, February 28, 2005 7:13 PM
> > To: shaharf
> > Cc: openib
Libor Michalek wrote:
Is it ever allowed to call ib_destroy_cm_id() from a CM callback?
For some reason I thought that this was OK from only the IDLE callback,
but if I destroy from IDLE I get a hang on cm_id_priv->lock, I believe.
Should the normal mode of operation in the case be to return an e
Hi Greg,
It turns out that Mellanox decided to change the device ID at the last
minute. So of course there will be parts with both IDs. Here's an
updated patch that includes both IDs. Please use this instead.
Thanks,
Roland
Add PCI device IDs for new Mellanox "Sinai" InfiniHost III Lx HC
Or> By "performance characteristics" do you mean the extra
Or> overhead to generate another rkey for the already registered
Or> address range (and also to create/free the mw)?
No, I mean the performance cost of binding/unbinding the MW.
- R.
__
James> I ask because the DAT API contains interfaces that allow
James> users to interact with memory windows.
Are there any real applications that use those interfaces?
Thanks,
Roland
___
openib-general mailing list
openib-general@openib.org
h
Title: RE: [openib-general] Question
The bug is only in the meaning of the report.
No other issue was found with it.
The Anafa1 will report this wrong value only after reboot.
EZ
Eitan Zahavi
Design Technology Director
Mellanox Technologies LTD
Tel:+972-4-9097208
Fax:+972-4-9593245
P.O. Bo
roland> James> It is my understanding that the current MTHCA driver does
roland> James> not support InfiniBand memory windows or memory
roland> James> registration using virtual addresses.
roland>
roland> James> Is this information correct? If so, when will these
roland> James
Hi Eitan,
On Tue, 2005-03-01 at 01:26, Eitan Zahavi wrote:
> Hal wrote:
> > So this looks like a workaround for a bug. Not sure what any of the
> other symptoms
> > are but I'm real curious now. Can someone comment more on this ?
>
> The ERR 3610 is really just a warning. It is caused by the Ana
>
> Roland> First, let's understand the problem we're trying to solve.
> Roland> Who are the consumers of this address translation service?
>
> shaharf> Any ULPs at user & kernel, and also some
> shaharf> applications.
>
> I think this is too general an answer. We should be des
Eric, let me correct some of your assumptions
Which this API is actually targeting to protect against, see below
> -Original Message-
> From: Eric W. Biederman [mailto:[EMAIL PROTECTED] On Behalf Of Eric W.
> Biederman
> Sent: Tuesday, March 01, 2005 9:18 AM
> To: Yaron Haviv
> Cc: Roland
38 matches
Mail list logo
