[dpdk-dev] [PATCH v2 1/4] app/test: unit test for rx and tx cycles/packet

Richardson, Bruce bruce.richardson at intel.com
Tue Oct 21 12:43:03 CEST 2014



> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Tuesday, October 21, 2014 11:33 AM
> To: Liang, Cunming
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 1/4] app/test: unit test for rx and tx
> cycles/packet
> 
> > >
> > > > +	if (count == 0)
> > > > +		return -1;
> > > > +
> > > > +	printf("%lu packet, %lu drop, %lu idle\n", count, drop, idle);
> > > > +	printf("Result: %ld cycles per packet\n", (cur_tsc - prev_tsc) / count);
> > > > +
> > > Bad math here.  Theres no guarantee that the tsc hasn't wrapped (potentially
> > > more than once) depending on your test length.  you need to check the tsc
> before
> > > and after each burst and record an average of deltas instead, accounting in
> each
> > > instance for the possibility of wrap.
> > [Liang, Cunming] I'm not sure catch your point correctly.
> > I think both cur_tsc and prev_tsc are 64 bits width.
> > For 3GHz, I think it won't wrapped so quick.
> > As it's uint64_t, so even get wrapped, the delta should still be correct.
> But theres no guarantee that the tsc starts at zero when you begin your test.
> The system may have been up for a long time and near wrapping already.
> Regardless, you need to account for the possibility that cur_tsc is smaller
> than prev_tsc, or this breaks.
> 

The tsc. is 64-bit and so only wraps around every couple of hundred years or so on a 2GHz machine, so I don't think it's necessary to handle that case. 

/Bruce


More information about the dev mailing list