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 956C72C24 for ; Fri, 26 May 2017 00:08:10 +0200 (CEST) Received: from pps.filterd (m0048193.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v4PM6tgd025078; Thu, 25 May 2017 15:08:09 -0700 Received: from hq1wp-exmb12.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 2ap0cq28q4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 25 May 2017 15:08:09 -0700 Received: from HQ1WP-EXMB11.corp.brocade.com (10.70.20.185) by HQ1WP-EXMB12.corp.brocade.com (10.70.20.186) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 25 May 2017 15:08:07 -0700 Received: from HQ1WP-EXMB11.corp.brocade.com ([fe80::4534:b177:107a:bcd8]) by Hq1wp-exmb11.corp.brocade.com ([fe80::4534:b177:107a:bcd8%20]) with mapi id 15.00.1210.000; Thu, 25 May 2017 15:08:07 -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//kxEA Date: Thu, 25 May 2017 22:08:07 +0000 Message-ID: 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.120.21.171] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-25_17:, , 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-1705250401 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: Thu, 25 May 2017 22:08:12 -0000 > 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. Regards, Nachi > Thanks, > Shri