Re: [B.A.T.M.A.N.] Basic Multicast Optimizations

["Linus Lüssing" <linus.luessing@web.de>]

Hrm, forgot to add the v3 an the patch naming. And forgot to
actually add
-static inline batadv_forw_mode
+static inline enum batadv_forw_mode
to the according commit.

Will send a v4 in a sec.

Cheers, Linus

On Mon, Jun 10, 2013 at 08:28:18AM +0200, Linus Lüssing wrote:
> This is the third revision of the basic multicast optimization patches.
> It includes one functional and some compat fixes, and some style improvements,
> thanks to Simons feedback:
> 
> PATCHv3 1/3:
> * the pmc_rcu functions got removed - they weren't actually used in the
>   submitted revision - so there's no more patch for net to export
>   for_each_pmc_rcu() needed anymore. Should also fix Simon's compat error.
> * Compat code for netdev_for_each_mc_addr() added.
>   (I needed to introduce a batadv_hw_addr because I wasn't able to achieve
>   backwards compatibility with a netdev_hw_addr - my "official reasoning" will
>   be that netdev_hw_addr is unnecessarily bloated, struct batadv_hw_addr
>   has just the right size to do the job)
> * Compat fix for IFF_BRIDGE_PORT
> * Removed primary_if->soft_iface in batadv_mcast_mla_tt_update() as we
>   can always use bat_priv->soft_iface instead.
> 
> PATCHv3 2/3
> * Renamed num_non_aware to a more specific num_no_mla - because we will need
>   things like a num_no_tracker for instance with the multicast tracker feature
>   in the future.
> * Fixed removal of orig_node's without BATADV_MCAST_LISTENER_ANNOUNCEMENT
>   flag, update num_no_mla properly now.
> 
> PATCHv3 3/3
> * Renamed batadv_mcast_flood() to batadv_mcast_forw_mode() because it does not
>   only show whether to flood or not (=drop), but also whether to forward via
>   unicast. In the future with the multicast tracker feature a fourth return value
>   is going to be added, making the name "batadv_mcast_flood()" even less fitting.
> * Simon's style suggestions for batadv_mcast_forw_mode() and
>   batadv_interface_tx().
> * batadv_mcast_forw_mode() now returns an enum (thanks to Marek and Antonio for
>   the suggestion).
> 
> I did not change:
> > I don't quite understand why you return -1, maybe the packet could still
> > be forwarded even if it could not be pulled?
> 
> Because if it returns -1 then something is wrong, for instance we could be
> out of memory. If we are out of memory then we probably won't be able to
> forward any packet. Also we shouldn't allocate any more memory for one thing
> but I think it is also better to drop/free packets to save some memory
> to increase the possibility of the system to recover without crashing.
> 
> Cheers, Linus
>