Re: [dpdk-dev] [PATCH 1/6] net/vmxnet3: retain counters on restart

[Shrikrishna Khare <skhare@shri-linux.eng.vmware.com>]

On Thu, 25 May 2017, Nachi Prachanda wrote:

> > From: Shrikrishna Khare [mailto:skhare@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 <nprachan@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 <nprachan@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