[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070103151823.GR6019@mellanox.co.il>
Date: Wed, 3 Jan 2007 17:18:23 +0200
From: "Michael S. Tsirkin" <mst@...lanox.co.il>
To: Steve Wise <swise@...ngridcomputing.com>
Cc: netdev@...r.kernel.org, Roland Dreier <rdreier@...co.com>,
linux-kernel@...r.kernel.org, openib-general@...nib.org
Subject: Re: [PATCH v4 01/13] Linux RDMA Core Changes
> > > > 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.
This might be an interesting datapoint.
--
MST
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists