pull request: batman-adv 2012-11-03

  Hello David,

here you have another patchset with two new features intended for
net-next/linux-3.8.

Patch 1/9 adds the new UNICAST_4ADDR packet type which contains both the source
and the destination node addresses (unlike the classic UNICAST which contains
the destination only) and can encapsulate different packet subtypes.

Then all the remaining patches introduce the new Distributed ARP Table (DAT)
component. It is the first user of the new packet type introduced by 1/9.

DAT is the results of Antonio Quartulli's Google Summer Of Code 2011.
It was already sent to netdev once in the past, but got rejected because of its
dependency on the ARP/neigh layer internals. In this new version a batman-adv
private ARP storage has been implemented, so dropping any possible relationship
with the inner neigh code.

Please, let me know if there is any problem.

Thank you very much,
		Antonio



The following changes since commit b77bc2069d1e437d5a1a71bb5cfcf4556ee40015:

  ppp: make ppp_get_stats64 static (2012-11-01 12:38:31 -0400)

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 f113f61fd0af6dfd08f8110236cd47c410b36711:

  batman-adv: Add get_ethtool_stats() support for DAT (2012-11-02 21:50:15 +0100)

----------------------------------------------------------------
Included changes:
- new packet type called UNICAST_4ADDR: in this packet it is possible to find
  both source and destination node (in the classic UNICAST header only the
  destination field exists).
- a new feature: Distributed ARP Table (D.A.T.). It aims to reduce ARP lookups
  latency by means of a simil-DHT approach.

----------------------------------------------------------------
Antonio Quartulli (8):
      batman-adv: add UNICAST_4ADDR packet type
      batman-adv: Distributed ARP Table - add a new debug log level
      batman-adv: Distributed ARP Table - create DHT helper functions
      batman-adv: Distributed ARP Table - implement local storage
      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 - add compile option
      batman-adv: Distributed ARP Table - add runtime switch

Martin Hundebøll (1):
      batman-adv: Add get_ethtool_stats() support for DAT

 Documentation/networking/batman-adv.txt |    3 +-
 net/batman-adv/Kconfig                  |   10 +
 net/batman-adv/Makefile                 |    1 +
 net/batman-adv/debugfs.c                |   20 +
 net/batman-adv/distributed-arp-table.c  | 1066 +++++++++++++++++++++++++++++++
 net/batman-adv/distributed-arp-table.h  |  167 +++++
 net/batman-adv/hard-interface.c         |    3 +
 net/batman-adv/main.c                   |    9 +
 net/batman-adv/main.h                   |   13 +-
 net/batman-adv/originator.c             |    2 +
 net/batman-adv/packet.h                 |   43 +-
 net/batman-adv/routing.c                |   41 +-
 net/batman-adv/send.c                   |    4 +
 net/batman-adv/soft-interface.c         |   28 +-
 net/batman-adv/sysfs.c                  |    7 +
 net/batman-adv/types.h                  |   73 +++
 net/batman-adv/unicast.c                |  134 +++-
 net/batman-adv/unicast.h                |   36 +-
 18 files changed, 1631 insertions(+), 29 deletions(-)
 create mode 100644 net/batman-adv/distributed-arp-table.c
 create mode 100644 net/batman-adv/distributed-arp-table.h
  

On Sunday 04 November 2012 11:29:29 Sven Eckelmann wrote:
> On Saturday 03 November 2012 15:22:26 David Miller wrote:
> [...]
> 
> > Your packet layouts are very poorly designed and I want you to stop
> > and think seriously about things before extending things further.
> 
> You are right about the packet design/layout. But I also have some problems
> with the following statement. Maybe you can help me to resolve it.
> 
> > All of this __packed stuff is a serious problem.
> > 
> > It means that on RISC system, fields such as your 32-bit sequence
> > number, will be read and written using byte loads and stores.
> > 
> > This is terrible.
> > 
> > Instead, design the structures so that they are full filled out to
> > at least 4 byte boundaries, so that they and the contents after
> > them, are 4 byte aligned too.
> > 
> > Then you won't need to mark all of your packet header structs
> > with __packed, and therefore the compiler can use full 32-bit
> > loads and stores to access 32-bit fields.
> 
> Ok, lets assume batman-adv has everything 4 byte aligned and we are running
> on a machine without unaligned r/w access. The machine may issues bus
> errors and so on.
> 
> Now also assume following really unusual situation: We get our data from a
> ethernet driver and the skb stores the ethernet header. The start of the
> ethernet header is perfectly aligned (4 or even 16 byte boundary aligned).
> The the header is 14/18 byte long (6 byte src, 6 byte dst, 2 byte ethertype
> and maybe 4 byte vlan). Now the payload starts only on a 2 byte boundary ->
> it is never 4 byte boundary aligned. A 32 bit read now causes different
> variations of problems (reminder: bus error).
> 
> This brings me to the question: Why should the "32 bit align everything
> relative to the start of the struct" approach help to resolve the situation
> for the access of 32 bit data structure members? May I am missing some
> information?

To push this question in a direction: May I assume that the driver always 
ensures that the ethernet header is 4 byte boundary - NET_IP_ALIGN (2) 
aligned?

When yes, this would result in a slight variations of your suggestion: 
unicast/bcast headers have to end at 4 bytes boundary + 2 bytes. The reason is 
easy to explain. batman-adv unicast/bcast headers are used to encapsulate the 
important parts of an ethernet frame:

Ethernet Header for P2P | batman-adv header stuff | ethernet header | payload.

Would you aggree?

Thanks,
	Sven
  

From: Sven Eckelmann <sven@narfation.org>
Date: Sun, 04 Nov 2012 12:20:13 +0100

> To push this question in a direction: May I assume that the driver always 
> ensures that the ethernet header is 4 byte boundary - NET_IP_ALIGN (2) 
> aligned?

Yes.

> When yes, this would result in a slight variations of your suggestion: 
> unicast/bcast headers have to end at 4 bytes boundary + 2 bytes. The reason is 
> easy to explain. batman-adv unicast/bcast headers are used to encapsulate the 
> important parts of an ethernet frame:
> 
> Ethernet Header for P2P | batman-adv header stuff | ethernet header | payload.
> 
> Would you aggree?

Then you can get rid of the packed crap.