| Message ID | 1315500051-1122-1-git-send-email-lindner_marek@yahoo.de |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Thursday, September 08, 2011 18:40:44 Marek Lindner wrote: > here comes the next batch batch I'd like to get the pulled into > net-next-2.6/3.2. These patches mainly focus restructering the > routing code in order to allow the kernel module the handling > of the current routing algorithm and the upcoming one. > > To ensure a smooth transition and efficient testing later, we > decided to offer a choice of routing algorithm but have not > come to a final decision on how to design this choice yet. It > either will be a compile time option, a module parameter or a > runtime switch. Any suggestions / best practice tips ? > > Note: The new algorithm has been designed with backward > compatibility in mind (using TLVs). We are trying to address > the incompatibility issue you and others have pointed out. Forgot to mention: We are well aware of the difficulties after the kernel.org intrusion. If you can't pull our patches right now, feel free to do it whenever kernel.org is back online. Regards, Marek
From: Marek Lindner <lindner_marek@yahoo.de> Date: Thu, 8 Sep 2011 18:40:44 +0200 > The following changes since commit a943cac144e035c21d4f1b31b95f15b33c33a480: > > batman-adv: merge update_transtable() into tt related code (2011-08-22 15:16:22 +0200) > > are available in the git repository at: > git://git.open-mesh.org/linux-merge.git batman-adv/next Pulled, thanks Marek.
On Wednesday, September 21, 2011 21:26:16 David Miller wrote: > > are available in the git repository at: > > git://git.open-mesh.org/linux-merge.git batman-adv/next > > Pulled, thanks Marek. Pretty sure you are quite busy fighting with your backlog of patches but would you mind giving some advice on this: To ensure a smooth transition and efficient testing later, we decided to offer a choice of routing algorithm but have not come to a final decision on how to design this choice yet. It either will be a compile time option, a module parameter or a runtime switch. Any suggestions / best practice tips ? Regards, Marek
From: Marek Lindner <lindner_marek@yahoo.de> Date: Thu, 22 Sep 2011 01:39:26 +0200 > To ensure a smooth transition and efficient testing later, we > decided to offer a choice of routing algorithm but have not > come to a final decision on how to design this choice yet. It > either will be a compile time option, a module parameter or a > runtime switch. Any suggestions / best practice tips ? What do you mean by "algorithm"? Do you mean the implementation of the data-structure used to perform lookups? We had two data structures for our main routing table lookup implementation in ipv4, this was a mistake. We spent the next couple years maintaining two pieces of code, and finally investing lots of effort to eliminate the older code.
On Thursday, September 22, 2011 02:05:39 David Miller wrote: > From: Marek Lindner <lindner_marek@yahoo.de> > Date: Thu, 22 Sep 2011 01:39:26 +0200 > > > To ensure a smooth transition and efficient testing later, we > > decided to offer a choice of routing algorithm but have not > > come to a final decision on how to design this choice yet. It > > either will be a compile time option, a module parameter or a > > runtime switch. Any suggestions / best practice tips ? > > What do you mean by "algorithm"? Do you mean the implementation > of the data-structure used to perform lookups? > > We had two data structures for our main routing table lookup > implementation in ipv4, this was a mistake. We spent the next couple > years maintaining two pieces of code, and finally investing lots of > effort to eliminate the older code. No, the data structures for the routing lookups remain the same but there will be more than one way to fill them with data. You will only use one "filling algorithm" at a time, so you will need to select the one you want. Regards, Marek
From: Marek Lindner <lindner_marek@yahoo.de> Date: Thu, 22 Sep 2011 02:10:04 +0200 > No, the data structures for the routing lookups remain the same but there will > be more than one way to fill them with data. You will only use one "filling > algorithm" at a time, so you will need to select the one you want. Extend the userspace interface for adding route entries with a boolean flag. You're using netlink right? If so, this should be trivial by simply adding a flags attribute if you don't have one already.
On Thursday, September 22, 2011 02:11:53 David Miller wrote: > From: Marek Lindner <lindner_marek@yahoo.de> > Date: Thu, 22 Sep 2011 02:10:04 +0200 > > > No, the data structures for the routing lookups remain the same but there > > will be more than one way to fill them with data. You will only use one > > "filling algorithm" at a time, so you will need to select the one you > > want. > > Extend the userspace interface for adding route entries with a boolean > flag. You're using netlink right? If so, this should be trivial by > simply adding a flags attribute if you don't have one already. Not really. It's rather the tcp westwood vs tcp reno type of story. But I think we simply make this a runtime option to keep everybody happy. Thanks, Marek
Hi, here comes the next batch batch I'd like to get the pulled into net-next-2.6/3.2. These patches mainly focus restructering the routing code in order to allow the kernel module the handling of the current routing algorithm and the upcoming one. To ensure a smooth transition and efficient testing later, we decided to offer a choice of routing algorithm but have not come to a final decision on how to design this choice yet. It either will be a compile time option, a module parameter or a runtime switch. Any suggestions / best practice tips ? Note: The new algorithm has been designed with backward compatibility in mind (using TLVs). We are trying to address the incompatibility issue you and others have pointed out. Thanks, Marek The following changes since commit a943cac144e035c21d4f1b31b95f15b33c33a480: batman-adv: merge update_transtable() into tt related code (2011-08-22 15:16:22 +0200) are available in the git repository at: git://git.open-mesh.org/linux-merge.git batman-adv/next Joe Perches (1): batman-adv: Remove unnecessary OOM logging messages Marek Lindner (4): batman-adv: rename all instances of batman_packet to batman_ogm_packet batman-adv: agglomerate all batman iv ogm processing functions in a single file batman-adv: move routing packet initialization into corresponding file batman-adv: agglomerate all batman iv ogm sending functions in the batman iv file Simon Wunderlich (1): batman-adv: update README (date & ap isolation sysfs file) Sven Eckelmann (1): batman-adv: update internal version number Documentation/networking/batman-adv.txt | 8 +- net/batman-adv/Makefile | 2 +- net/batman-adv/aggregation.c | 293 ------- net/batman-adv/bat_iv_ogm.c | 1170 +++++++++++++++++++++++++++ net/batman-adv/{aggregation.h => bat_ogm.h} | 30 +- net/batman-adv/hard-interface.c | 54 +- net/batman-adv/main.c | 2 - net/batman-adv/main.h | 2 +- net/batman-adv/originator.c | 19 +- net/batman-adv/packet.h | 18 +- net/batman-adv/routing.c | 602 +------------- net/batman-adv/routing.h | 17 +- net/batman-adv/send.c | 305 +------- net/batman-adv/send.h | 9 +- net/batman-adv/soft-interface.c | 21 +- net/batman-adv/vis.c | 4 +- 16 files changed, 1281 insertions(+), 1275 deletions(-) delete mode 100644 net/batman-adv/aggregation.c create mode 100644 net/batman-adv/bat_iv_ogm.c rename net/batman-adv/{aggregation.h => bat_ogm.h} (50%)