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
