I posted a V2 [1] which is aligned to what we discussed here Alex [1] https://marc.info/?l=linux-rdma&m=151438961826612&w=2 On Thu, Nov 2, 2017 at 6:19 PM, Jason Gunthorpe <jgg@xxxxxxxx> wrote: > 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@xxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
