Re: [dpdk-dev] Incorrect latencystats implementation

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

Hi Reshma,

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Pattan, Reshma
> Sent: Friday, September 21, 2018 12:15 PM
> To: longtb5@viettel.com.vn
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] Incorrect latencystats implementation
> 
> Hi,
> 
> > -----Original Message-----
> > From: longtb5@viettel.com.vn [mailto:longtb5@viettel.com.vn]
> > Sent: Friday, September 21, 2018 2:58 AM
> > To: Pattan, Reshma <reshma.pattan@intel.com>
> > Cc: dev@dpdk.org
> > Subject: RE: Incorrect latencystats implementation
> >
> > Hi Reshma,
> >
> > > -----Original Message-----
> > > From: reshma.pattan@intel.com [mailto:reshma.pattan@intel.com]
> > > Sent: Thursday, September 20, 2018 8:09 PM
> > > To: longtb5@viettel.com.vn
> > > Cc: dev@dpdk.org
> > > Subject: RE: Incorrect latencystats implementation
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: longtb5@viettel.com.vn [mailto:longtb5@viettel.com.vn]
> > > > Sent: Wednesday, September 19, 2018 9:17 AM
> > > > To: Pattan, Reshma <reshma.pattan@intel.com>
> > > > Cc: dev@dpdk.org; Bao-Long Tran <longtb5@viettel.com.vn>
> > > > Subject: Incorrect latencystats implementation
> > > >
> > > >
> > > > I have submit a patch to implement the trivial fix. For the drop
> > > > case I can think of 2 options. We can either clear timestamp when
> > > > putting mbufs back to their pool, or change lib latencystats
> > > > implementation to perform packet selection at TX callback and let RX
> > > > callback add
> > timestamp
> > > to every packet.
> > > > Both option could affect performance but I think the second option
> > > > is less aggressive.
> > >
> > > What happens when applications drop the packets? Do they free the mbuf?
> > > In such case, can application set the timestamp to 0 before freeing
> > > the
> > mbuf,
> > > instead of making these changes in latency library.?
> > >
> >
> > Yes, applications can set the mbuf timestamp before freeing. But in my
> > opinion that would not be a clean solution. Applications should not have to
> > worry about the timestamp field at all, since that is an implementation detail
> > of the library. For simple apps, wrapping rte_pktmbuf_free() to perform
> > timestamp reset could be done without much hassle, but that kind of ad-hoc
> > solution would become messy for more complex ones where packets are
> > dropped at different places. From a usability point of view, as an user I want
> > the lib to provide latency measurements without me having to touch existing
> > codebase other than adding codes that use the APIs.
> >
> 
> I will send a patch to  add timestamp reset in rte_pktmbuf_free().  That will be a cleaner way  I think.
> Let's see what other says on the patch.

That would probably affect performance.
Actually, looking at rte_mbuf.h - timestamp field supposed to be valid only if PKT_RX_TIMESTAMP is set.
>From other side, as I remember, PMD RX routine should reset RX flags of the received PMD.
So in theory you can rely on PKT_RX_TIMESTAMP to determine use this mbuf for latency calcs or not.
Would that help?
Konstantin

> 
> Thanks,
> Reshma