linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve Wise <swise@opengridcomputing.com>
To: "Michael S. Tsirkin" <mst@mellanox.co.il>
Cc: Roland Dreier <rdreier@cisco.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	openib-general@openib.org
Subject: Re: [PATCH  v4 01/13] Linux RDMA Core Changes
Date: Wed, 03 Jan 2007 09:07:21 -0600	[thread overview]
Message-ID: <1167836841.4187.18.camel@stevo-desktop> (raw)
In-Reply-To: <20070103150013.GO6019@mellanox.co.il>

On Wed, 2007-01-03 at 17:00 +0200, Michael S. Tsirkin wrote:
> > > 
> > > No, it won't need 2 transitions - just an extra function call,
> > > so it won't hurt performance - it would improve performance.
> > > 
> > > ib_uverbs_req_notify_cq would call
> > > 
> > > 	ib_uverbs_req_notify_cq()
> > > 	{
> > > 			ib_set_cq_udata(cq, udata)
> > > 			ib_req_notify_cq(cq, cmd.solicited_only ?
> > > 				IB_CQ_SOLICITED : IB_CQ_NEXT_COMP);
> > > 	}
> > > 
> > 
> > ib_set_cq_udata() would transition into the kernel to pass in the
> > consumer's index.  In addition, ib_req_notify_cq would also transition
> > into the kernel since its not a bypass function for chelsio.
> 
> We misunderstand each other.
> 
> ib_uverbs_req_notify_cq is in drivers/infiniband/core/uverbs_cmd.c -
> all this code runs inside the IB_USER_VERBS_CMD_REQ_NOTIFY_CQ command,
> so there is a single user to kernel transition.
> 

Oh I see. 

This seems like a lot of extra code to avoid passing one extra arg to
the driver's req_notify_cq verb.  I'd appreciate other folk's input on
how important they think this is.  

If you insist, then I'll run some tests specifically in kernel mode and
see how this affects mthca's req_notify performance.

Steve.






  reply	other threads:[~2007-01-03 15:07 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-14 13:52 [PATCH v4 00/13] 2.6.20 Chelsio T3 RDMA Driver Steve Wise
2006-12-14 13:53 ` [PATCH v4 01/13] Linux RDMA Core Changes Steve Wise
2006-12-24  8:49   ` Michael S. Tsirkin
2007-01-03 14:25     ` Steve Wise
2007-01-03 14:41       ` Michael S. Tsirkin
2007-01-03 14:56         ` Steve Wise
2007-01-03 15:00           ` Michael S. Tsirkin
2007-01-03 15:07             ` Steve Wise [this message]
2007-01-03 15:18               ` Michael S. Tsirkin
2007-01-03 19:17                 ` Steve Wise
2007-01-03 19:33                   ` Michael S. Tsirkin
2007-01-03 20:20                     ` Steve Wise
2007-01-03 21:22                       ` [openib-general] " Steve Wise
2007-01-04  5:07                         ` Michael S. Tsirkin
2007-01-04 14:07                           ` Steve Wise
2007-01-04 21:34                         ` [openib-general] " Roland Dreier
2007-01-04 21:49                           ` Steve Wise
2007-01-05 14:22                           ` Steve Wise
2007-01-03 15:02           ` Michael S. Tsirkin
2007-01-03 15:06             ` Steve Wise
2007-01-03 15:10               ` Michael S. Tsirkin
2006-12-14 13:53 ` [PATCH v4 02/13] Device Discovery and ULLD Linkage Steve Wise
2006-12-14 13:54 ` [PATCH v4 03/13] Provider Methods and Data Structures Steve Wise
2006-12-14 13:54 ` [PATCH v4 04/13] Connection Manager Steve Wise
2006-12-14 13:55 ` [PATCH v4 05/13] Queue Pairs Steve Wise
2006-12-14 13:55 ` [PATCH v4 06/13] Completion Queues Steve Wise
2006-12-14 13:56 ` [PATCH v4 07/13] Async Event Handler Steve Wise
2006-12-14 13:56 ` [PATCH v4 08/13] Memory Registration Steve Wise
2006-12-14 13:57 ` [PATCH v4 09/13] Core WQE/CQE Types Steve Wise
2006-12-14 13:57 ` [PATCH v4 10/13] Core HAL Steve Wise
2006-12-14 13:58 ` [PATCH v4 11/13] Core Resource Allocation Steve Wise
2006-12-14 13:58 ` [PATCH v4 12/13] Core Debug functions Steve Wise
2006-12-14 13:59 ` [PATCH v4 13/13] Kconfig/Makefile Steve Wise
2007-01-05 17:32 [openib-general] [PATCH v4 01/13] Linux RDMA Core Changes Felix Marti
2007-01-06 17:34 ` Michael S. Tsirkin

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=1167836841.4187.18.camel@stevo-desktop \
    --to=swise@opengridcomputing.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@mellanox.co.il \
    --cc=netdev@vger.kernel.org \
    --cc=openib-general@openib.org \
    --cc=rdreier@cisco.com \
    /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;
as well as URLs for NNTP newsgroup(s).