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,