Re: [PATCH rdma-next 00/16] Flow counters support

[Jason Gunthorpe <jgg-uk2M96/98Pc@public.gmane.org>]

On Thu, Nov 02, 2017 at 06:11:07PM +0200, Alex Rosenbaum wrote:
> On Thu, Nov 2, 2017 at 5:38 PM, Jason Gunthorpe <jgg-uk2M96/98Pc@public.gmane.org> wrote:
> > On Thu, Nov 02, 2017 at 08:50:22AM +0200, Alex Rosenbaum wrote:
> >
> > So, if every path has a atomic/batch API, do you still want to include
> > the single counter add capability? It would be fine to me to drop the
> > object arg, but keep the single counter and differentiated API..
> 
> I think single counter add with user space bookkeeping is good and
> simple API for applciations.
> 
> what do you mean by "differentiated API"?
> do you mean keep the ibv_add_xxx_qp() but remove the ibv_qp object
> input parameter? same for flow?

Yes

> if yes, isn't it simpler to do ibv_create_counters_qp() or
> ibv_create_counters(QP), and keep a single non differentiated add
> sample counter point on a clearly defined ibv_counter

You want to have the counters object itself linked to only QP or only
flow? Why?

The counter object should be able to aggregate counting
anything so that a single kernel round trip will return all of the
desired counters on any sort of object.

The point of the per-object differentiation is to keep the counter
labling simpler:

 ibv_add_sampling_point(counters, 0, QP, RX_BYTES)
 ibv_add_sampling_point(counters, 1, FLOW, RX_BYTES)
 ibv_add_sampling_point(counters, 2, QP, RX_PACKETS)
 ibv_add_sampling_point(counters, 3, FLOW, RX_PACKETS)

vs

 ibv_add_sampling_point(counters, 0, RX_BYTES_QP)
 ibv_add_sampling_point(counters, 1, RX_BYTES_FLOW)
[..]

Observing that most of the things we will want to count will likely
apply equally to qps, flows and other things. # packets, # bytes,
in/out versions, etc.

Jason
--
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