From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Duyck Subject: Re: [PATCH 1/2] ixgbe: fix VF statistic wraparound handling macro Date: Mon, 12 Oct 2015 08:41:34 -0700 Message-ID: <561BD4AE.4010704@gmail.com> References: <1444656823-717-1-git-send-email-harry.van.haaren@intel.com> <1444656823-717-2-git-send-email-harry.van.haaren@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit To: Harry van Haaren , dev@dpdk.org Return-path: Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by dpdk.org (Postfix) with ESMTP id B6F4C8E80 for ; Mon, 12 Oct 2015 17:41:36 +0200 (CEST) Received: by padhy16 with SMTP id hy16so156982608pad.1 for ; Mon, 12 Oct 2015 08:41:36 -0700 (PDT) In-Reply-To: <1444656823-717-2-git-send-email-harry.van.haaren@intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/12/2015 06:33 AM, Harry van Haaren wrote: > Fix a misinterpretation of VF stats in ixgbe > > Signed-off-by: Harry van Haaren > --- > drivers/net/ixgbe/ixgbe_ethdev.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c > index ec2918c..d226e8d 100644 > --- a/drivers/net/ixgbe/ixgbe_ethdev.c > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c > @@ -329,10 +329,14 @@ static int ixgbe_timesync_read_tx_timestamp(struct rte_eth_dev *dev, > /* > * Define VF Stats MACRO for Non "cleared on read" register > */ > -#define UPDATE_VF_STAT(reg, last, cur) \ > +#define UPDATE_VF_STAT(reg, last, cur) \ > { \ > uint32_t latest = IXGBE_READ_REG(hw, reg); \ > - cur += latest - last; \ > + if(likely(latest > last)) { \ > + cur += latest - last; \ > + } else { \ > + cur += (UINT_MAX - last) + latest; \ > + } \ > last = latest; \ > } > From what I can tell your math is adding an off by one error. You should probably be using UINT_MAX as a mask for the result, not as a part of the calculation itself. So the correct way to compute this would be "cur += (latest - last) & UINT_MAX". Also the mask approach should be faster as it avoids any conditional jumps. - Alex