public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Rosser <jonathan.rosser-gjMux1o1B1/QXOPxS62xeg@public.gmane.org>
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Extending rdma_server example
Date: Mon, 18 Oct 2010 12:31:02 +0000 (UTC)	[thread overview]
Message-ID: <loom.20101018T140608-776@post.gmane.org> (raw)

Hi,

I took librdmacm/examples/rdma_server.c and converted it to be a persistent
server to serve successive requests. However, this does not work and I have 
the following problem:

fprintfs from my code (lower case) and librdmacm (caps) for a first successful
connection and a second one which causes a segfault

rdma_getaddrinfo
rdma_listen
rdma_getrequest              <----- wait for first request
RDMA CREATE QP
UCMA CREATE_CQS
CALLED UCMA CREATE CQS
CREATING RECV_CQ             <----- CQ created here OK for client connection
CREATING SEND_CQ             <----- this looks good
IBV CREATE QP
rdma_reg_msgs
rdma_post_recv
rdma_accept
rdma_get_recv_comp
rdma_post_send
rdma_get_send_comp
rdma_getrequest              <----- wait for second request
RDMA CREATE QP
UCMA CREATE_CQS
CALLED UCMA CREATE CQS       <----- !!! no recv/send CQ created here
IBV CREATE QP
rdma_reg_msgs
rdma_post_recv
rdma_accept
rdma_get_recv_comp           <----- dereference of id->recv_cq = NULL
Segmentation fault

So I'm wondering why the CQs do not get created second time round and it
looks like

1) rdma_get_request passes event_id and (listen_id)id_priv->qp_init_attr to
   rdma_create_qp()

2) rdma_create_qp passes qp_init_attr to ucma_create_cqs()

3) ucma_create_cqs stores a pointer to the created CQs in attr->recv_cq /
   send_cq, which is the attr of the listen_id

4) serving the second client, ucma_create_cqs checks attr->recv_cq and does 
   not create a pair of CQs

Feels a little odd to me that the listen_id takes a pointer to the CQs created
for the client_id in its qp_init_attr.

Can anyone enlighten me? Am I trying to do something (persistent server) that
rdma_get_request is not intended to do?

Cheers,
Jonathan Rosser
Senior R&D Engineer
BBC R&D

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

             reply	other threads:[~2010-10-18 12:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-18 12:31 Jonathan Rosser [this message]
     [not found] ` <loom.20101018T140608-776-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
2010-10-18 16:25   ` Extending rdma_server example Hefty, Sean
2010-10-18 17:27   ` [PATCH] librdmacm: Do not modify qp_init_attr in rdma_get_request Hefty, Sean
2010-10-19  8:28     ` Jonathan Rosser

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=loom.20101018T140608-776@post.gmane.org \
    --to=jonathan.rosser-gjmux1o1b1/qxopxs62xeg@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@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