[Bug 892] librte.sched scheduler can undershoot target rate

[bugzilla at dpdk.org]

https://bugs.dpdk.org/show_bug.cgi?id=892

            Bug ID: 892
           Summary: librte.sched scheduler can undershoot target rate
           Product: DPDK
           Version: 21.11
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: core
          Assignee: dev at dpdk.org
          Reporter: mike.evans at microsoft.com
  Target Milestone: ---

As per the comments, we found that the scheduler can significantly undershoot
the target rate, particularly if tc_period is set to a low value, the packet
size is large and the bitrate is fairly low.  As examples, testing with
tc_period = 10ms, packet size of 1538 bytes and both pipe and TC bitrates set
to 1875000 bytes/s (1.5Mbps) we saw the target rate undershot by ~20%.

The problem appears to be in grinder_credits_update, where TC credits are
refreshed.  Because the update simply sets the tc_credits to
tc_credits_per_period, any residual credits are lost.  In our test scenario,
tc_period is 10ms, and so tc_credits_per_period is 1875.  This means that in
each tc_period the scheduler only sends one 1538 byte packet and the residual
337 bytes of credit are lost on the next refresh.  This means we send 100
packets per second, whereas we would expect either 121 or 122 packets per
second.

It's not clear if the behaviour is intentional and the choice of 10ms for
tc_credit is a poor one.  It seems sensible not to let TC credit grow unbounded
when it is not being used, but isn't that the purpose of the tb_size parameter?
 If this is intentional then it means shaping at the TC is very different to
shaping at the pipe or subport levels.

-- 
You are receiving this mail because:
You are the assignee for the bug.