On 12.04.24 14:55, Johannes Berg wrote:
On Fri, 2024-04-12 at 14:06 +0200, Felix Fietkau wrote:+struct ieee80211_mesh_fast_tx_key { + u8 addr[ETH_ALEN] __aligned(2); + enum ieee80211_mesh_fast_tx_type type; +};Does it make sense to hash a bunch of zeroes there if the compiler allocates more than a single byte for "type"? It's uglier, but maybe makes more sense to not do that? There's also padding in there in that case.
Good point. I will change the type to u16 to make the size explicit and make the struct size a multiple of 4 for faster hashing.
@@ -646,12 +653,18 @@ void mesh_fast_tx_flush_addr(struct ieee80211_sub_if_data *sdata, const u8 *addr) { struct mesh_tx_cache *cache = &sdata->u.mesh.tx_cache; + struct ieee80211_mesh_fast_tx_key key = {}; struct ieee80211_mesh_fast_tx *entry; + int i;+ ether_addr_copy(key.addr, addr);spin_lock_bh(&cache->walk_lock); - entry = rhashtable_lookup_fast(&cache->rht, addr, fast_tx_rht_params); - if (entry) - mesh_fast_tx_entry_free(cache, entry); + for (i = MESH_FAST_TX_TYPE_LOCAL; i < MESH_FAST_TX_TYPE_FORWARDED; i++) {Seems that should be "i <= ...FORWARDED". Maybe better then to add a NUM_MESH_FAST_TX_TYPES or so to the enum and then use "i < NUM_MESH_FAST_TX_TYPES", so new additions won't have to update this, if they ever happen.
Will do, thanks. - Felix
