On Thu, Jul 15, 2021 at 03:19:55PM +0530, Jerin Jacob wrote: > 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. > Agreed. Let's just stick to 3 basic stats.
/Bruce
