Re: [dpdk-dev] Packet drops at lower tc transmit-rates.

["Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>]

> -----Original Message-----
> From: Sridhar.V.Iyer [mailto:sridhariyer@versa-networks.com]
> Sent: Wednesday, April 13, 2016 12:39 AM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] Packet drops at lower tc transmit-rates.
> 
> Hi Cristian,
> 
> Thanks for the response.
> 
> >
> > Another potential workaround could be to change the pipe TC credit
> update logic from straightforward re-initialization to a slightly more tuned
> strategy that, in some cases, keeps some of the existing credits, so that the
> existing credits are not completely lost but some of them (value capped to 1x
> MTU) are carried forward:
> >
> > 	pipe->tc_credits[i] = (params->tc_credits_per_period[i] < MTU)?
> > 		((pipe->tc_credits[i] % MTU) + params-
> >tc_credits_per_period[i]) :
> > 		params->tc_credits_per_period[i];
> >
> > This would give the chance to the pipe TC credits to accumulate and
> become greater than the MTU every few periods and a packet to be
> transmitted for this pipe TC. Of course, this strategy needs to be further
> developed.
> 
> This approach seemed to give the apparent rate closest to the configured
> rate, irrespective of the MTU, the packet size, or the min packet size. I’ll use
> the port->mtu to influence the tc_credits_per_period accumulation.
> 
> Is there any particular reason why a token bucket was not used for traffic
> classes?

Yes, all the pipe traffic classes are sharing the rate of their pipe, i.e. credits from the same pipe token bucket. Traffic classes are there just to describe how to divide the pipe rate amongst different types of traffic of the same user.

> 
> Regards,
> Sridhar