[openib-general] Re: [PATCH] mthca - query qp

Michael S. Tsirkin mst at mellanox.co.il
Sun Mar 19 01:31:40 PST 2006


Quoting r. Roland Dreier <rdreier at cisco.com>:
> Subject: Re: [PATCH] mthca - query qp
> 
> OK, I at least applied the error flow part of this patch, since that's
> clearly something we want.
> 
> I need to think about how to handle the other attributes.  Probably
> anything that just copies values from the struct ib_qp passed in to
> the function should at least be in the generic ib_query_qp function,
> since there's no good reason for every low-level driver to duplicate it.
> 
> However I'm wondering whether we even have the right interface for
> query QP at all.



I think even QP state is already reported to user by means of completion
with error and asynchronous event (and I think same can be said for path
migration state).

I conclude that ib_query_qp is mostly useful for debug.
However, speaking from experience, things you need the most during debug:
number of end to end credits (debug performance problems),
work requests executed (debug data/debug problems)
are actually not part of query qp verb.

> The only thing that the consumer couldn't have saved
> off for themselves is the QP state,

Formally speaking, we also have the send/receive PSN which the users couldn't
have saved off for themselves.

> so maybe the right interface is
> just an ib_query_qp_state() function that gives back the QP's current state.

I don't thinj anyone actually uses query qp, so we probably even can
kill it off altogether.

If the point is to make debugging possible/easier, what I think we are missing
is an interface (in debugfs?) that given QP number, will get us the QP state
in hardware format, with all the detail. This could be implemented as
a separate module.

-- 
Michael S. Tsirkin
Staff Engineer, Mellanox Technologies



More information about the general mailing list