Hi Bala,
OK, thanks for your clarification. I will add the user limit in the example
instead of TM library.
Thanks,
Forrest
On 4 November 2016 at 11:26, Bala Manoharan <bala.manoha...@linaro.org>
wrote:
> 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
> >> >
> >> >
> >
> >
>
