Hi, Thanks, I have sent a v2.
Any comment on the problem of dropped mbuf that I described in the cover letter? In our application the max_latency_ns metric is useless since after running for a while it would always take on obviously incorrect value (up to a few minutes). I suspect the impact on avg_latency_ns is much less severe but significant nonetheless. > -----Original Message----- > From: reshma.pat...@intel.com [mailto:reshma.pat...@intel.com] > Sent: Thursday, September 20, 2018 5:25 PM > To: long...@viettel.com.vn > Cc: dev@dpdk.org; sta...@dpdk.org > Subject: RE: [PATCH] latency: clear mbuf timestamp after latency calculation > > Hi, > > > -----Original Message----- > > From: long...@viettel.com.vn [mailto:long...@viettel.com.vn] > > Sent: Wednesday, September 19, 2018 9:23 AM > > To: Pattan, Reshma <reshma.pat...@intel.com> > > Cc: dev@dpdk.org; Bao-Long Tran <long...@viettel.com.vn>; > > sta...@dpdk.org > > Subject: [PATCH] latency: clear mbuf timestamp after latency > > calculation > > > > 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. > > > > Cc: sta...@dpdk.org > > > > Signed-off-by: Bao-Long Tran <long...@viettel.com.vn> > > You need to add the Fixes line just before CC: in the commit message. > > Original commit that introduced the bug was 5cd3cac9ed. So fixes should be > added like below > Fixes: 5cd3cac9ed ("latency: added new library for latency stats"). > > You can send v2 with fixes line and my ack. Other than that > > Acked-by: Reshma Pattan <reshma.pat...@intel.com>
