From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by dpdk.org (Postfix) with ESMTP id D0F4C1B154 for ; Fri, 28 Sep 2018 00:41:34 +0200 (CEST) Received: by mail-wm1-f52.google.com with SMTP id s12-v6so387054wmc.0 for ; Thu, 27 Sep 2018 15:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UCToXo+k8a8e7IWL10SoZtqWIs04pL+JfRENIxhXkFA=; b=GoHLQGEDqOEiN1495o6369fbNUXnTe7hPrQElzhCLTUmZvkZ+UTs4RMxO9OguplmTB NKFRZjp77tX3xPLd3srGYE1IsdY5bBllvsXRXGXSP58EK/BullYA35DrOfxcokWLRuJr l8GI4RuksQlRfDynRLtRpfNd9i4uXL6ci5VmZ7kEDOveV8LIsBghPgVsYpwEUre26pFj VNsy5QtmukVrSDBm9NeRL2CioA7Lcm6SusH86WR6d8W/mqOw9Iuq8H6GPy46Yb491/Pf 2VdUOkT9sFc3tt1CgchsD+NcuHZ8iVrycNeFfsZf9Y2Jzs8221hqRCXj1YK/dRJdp+Td 005Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UCToXo+k8a8e7IWL10SoZtqWIs04pL+JfRENIxhXkFA=; b=p1g8ezdszsEw2ti9yEUGH6hXDeCmA6FA0s95tXIvK4cw4XM5L/Lt+VQFQJowkJilf/ L4fBMfQHauvlC+fUYL+DkOU2KQyrgBAnTX3M493ST5xTmx0faqUx6MuKAeeBWBcesI+i JpFR/6gpgf+vMkGwlPp4Tm2SF+nSRKfKH8iCLzbv15E5fDAepq8UP+JWb4bNIXRI0jTk Li28S+tfLMthalENmuXHGx4qw7dEjhoO/DgGjwjJ3hrGzvbYdV4rQvWarGhBzIa381n1 MKDhtIjd9OTD8xkl7MHOq5C13FVMH9SlnPoDeOjTCqvsLe5pxzDR3i759sV5KuC/pdPL K23g== X-Gm-Message-State: ABuFfoif4vI97ORzfSe9MrXWEd5p1QfuBWb2muqKOS3Kx2P8N0yV+2Pv QSiJSIv7TuXkuxVRZm1yKPtFxLOuj9G37TX6lmw= X-Google-Smtp-Source: ACcGV61yxqR3iGKMQG038CW8BSQxpzKF/RBXOAYj08qtkQVmgQm60Fgi69ZiffDiSGKcP+kW4quoQozAhjVSNntG/mE= X-Received: by 2002:a1c:3581:: with SMTP id c123-v6mr402677wma.50.1538088093978; Thu, 27 Sep 2018 15:41:33 -0700 (PDT) MIME-Version: 1.0 Sender: dan.gora@gmail.com Received: by 2002:adf:fbc1:0:0:0:0:0 with HTTP; Thu, 27 Sep 2018 15:40:53 -0700 (PDT) In-Reply-To: References: <20180911232906.18352-1-dg@adax.com> <20180919195549.5585-1-dg@adax.com> <20180919195549.5585-6-dg@adax.com> <1bc03874-f981-f5f2-e071-76c4fc1da96e@intel.com> From: Dan Gora Date: Thu, 27 Sep 2018 19:40:53 -0300 X-Google-Sender-Auth: I7NrNIUODluMKQzy0QYlUx8ybZk Message-ID: To: Ferruh Yigit Cc: dev@dpdk.org, Igor Ryzhov , Stephen Hemminger Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 5/5] examples/kni: improve zeroing statistics 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, 27 Sep 2018 22:41:35 -0000 On Thu, Sep 27, 2018 at 7:04 PM, Ferruh Yigit wrote: >> >> With no traffic it's worse because the worker threads perform these >> increments even more often! > > Dear Dan, > > Your implementation doesn't prevent the race when there is traffic, it can be Correct. To do that would require per-cpu counters or atomic increments. That all seems a bit much for a simple example app. > useful when there is no traffic, that is why my suggestion was in signal > handler, stop worker threads, zero stats, start workers again. > But for traffic case this will cause packet lost so overall may not be desirable. Yeah, of course it would cause packet loss while traffic is running, that's why I didn't even consider that.. >>> Yes effect is small but it is for each packet, it doesn't make sense to me to >>> add extra check for each packet for the rare case of stats reset. >> >> Its not rare at all! You cannot zero the statistics around 80% of the >> time on my machine when there is no traffic. It's trivial to >> reproduce this. Just run a little traffic, stop the traffic, zero the >> stats and check the stats. > > I was trying to say, packet transfer is millions per second, so the waste is in > that scale, but clear stats will be called in the scale of seconds/minutes? Or > not at all perhaps for some cases? Even at 100G 64 byte packets, this one extra instruction is not going to make any difference. In fact I would bet money that it will actually improve performance by decreasing the pressure on that cache line, which is shared between the tx and rx threads (and cores! possibly on different sockets!). Currently you have two cores constantly dirtying the same cache line every few instructions for no reason other than to read and write back the same value if no data was tx/rx'd. >> If you cannot zero the statistics reliably under any circumstance then >> the statistics themselves are worthless and should be removed. It's >> better to have no stats than completely unreliable ones. > > How much really you rely on sample application stats clear, and stats are still > useful of course since you can use them without reset. Well, you can, but... Say you're doing a data transfer test and you want to make sure that no packets are lost. You stop the traffic, zero the counters, run the test, look at the counters. Oops, they are different! Oh yeah, the silly test app cannot zero the counters, I forgot... So then you have to go back, find the old stats (if you checked them first), copy that number into dc, do the subtraction by hand, etc.. It just seems all a bit much, especially for a toy example application. That said, this is by no means a hill I want to die on. If you don't want to add it, that's fine... d