mbox

pull request: batman-adv 2012-04-29

Message ID 1335689867-8017-1-git-send-email-ordex@autistici.org (mailing list archive)
State Not Applicable, archived
Headers

Pull-request

git://git.open-mesh.org/linux-merge.git tags/batman-adv-for-davem

Message

Antonio Quartulli April 29, 2012, 8:57 a.m. UTC
  Hello David,

this is the new version of my last pull request (issued on 2012-04-25).
This patchset is intended for net-next/linux-3.5.

Since last series I only removed the biggest_unsigned_int() macro.

Let me know if there is any other problem.

Thank you,
	Antonio

===============================================================

The following changes since commit 7a2a66a0ac1cf93d30869c4ecbfc71a2fda19397:

  Add linux-next specific files for 20120423 (2012-04-23 16:58:43 +1000)

are available in the git repository at:

  git://git.open-mesh.org/linux-merge.git tags/batman-adv-for-davem

for you to fetch changes up to 3ad345e2521ef41500cc0890a717656b975c4321:

  batman-adv: split neigh_new function into generic and batman iv specific parts (2012-04-29 10:50:10 +0200)

----------------------------------------------------------------
Included changes:

* a new feature has been introduced: D.A.T. (Distributed ARP Table). It is a
  mechanism based on DHT theory that creates a distributed (mesh network wide)
  ARP cache in order to speed up ARP resolutions in sparse wireless mesh
  networks.
* in order to satisfy DAT requirements a new unicast packet type, namely
  UNICAST_4ADDR, has been introduced. Backward compatibility has been kept: not
  updated nodes will simply drop the packet and ignore DAT mechanism.
* minor fixes and cleanups
* minor routing protocol API cleanups

----------------------------------------------------------------
Antonio Quartulli (9):
      batman-adv: add UNICAST_4ADDR packet type
      batman-adv: add a new log level for DAT debugging
      batman-adv: add biggest_unsigned_int(x) macro
      batman-adv: Distributed ARP Table - create DHT helper functions
      batman-adv: Distributed ARP Table - add ARP parsing functions
      batman-adv: Distributed ARP Table - add snooping functions for ARP messages
      batman-adv: Distributed ARP Table - increase default soft_iface ARP table timeout
      batman-adv: Distributed ARP Table - add compile option
      batman-adv: fix wrong dhcp option list browsing

Marek Lindner (6):
      batman-adv: introduce is_single_hop_neigh variable to increase readability
      batman-adv: introduce packet type handler array for incoming packets
      batman-adv: register batman ogm receive function during protocol init
      batman-adv: rename last_valid to last_seen
      batman-adv: replace HZ calculations with jiffies_to_msecs()
      batman-adv: split neigh_new function into generic and batman iv specific parts

 Documentation/networking/batman-adv.txt |    3 +-
 net/batman-adv/Kconfig                  |   10 +
 net/batman-adv/Makefile                 |    1 +
 net/batman-adv/bat_debugfs.c            |    4 +-
 net/batman-adv/bat_iv_ogm.c             |   95 +++--
 net/batman-adv/bat_sysfs.c              |    2 +-
 net/batman-adv/distributed-arp-table.c  |  605 +++++++++++++++++++++++++++++++
 net/batman-adv/distributed-arp-table.h  |  140 +++++++
 net/batman-adv/gateway_client.c         |    6 +-
 net/batman-adv/hard-interface.c         |  116 +-----
 net/batman-adv/main.c                   |  124 ++++++-
 net/batman-adv/main.h                   |   21 +-
 net/batman-adv/originator.c             |   52 +--
 net/batman-adv/originator.h             |    6 +-
 net/batman-adv/packet.h                 |   30 +-
 net/batman-adv/routing.c                |   30 +-
 net/batman-adv/routing.h                |    4 +-
 net/batman-adv/send.c                   |    6 +-
 net/batman-adv/soft-interface.c         |   17 +-
 net/batman-adv/types.h                  |   33 +-
 net/batman-adv/unicast.c                |  102 +++++-
 net/batman-adv/unicast.h                |   21 +-
 22 files changed, 1202 insertions(+), 226 deletions(-)
 create mode 100644 net/batman-adv/distributed-arp-table.c
 create mode 100644 net/batman-adv/distributed-arp-table.h
  

Comments

David Miller April 30, 2012, 5:05 p.m. UTC | #1
From: Antonio Quartulli <ordex@autistici.org>
Date: Sun, 29 Apr 2012 10:57:38 +0200

> In case of an ARP message going in or out the soft_iface, it is intercepted and
> a special action is performed. In particular the DHT helper functions previously
> implemented are used to store all the ARP entries belonging to the network in
> order to provide a fast and unicast lookup instead of the classic broadcast
> flooding mechanism.
> Each node stores the entries it is responsible for (following the DHT rules) in
> its soft_iface ARP table. This makes it possible to reuse the kernel data
> structures and functions for ARP management.
> 
> Signed-off-by: Antonio Quartulli <ordex@autistici.org>

Sorry, I'm not letting subsystems outside of net/ipv4/arp.c and related
code make changes to the ARP table.

I plan to make major surgery to the way neighbour table entries are
handled and therefore the less people who get their grubby paws
directly in there, the better.

Find a way to propagate the ARP packet into the properl ARP receive
path to cause the state update to occur, I'm not letting you trigger
it by hand in the batman-adv code.

Sorry.
  
Antonio Quartulli April 30, 2012, 10:22 p.m. UTC | #2
On Mon, Apr 30, 2012 at 01:05:55 -0400, David Miller wrote:
> From: Antonio Quartulli <ordex@autistici.org>
> Date: Sun, 29 Apr 2012 10:57:38 +0200
> 
> > In case of an ARP message going in or out the soft_iface, it is intercepted and
> > a special action is performed. In particular the DHT helper functions previously
> > implemented are used to store all the ARP entries belonging to the network in
> > order to provide a fast and unicast lookup instead of the classic broadcast
> > flooding mechanism.
> > Each node stores the entries it is responsible for (following the DHT rules) in
> > its soft_iface ARP table. This makes it possible to reuse the kernel data
> > structures and functions for ARP management.
> > 
> > Signed-off-by: Antonio Quartulli <ordex@autistici.org>
> 
> Sorry, I'm not letting subsystems outside of net/ipv4/arp.c and related
> code make changes to the ARP table.
> 
> I plan to make major surgery to the way neighbour table entries are
> handled and therefore the less people who get their grubby paws
> directly in there, the better.
> 
> Find a way to propagate the ARP packet into the properl ARP receive
> path to cause the state update to occur, I'm not letting you trigger
> it by hand in the batman-adv code.
> 
> Sorry.


Hello David,

I perfectly understand. We did it that way because we thought that we could use
the exported API.

At this point, in my honest opinion, it is better to postpone this new feature
for a later pull request.

However this patch also contains a procedure which queries the neigh table in
order to understand whether a given host is known or not.
Would it be possible to do that in another way (Without manually touching the
table)?

Instead, in the next patch (patch 06/15) batman-adv manually increase the neigh
timeouts. Do you think we should avoid doing that as well? If we are allowed to
do that, how can we perform the same operation in a cleaner way?

Last question: why can't other modules use exported functions? Are you going to
change them as well?


Thank you very much,
  
David Miller May 1, 2012, 12:59 a.m. UTC | #3
From: Antonio Quartulli <ordex@autistici.org>
Date: Tue, 1 May 2012 00:22:30 +0200

> However this patch also contains a procedure which queries the neigh table in
> order to understand whether a given host is known or not.
> Would it be possible to do that in another way (Without manually touching the
> table)?
> 
> Instead, in the next patch (patch 06/15) batman-adv manually increase the neigh
> timeouts. Do you think we should avoid doing that as well? If we are allowed to
> do that, how can we perform the same operation in a cleaner way?
> 
> Last question: why can't other modules use exported functions? Are you going to
> change them as well?

I really don't have time to discuss your neigh issues right now as I'm
busy speaking at conferences and dealing with the backlog of other
patches.

You'll need to find someone else to discuss it with you, sorry.
  
Marek Lindner May 12, 2012, 8:26 a.m. UTC | #4
David,

On Tuesday, May 01, 2012 08:59:04 David Miller wrote:
> From: Antonio Quartulli <ordex@autistici.org>
> Date: Tue, 1 May 2012 00:22:30 +0200
> 
> > However this patch also contains a procedure which queries the neigh
> > table in order to understand whether a given host is known or not.
> > Would it be possible to do that in another way (Without manually touching
> > the table)?
> > 
> > Instead, in the next patch (patch 06/15) batman-adv manually increase the
> > neigh timeouts. Do you think we should avoid doing that as well? If we
> > are allowed to do that, how can we perform the same operation in a
> > cleaner way?
> > 
> > Last question: why can't other modules use exported functions? Are you
> > going to change them as well?
> 
> I really don't have time to discuss your neigh issues right now as I'm
> busy speaking at conferences and dealing with the backlog of other
> patches.
> 
> You'll need to find someone else to discuss it with you, sorry.

I hope now is a good moment to bring the questions back onto the table. We 
still are not sure how to proceed because we have no clear picture of what is 
going to come and how the exported functions are supposed to be used.

David, if you don't have the time to discuss the ARP handling with us could 
you name someone who knows your plans and the code equally well ? So far, 
nobody has stepped up.

Thanks,
Marek