Ya, there is a possibility that a mesh node is leaving its MBSS and joining another new MBSS just behind its original MBSS or vice versa. By the way, I just wondering whether it would be much faster in path resolving towards destination behind MBSS if we keep two tables separately. In typical case, assuming with one or two mesh gates providing the internet connectivity, we will have large mesh path table but smaller mpp path table. --- Chun-Yeow On Fri, May 23, 2014 at 3:31 AM, Henning Rogge <hrogge@xxxxxxxxx> wrote: > I first had planned to just throw them together... but it didn't > worked out and I assume that there is some time where you can have two > entries with the same destination, one of them a normal path > (request), the other one the mapped destination. > > Henning Rogge > > On Thu, May 22, 2014 at 9:27 PM, Bob Copeland <me@xxxxxxxxxxxxxxx> wrote: >> On Thu, May 22, 2014 at 05:06:21PM +0200, Henning Rogge wrote: >>> From: Henning Rogge <hrogge@xxxxxxxxx> >>> >>> This patch is a preparation for exporting the MPP data of the 802.11s >>> implementation via netlink to userspace. It unifies the content of the >>> mesh_paths and mpp_paths tables in mesh_pathtbl.c without changing >>> the behavior of the code. >>> >>> Signed-off-by: Henning Rogge <hrogge@xxxxxxxxx> >> >> I think I fall on the side of your earlier assessment that they >> hold different things and should stay in different tables, even though >> there are 200 lines of identical code here. Maybe some bits could >> be shared without sharing the data and changing the API? >> >>> -static struct mesh_path *mpath_lookup(struct mesh_table *tbl, const u8 *dst, >>> - struct ieee80211_sub_if_data *sdata) >>> +/** >>> + * mesh_path_lookup - look up a path in the mesh path table >>> + * @sdata: local subif >>> + * @dst: hardware address (ETH_ALEN length) of destination >>> + * @is_proxied: true to lookup mpp entries, false otherwise >> >> Also, I don't like adding random boolean variables to water down what >> this function does. It means when looking at the caller you have to go >> back to the definition to see just what is going on here. >> >> We do mpp_path_lookup exactly twice so it seems weird to have to >> change all of the mpath_lookup callers too. >> >> -- >> Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
