public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: "Marciniszyn,
	Mike" <mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	"linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Problem running rping over Intel adapters
Date: Wed, 03 Oct 2012 17:40:57 -0400	[thread overview]
Message-ID: <506CB0E9.90201@redhat.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

We ran into this problem when testing rping over Intel/QLogic hardware:

[root@rdmaperf3 ~]# rping -s -a 172.31.2.103 -v
wait for CONNECTED state 10
connect error -1
cma event RDMA_CM_EVENT_REJECTED, error 28
[root@rdmaperf3 ~]#


[root@rdmaperf8 ~]# rping -c -a 172.31.2.103 -v -C 5
cma event RDMA_CM_EVENT_CONNECT_ERROR, error -1
wait for CONNECTED state 4
connect error -1
[root@rdmaperf8 ~]#

Turns out this is because of a couple things:

1) rping, on the client side, clears the conn_params for the newly to be
attempted connection, then sets:

	conn_param.responder_resources = 1;
	conn_param.initiator_depth = 1;
	conn_param.retry_count = 10;

On the accept side, rping clears the conn_params and then sets just the
responder_resources and initiator_depth, without even checking the
incoming requested conn_param values from the incoming cm_id.  So, OK,
you can get away with that since this is a simple test program, but
still not "best programming practices".  However, the important part
here is the retry_count of 10.  That won't work on Intel/QLogic hardware.

2) the qib driver enforces a maximum of 7 for retry_count.  I don't see
anything in the spec that specifies a maximum for this entry, and in
particular I know it doesn't call out for 7 to mean infinite retries
like it does for rnr_retry_count.

I don't think the spec really cares how we solve this, and I don't think
there is a hard limit of 7 for the retry_count like the qib driver
enforces.  On the other hand, the spec doesn't call out a limit on the
retry_count but I would assume each driver has the option to implement
their own "reasonable, implementation defined" limit in a case like this.

So, do we make qib more liberal in its acceptance of retry_count or do
we fix rping to use a smaller number?  Matters not to me...

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 895 bytes --]

             reply	other threads:[~2012-10-03 21:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-03 21:40 Doug Ledford [this message]
     [not found] ` <506CB0E9.90201-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-10-03 21:50   ` Problem running rping over Intel adapters Hefty, Sean
     [not found]     ` <1828884A29C6694DAF28B7E6B8A8237346A98E58-Q3cL8pyY+6ukrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2012-10-03 21:57       ` Doug Ledford
     [not found]         ` <506CB4D8.4010604-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-10-03 22:02           ` Hefty, Sean
     [not found]             ` <1828884A29C6694DAF28B7E6B8A8237346A98E8E-Q3cL8pyY+6ukrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2012-10-03 22:05               ` Doug Ledford
2012-10-04  1:47               ` Steve Wise
     [not found]                 ` <506CEAC1.9070808-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
2012-10-04  5:41                   ` Or Gerlitz
     [not found]                     ` <506D2174.10601-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2012-10-04 14:27                       ` Steve Wise
     [not found]                         ` <506D9CD2.20606-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
2012-10-04 15:01                           ` Hefty, Sean
     [not found]                             ` <1828884A29C6694DAF28B7E6B8A8237346A99126-Q3cL8pyY+6ukrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2012-10-04 15:08                               ` Steve Wise
2012-10-03 22:38   ` Hefty, Sean
     [not found]     ` <1828884A29C6694DAF28B7E6B8A8237346A98ECB-Q3cL8pyY+6ukrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2012-10-04 13:55       ` Marciniszyn, Mike

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=506CB0E9.90201@redhat.com \
    --to=dledford-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox