The statistics of "total" packets one user can enqueue can be easily
calculated by the application meaning there is no need of any
implementation support. This can be simply calculated over a counter
in the application which increments when packets are transmitted for a
single user.
The Threshold limit which denotes the "active" packets in the TM
system requires implementation support since the number of packets in
the queue depends also on the rate at which the packets are depleted
from the queue which could vary based on the total load in the TM
system i.e if there is additional bandwidth available a single queue
could transmit packets at the Peak Information Rate (PIR) above the
Committed Information Rate (CIR). Hence this threshold limit is of
importance simply coz this is internally handled by the
implementation.
Regards,
Bala
On 4 November 2016 at 07:50, Forrest Shi <forrest....@linaro.org> wrote:
> Hi Bala,
>
> This is what the current TM does.
>
> The max_packets is "active" packets in the TM queue, but not the "total"
> packets of one user can enqueue.
> "max active packets" in a TM queue is implementation things and the user may
> not care about it.
>
> What the use cares is how many bytes(max_bytes/packets) and how
> fast(commit_bps/peak_bps) he can transmit.
> That's should be a service committed to a user.
>
> In the traffic_mgmt example, each user is allocated one TM queue and
> associated one COS param.
> But it cannot restrict the max_bytes what a user can send into TM.
>
> Thanks,
> Forrest
>
> On 3 November 2016 at 20:44, Bala Manoharan <bala.manoha...@linaro.org>
> wrote:
>>
>> The threshold parameters are added to the tm queue mainly for tail
>> drop and WRED supported by some TM systems. It denotes the number of
>> active packets that can enqueued in the queue at any given instant If
>> threshold is required per user then the application can create a
>> single TM queue per user and attach threshold profile accordingly.
>>
>> Hope this answers the question.
>>
>> Regards,
>> Bala
>>
>>
>> On 2 November 2016 at 18:12, Bill Fischofer <bill.fischo...@linaro.org>
>> wrote:
>> > This question properly belongs on the ODP mailing list (+cc)
>> >
>> > On Wed, Nov 2, 2016 at 4:12 AM, Forrest Shi <forrest....@linaro.org>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> I can see some COS profile param like below in the example:
>> >>
>> >> .threshold_params = {
>> >> .max_pkts = 10000, .enable_max_pkts = TRUE,
>> >> .max_bytes = 1000000, .enable_max_bytes = TRUE
>> >> },
>> >>
>> >> The meaning of param max_pkts looks like the max length of the
>> >> tm_queue,
>> >> not the limit of the user can get into this tm system.
>> >> When the packet is processed and out of tm queue, the user can enque
>> >> packet again.
>> >>
>> >> I think the limit of user is more meaningful than of queue. Class of
>> >> service should be user oriented, not implementation oriented.
>> >>
>> >> How do you say?
>> >>
>> >> Thanks,
>> >> Forrest
>> >
>> >
>
>
