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 |
Return-Path: <ordex@autistici.org> Received: from confino.investici.org (investici.nine.ch [217.150.252.179]) by open-mesh.org (Postfix) with ESMTPS id 616E7600759 for <b.a.t.m.a.n@lists.open-mesh.org>; Sun, 29 Apr 2012 10:56:46 +0200 (CEST) Authentication-Results: open-mesh.org; dkim=pass (1024-bit key) header.i=@autistici.org; dkim-adsp=pass Received: from [217.150.252.179] (confino [217.150.252.179]) (Authenticated sender: ordex@autistici.org) by localhost (Postfix) with ESMTPSA id 15552C86B4; Sun, 29 Apr 2012 08:56:43 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 confino.investici.org 15552C86B4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=autistici.org; s=stigmate; t=1335689805; bh=Rgx7aWYTbOPsGjD4kqyk5g8tTR3Z6Q//JOiaunZpCaI=; h=From:To:Cc:Subject:Date:Message-Id; b=a6Yrz3RM/Y2SpBk6qIsjiwLih1VydHcirrXU/IY38MEijEbctL8ABnc+/7sWeKwDC C4JA9jwI/C8ePQKMMVt5loMD9B17AWClIWRah7M2XkfkqIYD6SXGgDszPofrfpI7xf NxG6ajrO4iaPjMCcPYlopCzuA2FEsSHJSVC5RrbY= From: Antonio Quartulli <ordex@autistici.org> To: davem@davemloft.net Date: Sun, 29 Apr 2012 10:57:32 +0200 Message-Id: <1335689867-8017-1-git-send-email-ordex@autistici.org> X-Mailer: git-send-email 1.7.9.4 Cc: netdev@vger.kernel.org, b.a.t.m.a.n@lists.open-mesh.org Subject: [B.A.T.M.A.N.] pull request: batman-adv 2012-04-29 X-BeenThere: b.a.t.m.a.n@lists.open-mesh.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: The list for a Better Approach To Mobile Ad-hoc Networking <b.a.t.m.a.n@lists.open-mesh.org> List-Id: The list for a Better Approach To Mobile Ad-hoc Networking <b.a.t.m.a.n.lists.open-mesh.org> List-Unsubscribe: <https://lists.open-mesh.org/mm/options/b.a.t.m.a.n>, <mailto:b.a.t.m.a.n-request@lists.open-mesh.org?subject=unsubscribe> List-Archive: <http://lists.open-mesh.org/pipermail/b.a.t.m.a.n> List-Post: <mailto:b.a.t.m.a.n@lists.open-mesh.org> List-Help: <mailto:b.a.t.m.a.n-request@lists.open-mesh.org?subject=help> List-Subscribe: <https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n>, <mailto:b.a.t.m.a.n-request@lists.open-mesh.org?subject=subscribe> X-List-Received-Date: Sun, 29 Apr 2012 08:56:46 -0000 |
Pull-request
git://git.open-mesh.org/linux-merge.git tags/batman-adv-for-davemMessage
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
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.
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,
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.
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