From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id C529D1B128 for ; Tue, 25 Sep 2018 14:37:45 +0200 (CEST) Received: by mail-wr1-f68.google.com with SMTP id o16so9882093wrx.2 for ; Tue, 25 Sep 2018 05:37:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:mime-version; bh=z5Z/jKtIvb6UdUp8On9znw/lXyMNhooz0IeKmEjy7MQ=; b=fQS+ynGsWk4bg43z8rXhDOcyyjNHu2aOdUjbePlZPLOfm1aIqDz2FeMuEsDs+DlCRM oJpUPZ962SWbs4IWUWTSFmbgaidb4Z99i2BU1KEetsweGoIjCSbdqxswgyiLIt+s9UV8 ilAa1bgjF6luJbIbm/PVaz963701UcZpjcgU3Ej6Fr2K/WJz8Xgdzg8bC78zKw8HQKvb Snhf/lM3fRkbJ7/seX5WTsSudLedeSnYrO/YDl7IdDInyAC4SmZMh/794LBOsGn9a4Ih JWS+CwVUrOehz1x6TBQyuL4otaejxE5Og9XPma6gw2O3/xQmCp3p+R5wOUABKKi8mUL/ GPeg== X-Gm-Message-State: ABuFfogOVUKafdF6MvjOtWZ4N3vFHly5T2K6QTCh9u1o+G745Ony0pkT PWEpxn6V35t14t9x2W5pa6k= X-Google-Smtp-Source: ACcGV6302XdhJmZ7kwhdZeo2Lll3EnYqC24rW1V2oo8vxCagrOtfSEoAk/XrsNZV/GXckYgwdOKr/Q== X-Received: by 2002:a5d:4c49:: with SMTP id n9-v6mr808529wrt.71.1537879065392; Tue, 25 Sep 2018 05:37:45 -0700 (PDT) Received: from localhost ([2001:1be0:110d:fcfe:489f:80a9:5d59:c6bd]) by smtp.gmail.com with ESMTPSA id r13-v6sm2057405wmf.34.2018.09.25.05.37.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 25 Sep 2018 05:37:44 -0700 (PDT) Message-ID: <1537879063.10481.48.camel@debian.org> From: Luca Boccassi To: longtb5@viettel.com.vn Cc: stable@dpdk.org Date: Tue, 25 Sep 2018 13:37:43 +0100 In-Reply-To: <1537345361-70088-2-git-send-email-longtb5@viettel.com.vn> References: <1537345361-70088-1-git-send-email-longtb5@viettel.com.vn> <1537345361-70088-2-git-send-email-longtb5@viettel.com.vn> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Subject: Re: [dpdk-stable] [PATCH] latency: clear mbuf timestamp after latency calculation X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 12:37:45 -0000 On Wed, 2018-09-19 at 15:15 +0700, longtb5@viettel.com.vn wrote: > The timestamp of a mbuf should be cleared after that mbuf was used > for > latency calculation, otherwise future packets which reuse the same > mbuf > would inherit that previous timestamp. The latencystats library looks > for mbuf with non-zero timestamp, thus incorrectly inherited value > would > result in incorrect latency measurement. >=20 > Cc: stable@dpdk.org >=20 > Signed-off-by: Bao-Long Tran > --- > =C2=A0lib/librte_latencystats/rte_latencystats.c | 4 +++- > =C2=A01 file changed, 3 insertions(+), 1 deletion(-) >=20 > diff --git a/lib/librte_latencystats/rte_latencystats.c > b/lib/librte_latencystats/rte_latencystats.c > index 1fdec68..2d5384e 100644 > --- a/lib/librte_latencystats/rte_latencystats.c > +++ b/lib/librte_latencystats/rte_latencystats.c > @@ -156,8 +156,10 @@ calc_latency(uint16_t pid __rte_unused, > =C2=A0 > =C2=A0 now =3D rte_rdtsc(); > =C2=A0 for (i =3D 0; i < nb_pkts; i++) { > - if (pkts[i]->timestamp) > + if (pkts[i]->timestamp) { > =C2=A0 latency[cnt++] =3D now - pkts[i]->timestamp; > + pkts[i]->timestamp =3D 0; > + } > =C2=A0 } > =C2=A0 > =C2=A0 for (i =3D 0; i < cnt; i++) { Hi, Is this patch only for stable releases? If so, which one? Or was dev@ absent by mistake? Thanks --=20 Kind regards, Luca Boccassi