On Thu, 25 May 2017, Nachi Prachanda wrote:
> > From: Shrikrishna Khare [mailto:skh...@shri-linux.eng.vmware.com] > > Sent: Wednesday, May 24, 2017 2:10 PM > > > > On Fri, 19 May 2017, Charles (Chas) Williams wrote: > > > > > From: Nachiketa Prachanda <nprac...@brocade.com> > > > > > > Most nics like virtio, igb/ixgbe etc. don't reset counters on > > > dev_start and arguably this helps in monitoring the counters across a > > > longer time span with multiple device start/stops. > > > vmxnet3 behavior is opposite to that and counters are reset by the > > > host side implementation each time the device is restarted. > > > > > > Change the driver to save the counters in its private context before > > > it is reset by writing CMD_ACTIVATE to REG_CMD. > > > > > > Signed-off-by: Nachiketa Prachanda <nprac...@brocade.com> > > > > This won't be able to deal with vMotion or suspend/resume? > > Correct - this can't deal with the VM suspend/resume unless hypervisor > maintains the counter. But this patch doesn't make that behavior any worse > than what it was before. The current code always resets stats, but am concerned that this patch will make the behavior inconsistent for cases like suspend/resume. Wondering if this will be better handled by the device emulation instead of the driver (for igb/ixgbe, is this handled by the hardware?). If we were to handle this in the device emulation, what would be the goals/requirements: - device start/stop should not reset stats? - any other operations where we would like to maintain/reset stats? - what might be the expectation around how accurate the stats need to be? - any other requirement on the device? Also, note that if we proceed with this patch, and later extend device support to not reset stats, driver with this patch running on the extended device will report incorrect stats. Thanks, Shri
