pull request: batman-adv 2011-09-08

  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%)
  

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