All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Dreier <rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
To: Jack Morgenstein
	<jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
Cc: rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Tziporet Koren <tziporet-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>,
	diego-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org
Subject: Re: [PATCH 2/4] ib_core: implement XRC RCV qp's
Date: Wed, 05 May 2010 15:56:46 -0700	[thread overview]
Message-ID: <adaaasearf5.fsf@roland-alpha.cisco.com> (raw)
In-Reply-To: <201005050945.05729.jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> (Jack Morgenstein's message of "Wed, 5 May 2010 09:45:05 +0300")

 > The uverbs layer DOES handle the counting/listing (see, for example,
 > list_add_tail at the end of ib_uverbs_create_xrc_rcv_qp.

But that is the per-process list of rcv QPs... not the reference
counting for each rcv QP.  Look at how trivial
ib_uverbs_destroy_xrc_rcv_qp is -- there is no reference counting of the
real object there.

 > However, I had an additional problem -- to distribute async events received
 > for the xrc_rcv QP to all registered processes (so that each could unregister
 > and allow the QP to be destroyed -- the ref count going to zero).

 > In my original implementation, the low-level driver was responsible for generating
 > the events for all the processes.  To move this mechanism to the core would require
 > a fairly extensive re-write.  I would need to introduce ib_core methods for create,
 > reg, unreg, and destroy, since the uverbs layer operates per user process and does
 > not track across multiple processes.  I was concerned that modifications of this
 > magnitude would introduce instability in XRC, and would require a significant QA cycle

It seems to me that it should, if anything, be easier to track all these
lists at the uverbs layer.  We already have a global xrcd structure for
each xrcd that we could easily stick a list of rcv QPs in (and keep the
list of rcv QP registrations per rcv QP). 

I do see your point that the changes might be fairly large (although the
total XRC code is not so big), but we shouldn't stick ourselves with a
wrong implementation just because that implementation was already tested.

 > Finally, I do not believe that it is such a bad thing to have low-level driver
 > procedures for reg/unreg here.  If a given low-level driver has implementation
 > details that it wishes to record, it should have the opportunity to do so.

Hmm.  I'm having a hard time imagining what those details are -- I
really do feel that this tracking of per-process reference counting etc
is something that we should do once in the core, rather than hiding it
in low-level drivers.

 - R.
-- 
Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
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

  parent reply	other threads:[~2010-05-05 22:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-28  9:02 [PATCH 2/4] ib_core: implement XRC RCV qp's Jack Morgenstein
     [not found] ` <201002281102.21207.jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2010-04-22 18:03   ` Roland Dreier
     [not found]     ` <adaljcfmkj9.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
2010-05-05  5:36       ` Jack Morgenstein
2010-04-29 19:46   ` Roland Dreier
     [not found]     ` <adavdbaxcs1.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
2010-05-05  6:45       ` Jack Morgenstein
     [not found]         ` <201005050945.05729.jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2010-05-05 22:40           ` Roland Dreier
     [not found]             ` <adaeihqas5y.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
2010-05-08  7:28               ` Jack Morgenstein
     [not found]                 ` <201005081028.20327.jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2010-05-08 13:13                   ` Dhabaleswar Panda
2010-05-09  8:10                   ` Ishai Rabinovitz
2010-05-05 22:56           ` Roland Dreier [this message]
     [not found]             ` <adaaasearf5.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
2010-05-10 10:01               ` Jack Morgenstein
     [not found]                 ` <201005101301.43113.jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2010-05-10 10:34                   ` Jack Morgenstein

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=adaaasearf5.fsf@roland-alpha.cisco.com \
    --to=rdreier-fyb4gu1cfyuavxtiumwx3w@public.gmane.org \
    --cc=diego-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org \
    --cc=jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org \
    --cc=tziporet-VPRAkNaXOzVS1MOuV/RT9w@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.