hanlded the qos reload without statistics reset.
shaping , classification or policer change and qos reload should
not cause queue reset in driver that was causing statistics of that queue
reset to 0. qos reload if trigerred with queue specific config change,in
that case only statistics will reset tot 0.
Update q setup that allows better coverage of q setup specially in
mixed mode scheduling.
Also remove dead code related to stats since that is already taken
care of by qosmngr daemon now.
And lastly, simplify the logic to calculate q precedence.
l3 iptables rule with ethx was not matching this was causing incorrect classification to wrong queue.
ebtables rule correction done with ethertype,protocol and port to classify packet for destination queue.
When using the runner accelerator we need to check how to
map between ethernet interfaces (i.e eth0) and the internal
names used by the runner (i.e. port/index=lan2). Depending on
the hardware the mapping is not always 1:1 as assumed earlier.
This commit also fixes a minor bug with resetting traffic
shaping for the archer accelerator.
In 5.04, broadcom seems to have removed the support for skbvlan extension
from the kernel, although its presence still in the userspace application
is confusing, ideally, it should be removed from the userspace application
as well. Instead of skbvlan, the vlan extension is used for configuring the
vlan qos.
Hence, the qosmngr is updated to use vlan extension instead of skbvlan.
We need to use 'brcm_fw_tool' instead of /proc/cpuinfo
to check the hardware platform. The /proc/cpuinfo API
is not stable. It only works as expected for BCM96846.
Although no devel panther or FT is not supported as yet but that
might be the case in near future so keeping it same here plus,
bs alias should be replaced with proper bdmf_shell command anyway
so this is done here as well. No regression, no harm.
Precedence value update to map with tr181 in default config,
now goes from 1 to 8, 8 meaning queue has lowest priority and 1
meaning that the queue has highest priority.
The broadcom script takes care of reversing this and mapping this
to 0 to 7 before configuring actual queues.
latest patch to resolve precedence issue causes regression.
Bug: queues for any port not configured at boot
fix: create the folders which store queue precedence
The default value of burst size in config is set to -1 which is one
part of the problem. The other part of the problem is that the check
in tr181 is not good enough to disallow negative values. That will
be fixed in a seprate patch.
Support for traffic policing added to allow configuration of
ingress rate limiting.
Test (on panther):
- ingress rate limiting on per lan port basis for US traffic.
- ingress rate limiting on wan port for DS traffic.
- when ingress rate limiting is applied on traffic in one direction,
then traffic in other direction remains un-affected, that is, if
ingress rate limiting is applied in DS, then US traffic on the port
is unaffected
Note: Autotest are ready and will be merge for now with the tag not_ready.
Once devel is ready or if we decide to merge this to release-5.3, the same
can be tagged ready and executed as part of nightly suite.
A couple of bugs detected during autotest are resolved, details as
follows:
1. Assumes precedence is qid, which is incorrect, does not allow config
of WRR queues which require precedence to be 0 for all queues.
As a consequence, the logic to configure and read queue stats had to be
updated, no change in behaviour though, that is, no regression.
As a neat outcome of this change, mixed mode scheduling can now be configured
on upstream queues, for which autotests are also being added now.
To verify that no regression is caused by this change, QoS L2 and L3 suite
were executed on both platform and were found to pass, hence, this change
is ready to submit.
After every QoS config, it is required that flows are flushed. Instead
of doing this as an extrenal step, its good to integrate this in the
qosmngr itself so that each config is atomically competent enough to
take effect with any further steps needed manually.
Bug identified: if a shaper config is removed from the UCI file,
it still remains active on the port since the logic to clean shaper
config is missing in the qosmngr.
Resolution: clean shapers on each reload so that fresh config takes
place as per the UCI file.
