Di Domenico, Michael wrote:
> Is there a way to use the build.sh script that comes with OFED to build
> a debug version of all the things listed in the ofed.conf file?
>
>
>
>
Please see OFED RN
(https://openib.org/svn/gen2/branches/1.0/ofed/docs/OFED_release_notes.txt)
section 3.2:
3.2 Inst
Hi and welcome John
:)
On Wednesday 16 August 2006 09:01, john t wrote:
> Hi,
>
> I am new to openIB and have some questions.
>
> - A QP has two work queues, send work queue and receive work queue. When
> host A sends a data buffer to host B using a QP (RC), I want to know if data
> is copied
Hi James,
Sorry for the delay, we had a long weekend.
> > > My opinion is that the create_qp taking generic parameters is
> > > correct, only subsequent calls may need to use transport specific
> > > calls/arguments. Infact rdma_create_qp uses the ibv_create_qp (now
> > > changed to rdmav_crea
Hi,
I am new to openIB and have some questions.
- A QP has two work queues, send work queue and receive work queue. When host A sends a data buffer to host B using a QP (RC), I want to know if data is copied into the send work queue of host A and then into the receive work queue of host B or is
On Tue, 2006-08-15 at 15:18 -0700, Roland Dreier wrote:
> Louis> Hi there, I would like to know if any application today
> Louis> uses ib_get_dma_mr verb with remote access flag(s).
>
> Yes, the SRP initiator does.
So does NFSoRDMA...
>
> - R.
>
> __
Louis> Hi there, I would like to know if any application today
Louis> uses ib_get_dma_mr verb with remote access flag(s).
Yes, the SRP initiator does.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/lis
This updated version of the ib_ipath mmap patch uses
vmalloc_user() and remap_vmalloc_range() as Roland suggested.
Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]>
diff -r dcc321d1340a drivers/infiniband/hw/ipath/Makefile
--- a/drivers/infiniband/hw/ipath/Makefile Sun Aug 06 19:00:05 2006 +
On Tue, 2006-08-15 at 17:49, Steve Wise wrote:
> > > According to the spec, C10-15 sez the qkey in the outgoing packet will
> > > be the qkey from the QP context IF the high order bit of the qkey is
> > > set. If the high order bit is _not_ set, then the outgoing packet will
> > > contain the qkey
Hi there,
I would like to know if any application today uses ib_get_dma_mr verb with
remote access flag(s).
It seems to me that such a dependency could first, create a security hole
and second, make this verb hard to implement for some RNICs.
If only local access is required for this "special" m
> >
> > Where does it say that a mcast group is associated with any qkey at all?
>
> In order to create a multicast group, the Q_Key needs to be supplied.
> See p. 912-3 o15-0.2.3
>
Thanks Hal.
I'm beginning to understand... :-)
___
openib-genera
> > According to the spec, C10-15 sez the qkey in the outgoing packet will
> > be the qkey from the QP context IF the high order bit of the qkey is
> > set. If the high order bit is _not_ set, then the outgoing packet will
> > contain the qkey from the WR. (why? why?)
>
> The high order bit is fo
>> 1) Doesn't need to be in the group (as sean pointed out)
>
>Yes it does. There are send only ("non") members in the JoinState
>component of the MCMemberRecord. This can be used to optimize the MC
>routing (as that port never needs to receive but needs to be able to
>send on the MLID).
I believe
On Tue, 2006-08-15 at 17:41, Steve Wise wrote:
> On Tue, 2006-08-15 at 17:29 -0400, Hal Rosenstock wrote:
> > On Tue, 2006-08-15 at 17:18, Sean Hefty wrote:
> > > > > App 1:
> > > > > Creates QP with QKey=22
> > > > > Joins multicast group 1 with QKey=33
> > > > >
> > > > > App 2:
> > > > > Creates
On Tue, 2006-08-15 at 17:40, Sean Hefty wrote:
> >p.145 13) where it states that "Further, in addition to having the same
> >MGID, all members of the multicast group must share the same P_Key and
> >Q_Key.
> >
> >That is compliance per C4-3 on p. 143.
>
> Thanks - my take is that the compliance br
Is there a way to use the build.sh script that comes with OFED to build
a debug version of all the things listed in the ofed.conf file?
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubs
On Tue, 2006-08-15 at 17:26, Steve Wise wrote:
> On Tue, 2006-08-15 at 14:18 -0700, Sean Hefty wrote:
> > > > App 1:
> > > > Creates QP with QKey=22
> > > > Joins multicast group 1 with QKey=33
> > > >
> > > > App 2:
> > > > Creates QP with QKey=44
> > > > Joins multicast group 1
> > > > Sends to m
On Tue, 2006-08-15 at 17:29 -0400, Hal Rosenstock wrote:
> On Tue, 2006-08-15 at 17:18, Sean Hefty wrote:
> > > > App 1:
> > > > Creates QP with QKey=22
> > > > Joins multicast group 1 with QKey=33
> > > >
> > > > App 2:
> > > > Creates QP with QKey=44
> > > > Joins multicast group 1
> > > > Sends
>p.145 13) where it states that "Further, in addition to having the same
>MGID, all members of the multicast group must share the same P_Key and
>Q_Key.
>
>That is compliance per C4-3 on p. 143.
Thanks - my take is that the compliance breaks when the QPs are first created
with the wrong QKey.
The
On Tue, 2006-08-15 at 17:13, Steve Wise wrote:
> On Tue, 2006-08-15 at 13:55 -0700, Roland Dreier wrote:
>
> > > App 1:
> > > Creates QP with QKey=22
> > > Joins multicast group 1 with QKey=33
> > >
> > > App 2:
> > > Creates QP with QKey=44
> > > Joins multicast group 1
> > > Sends to mu
On Tue, 2006-08-15 at 17:18, Sean Hefty wrote:
> > > App 1:
> > > Creates QP with QKey=22
> > > Joins multicast group 1 with QKey=33
> > >
> > > App 2:
> > > Creates QP with QKey=44
> > > Joins multicast group 1
> > > Sends to multicast group but with QKey=22
> >
> >I think that last send is techni
On Tue, 2006-08-15 at 14:18 -0700, Sean Hefty wrote:
> > > App 1:
> > > Creates QP with QKey=22
> > > Joins multicast group 1 with QKey=33
> > >
> > > App 2:
> > > Creates QP with QKey=44
> > > Joins multicast group 1
> > > Sends to multicast group but with QKey=22
> >
> >I think that last send is
> > App 1:
> > Creates QP with QKey=22
> > Joins multicast group 1 with QKey=33
> >
> > App 2:
> > Creates QP with QKey=44
> > Joins multicast group 1
> > Sends to multicast group but with QKey=22
>
>I think that last send is technically an IBA spec violation.
I'll admit that this definitely seems
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: question: ib_umem page_size
>
> Michael> Roland, could you please clarify what does the page_size
> Michael> field in struct ib_mem do?
>
> It gives the page size for the user memory described by the struct.
> The idea was that
On Tue, 2006-08-15 at 13:55 -0700, Roland Dreier wrote:
> > App 1:
> > Creates QP with QKey=22
> > Joins multicast group 1 with QKey=33
> >
> > App 2:
> > Creates QP with QKey=44
> > Joins multicast group 1
> > Sends to multicast group but with QKey=22
>
> I think that last send is techn
> App 1:
> Creates QP with QKey=22
> Joins multicast group 1 with QKey=33
>
> App 2:
> Creates QP with QKey=44
> Joins multicast group 1
> Sends to multicast group but with QKey=22
I think that last send is technically an IBA spec violation.
- R.
___
>> Steve> I was able to create a mcast group with the mc
>> Steve> qkey==0xe00a0a0a, and 3 apps joined this group, but their
>> Steve> qp qkeys were 0 (I changed ucma_init_ud_qp() to set the qp
>> Steve> qkey to 0). One app sent to the mcgroup ah/qkey/qpn and
>> Steve> the othe
>I don't see how this could work-- to mimic IP, an app has to be able
>to multicast a datagram to multiple destination ports using the same
>multicast group. Since IB multicast groups have a Q_Key associated,
>the only way this could work is if all QPs and MCGs share one Q_Key.
Hmm... I'd like t
On Tue, 2006-08-15 at 16:07, Steve Wise wrote:
> On Tue, 2006-08-15 at 12:39 -0700, Sean Hefty wrote:
> > >Why are these separated? Isn't an address handle needed for each
> > >destination QP? If so, then why is the remote qpn/qkey also needed to
> > >transmit a datagram?
> >
> > The address han
On Tue, 2006-08-15 at 13:17 -0700, Roland Dreier wrote:
> Steve> I was able to create a mcast group with the mc
> Steve> qkey==0xe00a0a0a, and 3 apps joined this group, but their
> Steve> qp qkeys were 0 (I changed ucma_init_ud_qp() to set the qp
> Steve> qkey to 0). One app sent t
Steve> I was able to create a mcast group with the mc
Steve> qkey==0xe00a0a0a, and 3 apps joined this group, but their
Steve> qp qkeys were 0 (I changed ucma_init_ud_qp() to set the qp
Steve> qkey to 0). One app sent to the mcgroup ah/qkey/qpn and
Steve> the other two received
On Tue, 2006-08-15 at 16:12 -0400, Hal Rosenstock wrote:
> On Tue, 2006-08-15 at 15:59, Roland Dreier wrote:
> > > This is what I was referring to. I'm really not familiar with IP
> > multicast
> > > beyond what I read in a book while coding the RDMA CM. It sounds like
> > we might
> > > be
On Tue, 2006-08-15 at 15:59, Roland Dreier wrote:
> > This is what I was referring to. I'm really not familiar with IP multicast
> > beyond what I read in a book while coding the RDMA CM. It sounds like we
> might
> > be able to use the QKey as the port number for the QP to mimic the
> behav
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: question: ib_umem page_size
>
> Michael> Roland, could you please clarify what does the page_size
> Michael> field in struct ib_mem do?
>
> It gives the page size for the user memory described by the struct.
> The idea was that
On Tue, 2006-08-15 at 12:39 -0700, Sean Hefty wrote:
> >Why are these separated? Isn't an address handle needed for each
> >destination QP? If so, then why is the remote qpn/qkey also needed to
> >transmit a datagram?
>
> The address handle doesn't include QPN/QKey information. Maybe think of t
Michael> Roland, could you please clarify what does the page_size
Michael> field in struct ib_mem do?
It gives the page size for the user memory described by the struct.
The idea was that if/when someone tries to optimize for huge pages,
then the low-level driver can know that a region is
> This is what I was referring to. I'm really not familiar with IP multicast
> beyond what I read in a book while coding the RDMA CM. It sounds like we
> might
> be able to use the QKey as the port number for the QP to mimic the behavior.
I don't see how this could work-- to mimic IP, an ap
>Why are these separated? Isn't an address handle needed for each
>destination QP? If so, then why is the remote qpn/qkey also needed to
>transmit a datagram?
The address handle doesn't include QPN/QKey information. Maybe think of them
more as specifying the path to some port.
- Sean
[adding back to list]
On Tue, 2006-08-15 at 11:59 -0700, Sean Hefty wrote:
>
> >For type SOCK_DGRAM (UDP), the socket will receive packets from multiple
> >subscribed ip mcast groups iff the dst_port of the incoming packet
> >matches the port to which the socket is bound...
>
> This is what I w
accidentally dropped off the list...
Forwarded Message
From: Sean Hefty <[EMAIL PROTECTED]>
To: 'Steve Wise' <[EMAIL PROTECTED]>
Subject: RE: [openib-general] IB mcast question
Date: Tue, 15 Aug 2006 11:59:12 -0700
FYI - your reply dropped off the list.
>For type SOCK_DGRAM (
Roland, could you please clarify what does the page_size field
in struct ib_mem do?
--
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailm
>One of the reserved bytes in the MGID is 1 rather than 0 and it's using
>an IPv4 signature (0x401b) ?
It uses a signature of 0x4001 to avoid conflicts with ipoib groups.
>Where does the qkey come from on the creation of the group ?
The qkey is the same as the IPv4 address.
I need to spend some
On Tue, 2006-08-15 at 14:33, Sean Hefty wrote:
> >Is the IP address only used locally to construct the MGID ? What does
> >the MGID look like ? What signature does it use if any ?
>
> The IP address may also used be used to lookup routing information in order to
> bind to a local device. The addr
>Is the IP address only used locally to construct the MGID ? What does
>the MGID look like ? What signature does it use if any ?
The IP address may also used be used to lookup routing information in order to
bind to a local device. The address is then used locally construct the MGID.
The MGID loo
>In my IP-centric mind, the sender specifies the ip mcast address and a
>remote port. All hosts with subscribers to the ip mcast address get the
>packet, and all sockets on those hosts who are bound to the dst_port
>receive a copy. Other sockets on those hosts that joined the ipmcast
>group but
On Tue, 2006-08-15 at 14:18, Sean Hefty wrote:
> >> A potential fix I see for this is to use the same qkey for all UD QPs and
> >> multicast groups created by the RDMA CM. Otherwise we restrict UD QPs to
> >using
> >> a single destination (remote UD QP or multicast group.)
> >
> >Doesn't the QKey
>> A potential fix I see for this is to use the same qkey for all UD QPs and
>> multicast groups created by the RDMA CM. Otherwise we restrict UD QPs to
>using
>> a single destination (remote UD QP or multicast group.)
>
>Doesn't the QKey need to be the same as the one used for the IPoIB
>broadcas
>> > What about local_sa ? Does it need this change too ?
>>
>> No idea. I'm focusing on 2.6.18 mainly.
>> local sa revocation policy is not really clear to me,
>> maybe it's already covered?
ib_multicast is okay, but ib_local_sa could probably use the change.
- Sean
Hello, Roland!
The following makes it possible to recover from catastrophic
errors through device reset. Could you please queue it for 2.6.19?
Implementation detail:
Catastrophic event device reset. Implemented via a fatal list, in
which device objects are queued for resetting. A spinlock guaran
Ryszard Jurga wrote:
> Hi Arlin,
>
> Thank you for your quick reply. Both dat_ep_post_rdma_read nad
> dat_ep_post_rdma_write return DAT_SUCCESS. When I read a field
> 'transfered_length' from DAT_DTO_COMPLETION_EVENT_DATA after calling a
> post function I receive the correct value which equals
On Tue, 2006-08-15 at 13:53, Michael S. Tsirkin wrote:
> Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > Subject: Re: [PATCH] IB/core: fix SM LID/LID changewithclient reregister set
> >
> > On Tue, 2006-08-15 at 12:45, Michael S. Tsirkin wrote:
> > > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]
Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] IB/core: fix SM LID/LID changewithclient reregister set
>
> On Tue, 2006-08-15 at 12:45, Michael S. Tsirkin wrote:
> > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > > > This patch simply restores the previous behavior of th
On Tue, 2006-08-15 at 12:58, Sean Hefty wrote:
> >The qkeys used by the RDMA CM sound like they may be the problem. I'll
> >verify
> >this and see how to fix it if so.
>
> If I set the qkeys for the QPs and MCMemberRecord to 0, I can get this to work
> now. The RDMA CM uses a qkey = port number
On Tue, 2006-08-15 at 12:45, Michael S. Tsirkin wrote:
> Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > > This patch simply restores the previous behavior of the sa_query and
> > > cache
> > > modules in responding to events.
> >
> > Understood but doesn't it also has the effect of doing mor
On Tue, 2006-08-15 at 09:58 -0700, Sean Hefty wrote:
> >The qkeys used by the RDMA CM sound like they may be the problem. I'll
> >verify
> >this and see how to fix it if so.
>
> If I set the qkeys for the QPs and MCMemberRecord to 0, I can get this to work
> now. The RDMA CM uses a qkey = port
>The qkeys used by the RDMA CM sound like they may be the problem. I'll verify
>this and see how to fix it if so.
If I set the qkeys for the QPs and MCMemberRecord to 0, I can get this to work
now. The RDMA CM uses a qkey = port number for UD QPs, and a qkey = IPv4
address for MCMemberRecords.
Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > This patch simply restores the previous behavior of the sa_query and cache
> > modules in responding to events.
>
> Understood but doesn't it also has the effect of doing more than this
> for certain cases of Set PortInfo ?
Not that I can see.
>Steve> How about qp attributes? pkeys? qkeys?
>
>Good question -- yes, the QPs will need be to set up with the right
>keys for packets to appear. It's definitely something to check.
The qkeys used by the RDMA CM sound like they may be the problem. I'll verify
this and see how to fix it if
Can you see if this patch lets you build compost?
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
Index: examples/cmpost.c
===
--- examples/cmpost.c (revision 8215)
+++ examples/cmpost.c (working copy)
@@ -614,6 +614,7 @@ out:
>I only saw SA SRs, PRs. and MCMs not MPRs. Did I miss the MPR support ?
Ah - this is in my local copy. I defined all attribute lengths (in an enum). I
wanted to get the libibsa support completed to make sure that the SA interfaces
provided what I needed. I will need to extract this patch, and
On Tue, 2006-08-15 at 11:52, Sean Hefty wrote:
> >Do you mean multiple path records rather than multipath record queries
> >here ?
>
> I meant multiple path records (GET_TABLE), but the interface is designed to
> handle both. The current implementation doesn't handle multipath record
> queries
>
>Do you mean multiple path records rather than multipath record queries
>here ?
I meant multiple path records (GET_TABLE), but the interface is designed to
handle both. The current implementation doesn't handle multipath record queries
with more than 1 SGID and 1 DGID. (I.e. it uses a size of 56
On Tue, 2006-08-15 at 11:06, Jack Morgenstein wrote:
> On Tuesday 15 August 2006 17:42, Hal Rosenstock wrote:
> >
> > Are these two events equivalent ? e.g. does LID change require
> > reregistration ? (That's a potential overhead as well).
> >
>
> Before the change in mthca_mad.c (sm_snoop), the
Jack Morgenstein wrote:
> Before the change in mthca_mad.c (sm_snoop), the LID CHANGE event was
> generated in all cases where a SET port-info MAD was received.
>
> After the change, either LID_CHANGE -- or -- CLIENT_REREGISTER is generated.
> (i.e., CLIENT REREGISTER replaced LID_CHANGE in thos
Hi Yevgeny,
On Wed, 2006-08-02 at 11:16, Yevgeny Kliteynik wrote:
> Hi Hal
>
> This patch adds new verbosity functionality.
I finally got some time to look this over and have a few comments on it
(see embedded text).
Generally, this looks good. One other thing that should be added to this
patch
Roland Dreier wrote:
> Ishai>[ishai] This is another tool for srp. I thought that
> Ishai> we want to put several tools in srptools directory. I will
> Ishai> put it in
> Ishai> https://openib.org/svn/gen2/trunk/src/userspace/srp_daemon
>
> It would be fine to have the srp d
>My code fails on using the ib_cm_create_id call.
Not sure why this happened.
>Looked around for some running examples using the libibcm but could not
>find them.
>Got a pointer to:
>
>https://openib.org/svn/gen2/branches/1.0/src/userspace/libibcm/examples/
>but those wont compile.
>Can someone h
Tziporet> So do you suggest we change the current srptools
Tziporet> Makefile to include this daemon too?
Sure, that would be fine.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-genera
It is the same result for link level address.
- Vladimir
Roland Dreier wrote:
> Vladimir> When I run: # ip maddres add 224.0.0.9 dev ib0
>
> It's poorly documented, but "ip maddr add" needs a link level address,
> not an IP address.
>
> - R.
>
>
_
On Tue, 2006-08-15 at 10:59, Michael S. Tsirkin wrote:
> Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > Are these two events equivalent ? e.g. does LID change require
> > reregistration ? (That's a potential overhead as well).
>
> Client reregistration support is an optional SM feature
I don
On Tuesday 15 August 2006 17:42, Hal Rosenstock wrote:
>
> Are these two events equivalent ? e.g. does LID change require
> reregistration ? (That's a potential overhead as well).
>
Before the change in mthca_mad.c (sm_snoop), the LID CHANGE event was
generated in all cases where a SET port-info
Vladimir> When I run: # ip maddres add 224.0.0.9 dev ib0
It's poorly documented, but "ip maddr add" needs a link level address,
not an IP address.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/op
MGID from the log:
Aug 15 17:57:20 737657 [40796BB0] -> MCMember Record dump:
MGID0x : 0x7eb525c040f1
PortGid.0xfe80 : 0x0002c9020020d8ed
Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> Are these two events equivalent ? e.g. does LID change require
> reregistration ? (That's a potential overhead as well).
Client reregistration support is an optional SM feature
> What about deregistration of the old registrations when this occurs
On Tue, 2006-08-15 at 10:30, Vladimir Sokolovsky wrote:
> When I run:
> # ip maddres add 224.0.0.9 dev ib0
> I got (dmesg):
> ib0: joining MGID :::::7eb5:25c0:40f1
> ib0: multicast join failed for: :::::7eb5:25c0:40f1,
> status -22
>
> And from the SM side:
On Thu, 2006-08-03 at 13:37, Sean Hefty wrote:
> The following patch adds a generic interface to send MADs to the SA.
> The primary motivation of adding these calls is to expand the SA query
> interface to include RMPP responses for users wanting more than a
> single attribute returned from a query
On Tue, 2006-08-15 at 10:20, Michael S. Tsirkin wrote:
> Hi, Roland!
> Please consider the following patch for 2.6.18 - this fixes a regression
> from 2.6.17 for us.
>
> After commit 12bbb2b7be7f5564952ebe0196623e97464b8ac5, when
> SM LID change or LID change MAD also has a client reregistration b
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Michael> Hi, Roland! There does not, at the moment, seem to exist
> Michael> a way to find out which HCA port the specific SRP host is
> Michael> connected through.
Here's the updated version of the patch. Pls queue for 2.6.19.
Add loca
When I run:
# ip maddres add 224.0.0.9 dev ib0
I got (dmesg):
ib0: joining MGID :::::7eb5:25c0:40f1
ib0: multicast join failed for: :::::7eb5:25c0:40f1,
status -22
And from the SM side:
ERR 1B01: Wrong MGID Prefix 0x00 must be 0xFF
Regards,
Vladimir
Rolan
Steve> How about qp attributes? pkeys? qkeys?
Good question -- yes, the QPs will need be to set up with the right
keys for packets to appear. It's definitely something to check.
If different mcmembers are used for the first join of the group and
subsequent joins by another QP, that could ex
How about qp attributes?
pkeys?
qkeys?
On Tue, 2006-08-15 at 07:15 -0700, Roland Dreier wrote:
> Steve> Just throwing out ideas here: Maybe something in the
> Steve> ib_sa_mcmember_rec is prohibiting replication on the HCA?
> Steve> And maybe ib_multicast is incorrectly building t
Hi, Roland!
Please consider the following patch for 2.6.18 - this fixes a regression
from 2.6.17 for us.
After commit 12bbb2b7be7f5564952ebe0196623e97464b8ac5, when
SM LID change or LID change MAD also has a client reregistration bit
set, only CLIENT_REREGISTER event is generated.
As a result, th
Steve> Just throwing out ideas here: Maybe something in the
Steve> ib_sa_mcmember_rec is prohibiting replication on the HCA?
Steve> And maybe ib_multicast is incorrectly building this
Steve> record...
Shouldn't make a difference -- if one copy of the packet arrives at
the HCA then
Just throwing out ideas here:
Maybe something in the ib_sa_mcmember_rec is prohibiting replication on
the HCA? And maybe ib_multicast is incorrectly building this record...
struct ib_sa_mcmember_rec {
union ib_gid mgid;
union ib_gid port_gid;
__be32 qkey;
__
Hi Arlin,
Thank you for your quick reply. Both dat_ep_post_rdma_read nad
dat_ep_post_rdma_write return DAT_SUCCESS. When I read a field
'transfered_length' from DAT_DTO_COMPLETION_EVENT_DATA after calling a post
function I receive the correct value which equals num_segs*seg_size.
Unfortunately
Ishai> [ishai] This is another tool for srp. I thought that
Ishai> we want to put several tools in srptools directory. I will
Ishai> put it in
Ishai> https://openib.org/svn/gen2/trunk/src/userspace/srp_daemon
It would be fine to have the srp daemon be built as part of srptool
Hi,
I'm just trying to port my IB gen1 application to gen2 in order to get
it running on a SLES 9 SP3 x86_64 Linux workstation.
I got stuck in porting the usage of the libcm in gen1 to libibcm in
gen2.
My code fails on using the ib_cm_create_id call.
Looked around for some running examples using th
The OFED-1.1-rc1 source tar ball (openib-1.1.tgz ) created by build_ofed.sh
script (from https://openib.org/svn/gen2/branches/1.1/ofed/build)
build_ofed.sh script takes userspace libraries/binaries after executing:
autogen.sh
configure
make dist
Therefor, autogen.sh is not a part of it and als
can you send me this code?
I suspect the main difference is that I'm using librdmacm to join and
leave mcast groups.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please
On Mon, 2006-08-14 at 07:36, Dotan Barak wrote:
> Hi.
>
> I noticed that the behavior of the openSM was changed in the latest driver:
>
> in the past, every HCA was configured (by the FW) with 0x in the first
> entry.
> today,
Just as an FYI: I think that Anafas have this in the second entr
See Below
-Original Message-
From: Roland Dreier [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 15, 2006 1:48 AM
To: Ishai Rabinovitz
Cc: openib-general@openib.org; Tziporet Koren
Subject: Re: A new version for srp daemon
> I put the code in
>
https://openib.org/svn/trunk/contrib/mel
Quoting r. zhu shi song <[EMAIL PROTECTED]>:
> Subject: why sdp connections cost so much memory
>
> (1) ibv_devinfo
> HCA: MHES18-XTC
> FW: 1.1.0
> OFED: OFED-1.1-rc1
> (2) Test Bed
> On Client:
> ib0: 193.12.10.24
> test command:
> LD_PRELOAD=/usr/local/ofed/lib64/libsdp.so
> SIMPLE_LIBSDP=1 ab
(1) ibv_devinfo
HCA: MHES18-XTC
FW: 1.1.0
OFED: OFED-1.1-rc1
(2) Test Bed
On Client:
ib0: 193.12.10.24
test command:
LD_PRELOAD=/usr/local/ofed/lib64/libsdp.so
SIMPLE_LIBSDP=1 ab -c m -n m -X 193.12.10.14:3129
http://www.sse.com.cn/sseportal/ps/zhs/home.shtml
The web page is about 68K.
On Server:
92 matches
Mail list logo
