Re: [B.A.T.M.A.N.] [PATCH v2] batman-adv: B.A.T.M.A.N V - make sure iface is reactivated upon NETDEV_UP event

[Antonio Quartulli <a@unstable.cc>]

[-- Attachment #1: Type: text/plain, Size: 3559 bytes --]

Hi all,

it looks like this patch was not interpreted the right way, probably because of
a lack of communication between me and other maintainers or probably because
too much laziness here and there...

Explanation follows below.

On Thu, Apr 14, 2016 at 09:37:05AM +0800, Antonio Quartulli wrote:
> At the moment there is no explicit reactivation of an hard-interface
> upon NETDEV_UP event. In case of B.A.T.M.A.N. IV the interface is
> reactivated as soon as the next OGM is scheduled for sending, but this
> mechanism does not work with B.A.T.M.A.N. V. The latter does not rely
> on the same scheduling mechanism as its predecessor and for this reason
> the hard-interface remains deactivated forever after being brought down
> once.
> 
> This patch fixes the reactivation mechanism by adding a new routing API
> which explicitly allows each algorithm to perform any needed operation
> upon interface re-activation.
> 

Right now we have a piece of infrastructure used by B.A.T.M.A.N IV that
consists in calling batadv_send_outstanding_bat_ogm_packet() periodically,
thus generating the following flow:

-> batadv_send_outstanding_bat_ogm_packet()
	-> bat_algo_ops->bat_ogm_emit()
	-> batadv_schedule_bat_ogm()
		bat_algo_ops->bat_ogm_schedule()

by scrolling over the mentioned functions I'd argue that such flow is rather
tight to the B.A.T.M.A.N. IV algorithm and, although there has been a lot of
effort in making such routines generic (that's why we have API calls in the
middle), such infrastructure is very difficult to be used within B.A.T.M.A.N. V.


On top of that, the logic implemented within this piece of infrastructure
aims to achieve two goals:
1) schedule OGM sending
2) send out aggregated OGMs


The consequence of this was that B.A.T.M.A.N. V has its own implementation for
sending OGMs and lacks support for OGMs aggregation (and queue limitation).


This said, the bug that this patch is trying to fix came up exactly from the
new implementation of point 1) in B.A.T.M.A.N. V.

One could argue that in order to fix this misbehaviour it would be better to
stick to using the already implemented infrastructure, but unfortunately, as
I explained above, this is not possible and therefore this patch can't go
in that direction.


This patch, instead, tries to make the first step towards changing the
infrastructure in a way where B.A.T.M.A.N. IV will adapt to its successor
and not viceversa.


The idea is to have a new API call to be invoked everytime a hard interface is
brought up so that each algorithm can take its own decision about what to do
next.

At this point, the potential next steps that I see are:

1) convert batadv_send_outstanding_bat_ogm_packet() and invoked routines to
B.A.T.M.A.N. IV private code (remove bat_algo_ops->ogm_schedule/ogm_emit())

2) have B.A.T.M.A.N. IV use the new iface_activate() API introduced by this
patch (if needed)

3) make the aggregation code generic so that other protocols can enjoy the same
benefit without having to re-use exactly the same logic

4) implement aggregation in B.A.T.M.A.N. V with queue limitation

I tried to include point 1) in this patch so that it could look more "sane" from
an architectural point of view, but given that this change is a fix (and thus
targets the net tree) I decided to squeeze it and include only what was necessary
to fix the "interface-enabling" issue.


I hope this helps understanding the ratio behind this patch :)

Cheers,


-- 
Antonio Quartulli

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]