Although SDP is not working correctly now, it can
easily support many existing applications based on
Sockets API. Patrick say rdma is a connected model
and has serious scalability problem. But Does
send/recv model has or support SDP-alike API?
zhu
_
At 07:46 PM 8/23/2006, Roland Dreier wrote:
>Greg> Actually, that leads me to a question: does the vendor of
>Greg> that adaptor say that this is actually safe? Just because
>Greg> something behaves one way most of the time doesn't mean it
>Greg> does it all of the time. So it it re
Changes from v1:
The ib_usa module exports two files: ib_usa_default and ib_usa_raw.
Use of the ib_usa_default restricts the user to sending PathRecord,
MultiPathRecord, MCMemberRecord, and ServiceRecord queries, and joining /
leaving multicast groups.
Use of ib_usa_raw allows any MADs to be sen
Woodruff, Robert J wrote:
> Catlin wrote,
>
>> For iWARP there are network performance reasons why in-order memory
>> writes will never be guaranteed.
>
> For iWarp, or any other RDMA over Ethernet protocol, the
> behavior is not to guarantee all packets are written
> in-order, just that the last
On Thu, Aug 24, 2006 at 04:13:22PM -0700, Sean Hefty wrote:
> >Why don't you measure it, then?
>
> Why? Reading a memory location directly will be faster than calling a
> function
> to read from a memory location.
... sigh. This is not true, there are quite obvious implementations
where this i
>> Polling on a CQ involves a function call, synchronization to the CQ, and
>> formatting a structure to return to the user. I don't see this ever being
>> faster than polling memory.
>
>Why don't you measure it, then?
Why? Reading a memory location directly will be faster than calling a functio
On Thu, Aug 24, 2006 at 03:53:37PM -0700, Woodruff, Robert J wrote:
> If the overhead in polling the CQ rather than memory was not so
> high, they would have used it, but they found that it added > 2us to
> the latency and found they could get better performance if they
> polled memory,
I keep on
Catlin wrote,
>For iWARP there are network performance reasons why in-order
>memory writes will never be guaranteed.
For iWarp, or any other RDMA over Ethernet protocol, the
behavior is not to guarantee all packets are written
in-order, just that the last byte of the last packet is
written last.
On Thu, Aug 24, 2006 at 03:43:38PM -0700, Sean Hefty wrote:
> >Actually, if a hardware implementation provided the same performance
> >(in this case latency) by polling on a CQ as one where polling on
> >memory was guaranteed to work, the customer may actually prefer the
> >"standard" implementatio
Greg wrote,
>In this case we're talking about code which can easily be changed to
>follow the standard, in addition to having a hack mode that's faster
>on 1 particular hardware implementation.
>You seem to be implying that the applications are set in stone, and
>that their authors have no intere
For those of you interested in this topic, there's an interesting
article by Patrick Geoffrey in HPCWire entitled "A Critique of RDMA".
http://www.hpcwire.com/hpc/815242.html
(you might have to be a subscriber, but I'm sure Patrick would send
you a copy if you ask.)
It's basically a critique of
[EMAIL PROTECTED] wrote:
> On 8/24/06, Woodruff, Robert J <[EMAIL PROTECTED]> wrote:
>> If the feature gives them a huge advantage in performance (and it
>> does) and all of the hardware vendors that they deal with already
>> implement it, then yes, they will force, by defacto standard that all
>>
On Thu, Aug 24, 2006 at 03:37:21PM -0700, Sean Hefty wrote:
> I'm missing the standard you're using to judge what's theoretically good and
> bad.
Having simpler programming to get good performance is a theoretical
good. Extra hacks for specific hardware is theoretically bad,
pratically good only
>Actually, if a hardware implementation provided the same performance
>(in this case latency) by polling on a CQ as one where polling on
>memory was guaranteed to work, the customer may actually prefer the
>"standard" implementation.
Polling on a CQ involves a function call, synchronization to the
>But you're still confusing practicality and theory. I can see why it's
>pratical sense for newcomers to implement this new, performance-
>reducing feature. But why is it theoretically good?
I'm missing the standard you're using to judge what's theoretically good and
bad.
Applications are written
On Thu, Aug 24, 2006 at 03:28:44PM -0700, Woodruff, Robert J wrote:
> Yes, IMO, the iWarp folks and the IBTA should consider making this a
> requirement, but even if they do not the ISVs will still require it.
Ahah. So with all this head and light, we agree that it should be
added to the standar
On 8/24/06, Woodruff, Robert J <[EMAIL PROTECTED]> wrote:
> If the feature gives them a huge advantage in performance (and it does)
> and all of the hardware vendors that they deal with already implement
> it, then yes,
> they will force, by defacto standard that all other newcomers implement
> it
Greg wrote,
>reducing feature. But why is it theoretically good? And shouldn't it
>be added to the standard, before all the poor iWarp people discover
>the hard way that they need it?
>-- greg
Yes, IMO, the iWarp folks and the IBTA should consider making this a
requirement, but even if they do
On Thu, Aug 24, 2006 at 03:13:33PM -0700, Woodruff, Robert J wrote:
> If the feature gives them a huge advantage in performance (and it
> does) and all of the hardware vendors that they deal with already
> implement it, then yes, they will force, by defacto standard that
> all other newcomers impl
Greg wrote,
>On Thu, Aug 24, 2006 at 02:10:38PM -0700, Woodruff, Robert J wrote:
>> The other way to look at it is, the customer goes to the ISV and
asks,
>> what hardware should I buy, and the ISV says I support X version of
MPI
>> and vendor Y's hardware works with X version of MPI.
>I thought
On Thu, Aug 24, 2006 at 02:58:18PM -0700, Sean Hefty wrote:
> >We're trying to create *inter-operable* hardware and
> >software in this community. So we follow the IB standard.
>
> Atomic operations and RDD are optional, yet still part of the IB "standard".
> An
> application that makes use of e
>We're trying to create *inter-operable* hardware and
>software in this community. So we follow the IB standard.
Atomic operations and RDD are optional, yet still part of the IB "standard". An
application that makes use of either of these isn't guaranteed to operate with
all IB hardware. I'm not
On Thu, Aug 24, 2006 at 02:10:38PM -0700, Woodruff, Robert J wrote:
> The other way to look at it is, the customer goes to the ISV and asks,
> what hardware should I buy, and the ISV says I support X version of MPI
> and vendor Y's hardware works with X version of MPI.
I thought the goal of Infi
Greg wrote,
>OK, great. I'm fine with people using things which are supported, but
>then we need the big, blinking "Warning! This program is non-standard,
and
>won't work with many of the devices supported by Open Fabrics!" sign.
>-- greg
The other way to look at it is, the customer goes to the
>OK, great. I'm fine with people using things which are supported, but
>then we need the big, blinking "Warning! This program is non-standard, and
>won't work with many of the devices supported by Open Fabrics!" sign.
If an application were written to use Myrinet, would you consider it
non-standar
On Wed, Aug 23, 2006 at 04:46:52PM -0700, Roland Dreier wrote:
> Yes, Mellanox documents that it is safe to rely on the last byte of an
> RDMA being written last.
OK, great. I'm fine with people using things which are supported, but
then we need the big, blinking "Warning! This program is non-sta
Folks:
Is there a utility within the OFED1.0 package which can be used for
generating traffic on different SL (akin to the Voltaire perf_main utility)?
Many thanks,
Suri
___
openib-general mailing list
openib-general@openib.org
http://openib.org/m
On Thu, Aug 24, 2006 at 01:57:39PM -0700, Sean Hefty wrote:
> >OK, great. I'm fine with people using things which are supported, but
> >then we need the big, blinking "Warning! This program is non-standard, and
> >won't work with many of the devices supported by Open Fabrics!" sign.
>
> If an appl
On Thu, 2006-08-24 at 09:31 -0700, Roland Dreier wrote:
> Along those lines, how would people feel if I removed the mthca kernel
> code from svn, and just maintained mthca in kernel.org git trees?
+1 from me. We'll drop the ipath code, too.
http://openib.org/mailman/listinfo/openib-gene
Here is a patch that I used in my backport to 2.6.9 for RedHat EL4 - U3
svn 8841 openib fixups patch. It also applies to svn9006 and will
likely work fine on the OFED 1.1 code if you replace the current patch
that removes the creation of the abi_version with this one that
creates it under /sys/c
Roland Dreier wrote:
> Sean> Why not remove your code from SVN?
>
> Along those lines, how would people feel if I removed the mthca kernel
> code from svn, and just maintained mthca in kernel.org git trees? I
> am getting heartily sick of double checkins for every mthca change...
I think thi
I committed this change to the librdmacm in svn 9105. It still requires a
backport patch for the kernel code.
- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please vi
On Thu, 24 Aug 2006 09:18:50 -0700
"Sean Hefty" <[EMAIL PROTECTED]> wrote:
> Michael S. Tsirkin wrote:
> > Maybe the librdmacm part should be merged to svn?
> > So librdmacm could try to read from misc, then from
> > /sys/class/infiniband/rdma_cm, and then assume latest.
> > It's good to have user
I have no idea what your bug is, but as for this part:
> 1. Are there any race issues with ibv_get_cq_event? The example code
> (ud_pingpong) seems to imply that the correct sequence is
>
> Start:
>
> Call ibv_get_cq_event
>
> Call ibv_ack_cq_event
Sean> Why not remove your code from SVN?
Along those lines, how would people feel if I removed the mthca kernel
code from svn, and just maintained mthca in kernel.org git trees? I
am getting heartily sick of double checkins for every mthca change...
- R.
___
Michael S. Tsirkin wrote:
>>And even with these proposed changes, there's a race condition where the CM
>>can timeout a connection after data is received over it, but before this event
>>can be processed.
>
>
> Hmm. And what happens then?
The connection is aborted by the CM. The CM sends a REJ
Michael S. Tsirkin wrote:
> Maybe the librdmacm part should be merged to svn?
> So librdmacm could try to read from misc, then from
> /sys/class/infiniband/rdma_cm, and then assume latest.
> It's good to have userspace code portable across distros ...
I can go with that.
- Sean
_
> > Hotplug event of HCA FATAL is supported and this is the #1 issue we
are
> troubled with.
>
> No I mean real hotplug.
[EZ] And umad will provide it?
>
> --
> MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/lis
Quoting r. Eitan Zahavi <[EMAIL PROTECTED]>:
> Subject: RE: [PATCH] osm: handle local events
>
> Hi MST,
>
> Hotplug event of HCA FATAL is supported and this is the #1 issue we are
> troubled with.
No I mean real hotplug.
--
MST
___
openib-general
On Thu, Aug 24, 2006 at 06:08:07PM +0300, Tziporet Koren wrote:
> Christian Guggenberger wrote:
> >is it also planned to support later kernels than 2.6.5-7.244 ? I tried
> >to build against 2.6.5-7.276, but failed. I also failed a bug (#192)
> >some time ago, but never got a response, unfortunately
Christian Guggenberger wrote:
> is it also planned to support later kernels than 2.6.5-7.244 ? I tried
> to build against 2.6.5-7.276, but failed. I also failed a bug (#192)
> some time ago, but never got a response, unfortunately.
>
>
>
To solve this problem in 1.1 you should apply the followi
Hi MST,
Hotplug event of HCA FATAL is supported and this is the #1 issue we are
troubled with.
Regarding other OpenSM vendors implementations (like the switch stack or
gen1 stacks)
This patch makes OpenSM agnostic for their support of events. If they do
support it OpenSM will
Register and behave
>This is already done - you can use OFED 1.1-rc2 or 1.0.1
>
>Tziporet
Hi,
again, regarding SLES9 SP3.
is it also planned to support later kernels than 2.6.5-7.244 ? I tried
to build against 2.6.5-7.276, but failed. I also failed a bug (#192)
some time ago, but never got a response, unfortunatel
Quoting r. Yevgeny Kliteynik <[EMAIL PROTECTED]>:
> Index: libvendor/osm_vendor_ibumad.c
> ===
> --- libvendor/osm_vendor_ibumad.c (revision 8998)
> +++ libvendor/osm_vendor_ibumad.c (working copy)
> @@ -72,6 +72,7 @@
> #inclu
Hi,
Does IPoIB work across IB subnets. For example if there are 4 IB subnets and all the IB subnets are reachable (meaning there is one host that is in all the IB subnets), then is it possible to ping/ssh to hosts in other IB subnets using IPoIB (assuming there is no ethernet)
Regards,
John T.
This is already done - you can use OFED 1.1-rc2 or 1.0.1
Tziporet
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Troy Telford
Sent: Thursday, August 17, 2006 8:57 PM
To: OPENIB
Subject: Re: [openib-general] OFED 1.1-rc2 is delayed for next Monday
(Aug-21
I did not see this on the reflector.
We did have some mailer problems. So I am resending to the list
One more thing to add:
The only other event we considered was PORT_ACTIVE.
But as it turns out the event is only generated when the port moves into ACTIVE
state
which means an SM already handled i
Hi Hal
This patch implements first item of the OSM todo list.
OpenSM opens a thread that is listening for events on the SM's port.
The events that are being taken care of are IBV_EVENT_DEVICE_FATAL and
IBV_EVENT_PORT_ERROR.
In case of IBV_EVENT_DEVICE_FATAL, osm is forced to exit.
in case of IBV
Quoting r. Robert Pearson <[EMAIL PROTECTED]>:
> Subject: dropped packets
>
> Roland,
>
>
>
> I am trying to write a user level application that receives multicast UD
> packets at user level. I am seeing about 1-2 % packet loss between the send
> side and the receive side apparently independ
On Wednesday 23 August 2006 23:25, Roland Dreier wrote:
> > 5. Return the send_cq, receive cq and srq handles. ib_query_qp() needs
> them
> >(required by IB Spec). ibv_query_qp() overwrites these values in
> user-space
> >with appropriate user-space values.
>
> > + qp_init_attr->se
Roland,
I am
trying to write a user level application that receives multicast UD packets at
user level. I am seeing about 1-2 % packet loss between the send side and the
receive side apparently independent of the packet rate for low rates. (Heavily
traced sends and receives with very lo
51 matches
Mail list logo
