Disregard this for now... I see there is more crazyness with OpenSM's
gen_ver.sh script...
:-(
Ira
On Thu, 26 Jul 2012 17:42:51 -0700
Ira Weiny wrote:
>
> This ensures plugin compatibility.
>
> Signed-off-by: Ira Weiny
> ---
> include/opensm/osm_version.h.in |2 +-
> 1 files changed
This ensures plugin compatibility.
Signed-off-by: Ira Weiny
---
include/opensm/osm_version.h.in |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/opensm/osm_version.h.in b/include/opensm/osm_version.h.in
index d783245..7a29b77 100644
--- a/include/opensm/osm_vers
On Thu, Jul 26, 2012 at 10:38 AM, "Xavier R. Guérin" wrote:
> is there any overhead associated with using GIDs?
yes, every packet is 40 bytes longer.
> man ibv_post_recv tells me that the GRH is written into the first 40 bytes of
> the receive buffer for UD QPs. Is that behavior only restricted
> I wonder if I might be seeing the same thing...
>
> How does one choose a good value for this setting?
>
> Apparently it maps to 4.096 x 2 ^ attr.timeout microseconds.
>
> What's the maximum value one can set here?
>
> What can go wrong if one goes for the maximum value?
In theory you want a tim
On Thu, Jul 26, 2012 at 01:38:03PM -0400, "Xavier R. Gu?rin" wrote:
> > It is the source GID of the local adaptor. Generally you can just use
> > index 0, particularly on RoCEE..
>
> thanks, this fixed my problem.
>
> A couple questions:
>
> is there any overhead associated with using GIDs?
Ye
>> On a side note, I see from rc_pingpong that ibv_query_gid requires
>> an index, and that this index is asked to the user of the pingpong
>> program. What is that index about (the man page is not very
>> explicit)? Cannot it be deduced in any way ?
>
> It is the source GID of the local adaptor
On Thu, Jul 26, 2012 at 09:49:57AM -0400, "Xavier R. Gu?rin" wrote:
> On a side note, I see from rc_pingpong that ibv_query_gid requires
> an index, and that this index is asked to the user of the pingpong
> program. What is that index about (the man page is not very
> explicit)? Cannot it be ded
he queue pairs successfully switch from RESET to INIT, but miserably fail
to switch from INIT to RTR with an EINVAL error code.
>>>
>>> On IBoE, are you passing in a path with a global routing info, ie a GID?
>>
>> for example, what is the value of
>>
>> qp_attr.ah_attr.is_global
>
Hello
On Thu, Jul 26, 2012 at 9:15 AM, Roland Dreier wrote:
> On Wed, Jul 25, 2012 at 7:07 PM, Ira Weiny wrote:
>> attr.timeout = 14;
> Is this timeout sufficient to account for the round trip on
> the fabric and the ack delay on the remote HCA?
> I don't think there are any othe
Hello Roland,
>>> he queue pairs successfully switch from RESET to INIT, but miserably fail
>>> to switch from INIT to RTR with an EINVAL error code.
>>
>> On IBoE, are you passing in a path with a global routing info, ie a GID?
>
> for example, what is the value of
>
>qp_attr.ah_attr.is_g
On Thu, Jul 26, 2012 at 12:24 AM, Roland Dreier wrote:
> On Wed, Jul 25, 2012 at 9:53 PM, "Xavier R. Guérin" wrote:
>> I am confronted to a strange behavior with ibv_modify_qp. I moved my
>> application from ConnectX3 (IB) to ConnectX2-EN (RoCE), and my queue pairs
>> refuse to reset on the RoC
On Wed, Jul 25, 2012 at 9:53 PM, "Xavier R. Guérin" wrote:
> I am confronted to a strange behavior with ibv_modify_qp. I moved my
> application from ConnectX3 (IB) to ConnectX2-EN (RoCE), and my queue pairs
> refuse to reset on the RoCE board (no problem on the IB board).
>
> The queue pairs suc
On Wed, Jul 25, 2012 at 7:07 PM, Ira Weiny wrote:
> attr.timeout = 14;
Is this timeout sufficient to account for the round trip on
the fabric and the ack delay on the remote HCA?
I don't think there are any other attributes that would affect
getting transport retries.
- R.
--
T
13 matches
Mail list logo
