> > > > 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 linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
