diff options
author | HsiuWen Yen <y.hsiuwen@gmail.com> | 2019-01-23 12:14:19 +0800 |
---|---|---|
committer | John Crispin <john@phrozen.org> | 2019-01-23 09:27:30 +0100 |
commit | fe7d965ea95e78905328fe5425c8e90e3bf11e58 (patch) | |
tree | deb2c34c3fb69412f38635919282f3325cadb86a /target/linux/brcm63xx/Makefile | |
parent | 45a2771953fb351879c332105c8d270c6daed0a7 (diff) | |
download | upstream-fe7d965ea95e78905328fe5425c8e90e3bf11e58.tar.gz upstream-fe7d965ea95e78905328fe5425c8e90e3bf11e58.tar.bz2 upstream-fe7d965ea95e78905328fe5425c8e90e3bf11e58.zip |
ramips: fix two-way hash and auto ageout on MT7621
Current code directly writes the FOE entry to hash_val+1 position
when hash collision occurs. However, it is found that this behavior
will cause the cache and the hardware FOE table to be inconsistent.
For example, there are three flows, and their hashed values are all
equal to 100. The first flow is written to the position of 100. The
second flow is written to the position of 100+1. Then, the logic of
the current code will also write the third flow to 100+1.
At this time, the cache has flow 1 and 2; and the hardware FOE table
has flow 1 and 3, where these two parts store different contents.
So it is necessary to check whether the hash_val+1 is also occupied
before writing. If hash_val+1 is also occupied, we won’t bind th
third flow to the FOE table.
Addition to that, we also cancel the processing of foe_entry removal
because the hardware has auto age-out ability. The hardware will
periodically iterate through the FOE table to find out the time-out
entry and set it as INVALID.
Signed-off-by: HsiuWen Yen <y.hsiuwen@gmail.com>
Diffstat (limited to 'target/linux/brcm63xx/Makefile')
0 files changed, 0 insertions, 0 deletions