On Thu, Jul 15, 2021 at 1:55 PM Bruce Richardson <bruce.richard...@intel.com> wrote: > > On Thu, Jul 15, 2021 at 12:14:05PM +0530, Jerin Jacob wrote: > > On Tue, Jul 13, 2021 at 7:08 PM Bruce Richardson > > <bruce.richard...@intel.com> wrote: > > > > > > On Tue, Jul 13, 2021 at 09:06:39PM +0800, fengchengwen wrote: > > > > > > 4. COMMENT:> + uint64_t reserved[4]; /**< Reserved for future > > > > fields */ > > > > > +}; > > > > Please add the capability for each counter in info structure as one > > > > device may support all the counters. > > > > > > > > REPLY: This is a statistics function. If this function is not supported, > > > > then do not need to implement the stats ops function. Also could to set > > > > the unimplemented ones to zero. > > > > > > > +1 > > > The stats functions should be a minimum set that is supported by all > > > drivers. Each of these stats can be easily tracked by software if HW > > > support for it is not available, so I agree that we should not have each > > > stat as a capability. > > > > In our current HW, submitted_count and completed_count offloaded to HW. > > In addition to that, we have a provision for getting stats for bytes > > copied.( We can make it as xstat, if other drivers won't support) > > > > our plan is to use enqueued_count and completed_fail_count in SW under > > condition compilation flags or another scheme as it is in fastpath. > > > > If we are not planning to add capability, IMO, we need to update the > > documentation, > > like unimplemented counters will return zero. But there is the > > question of how to differentiate between > > unimplemented vs genuine zero value. IMO, we can update the doc for > > this case as well or > > add capability. > > > > While we could add capabilities for stats, I'd really rather not. Let's > just get an agreed upon minimum set. Seems like submitted and completed are > fine for all, which just leaves two to discuss for an in/out decision. > > Jerin, can fail count be kept without conditional compilation, perhaps, > because it should not be touched in the fastpath but just on error legs?
Agree. > > For enqueued_count, in our driver I was just going to track the difference > between last doorbell and this one - which we would be tracking anyway, or > could compute very easily by saving last doorbell counter - and add that to > the submitted count when stats are requested. That would again ensure no > fastpath impact bar perhaps storing one additional variable (old DB) per > burst. If that is felt too cumbersome, I think we can drop it, but lets at > least keep error count. +1 to keep submitted_count, completed_count, and fail count. enqueue count can be move to xstat if it is supported by drivers. Also since drivers are returning, 0-2^16 monotonically incrementing counter , even applications can track the enqueue count if needed without the driver support. > > Thanks, > /Bruce
