You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
fe7d965ea9
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> |
6 years ago | |
|---|---|---|
| .. | ||
| base-files | 6 years ago | |
| dts | 6 years ago | |
| files-4.14/drivers | 6 years ago | |
| image | 6 years ago | |
| mt76x8 | 6 years ago | |
| mt7620 | 6 years ago | |
| mt7621 | 6 years ago | |
| patches-4.14 | 6 years ago | |
| rt288x | 6 years ago | |
| rt305x | 6 years ago | |
| rt3883 | 6 years ago | |
| Makefile | 6 years ago | |
| modules.mk | 6 years ago | |