From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EX13-EDG-OU-002.vmware.com (ex13-edg-ou-002.vmware.com [208.91.0.190]) by dpdk.org (Postfix) with ESMTP id CDDF2A104 for ; Fri, 26 May 2017 19:29:26 +0200 (CEST) Received: from sc9-mailhost1.vmware.com (10.113.161.71) by EX13-EDG-OU-002.vmware.com (10.113.208.156) with Microsoft SMTP Server id 15.0.1156.6; Fri, 26 May 2017 10:29:17 -0700 Received: from shri-linux.eng.vmware.com (shri-linux.eng.vmware.com [10.33.72.16]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id 8685A183B5; Fri, 26 May 2017 10:29:25 -0700 (PDT) Date: Fri, 26 May 2017 10:29:22 -0700 From: Shrikrishna Khare To: Nachi Prachanda CC: "skhare@vmware.com" , Chas Williams III , "dev@dpdk.org" In-Reply-To: Message-ID: References: <1495216560-12920-1-git-send-email-ciwillia@brocade.com> <6c785a5767ff466293523fbc88c901f0@Hq1wp-exmb11.corp.brocade.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Received-SPF: None (EX13-EDG-OU-002.vmware.com: skhare@shri-linux.eng.vmware.com does not designate permitted sender hosts) Subject: Re: [dpdk-dev] [PATCH 1/6] net/vmxnet3: retain counters on restart X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 17:29:27 -0000 On Thu, 25 May 2017, Nachi Prachanda wrote: > > From: Shrikrishna Khare [mailto:skhare@shri-linux.eng.vmware.com] > > Sent: Thursday, May 25, 2017 1:27 PM > > > > 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 > > > > > > > > > > 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 > > > > > > > > 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?). > > A little more nuanced.. - see below. > > > 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? > > I haven't thought about dealing it at the emulation layer - but the expectation > would be not clear counters not cleared for the lifetime of the device - and have > a way to clear them from the driver when needed. > > don't know if there is a standard behavior about resetting counters. But > for igb/ixgb the counters are read/clear registers and they are maintained > at driver. May not be always accurate if the hardware is reset without updating > the driver's counter - but at least ensures that it is monotonically increasing since > on each read driver only gets the delta. > > virtio emulation doesn't provide the counters - mostly the receive/send functions > updates the counters. > > > > > 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. > > Agree - it will need some work if the emulation changes. I spent some time looking at the emulation code. It turns out that these stats are already retained across vMotion, suspend/resume. And we have no immediate plan to change the device behavior to retain these stats across device start/stop. So am fine with this patch. Thank you for being patient with this. Thanks, Shri > > Regards, > Nachi > > > Thanks, > > Shri >