From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by dpdk.org (Postfix) with ESMTP id 57B2390F2 for ; Fri, 26 May 2017 21:01:46 +0200 (CEST) Received: from pps.filterd (m0000542.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v4QIpFFe019610; Fri, 26 May 2017 12:01:45 -0700 Received: from hq1wp-exmb12.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 2ap8ncuaey-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 26 May 2017 12:01:45 -0700 Received: from HQ1WP-EXMB14.corp.brocade.com (10.70.20.188) by HQ1WP-EXMB12.corp.brocade.com (10.70.20.186) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 26 May 2017 12:01:43 -0700 Received: from HQ1WP-EXMB12.corp.brocade.com (10.70.20.186) by HQ1WP-EXMB14.corp.brocade.com (10.70.20.188) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 26 May 2017 12:01:43 -0700 Received: from HQ1WP-EXMB12.corp.brocade.com ([fe80::b5c6:be43:7d72:632d]) by HQ1WP-EXMB12.corp.brocade.com ([fe80::b5c6:be43:7d72:632d%20]) with mapi id 15.00.1210.000; Fri, 26 May 2017 12:01:43 -0700 From: Nachi Prachanda To: "skhare@vmware.com" CC: Chas Williams III , "dev@dpdk.org" Thread-Topic: [PATCH 1/6] net/vmxnet3: retain counters on restart Thread-Index: AQHS0MkzpBsFEhL6cUyruWMDn/u8kqIEd+MAgADu0yCAAJexgP//kxEAgAHNiAD//6MdcA== Date: Fri, 26 May 2017 19:01:42 +0000 Message-ID: <4cac962ba2ef4a059e44d8884c8e7ea3@HQ1WP-EXMB12.corp.brocade.com> References: <1495216560-12920-1-git-send-email-ciwillia@brocade.com> <6c785a5767ff466293523fbc88c901f0@Hq1wp-exmb11.corp.brocade.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.252.136.47] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-26_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705260328 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 19:01:46 -0000 > -----Original Message----- > From: Shrikrishna Khare [mailto:skhare@shri-linux.eng.vmware.com] > Sent: Friday, May 26, 2017 10:29 AM > To: Nachi Prachanda > Cc: skhare@vmware.com; Chas Williams III; dev@dpdk.org > Subject: RE: [PATCH 1/6] net/vmxnet3: retain counters on restart > > > > 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 for checking this out. Nachi > > Thanks, > Shri > > > > > > Regards, > > Nachi > > > > > Thanks, > > > Shri > >