linux-toradex.git/drivers/net/macvlan.c, branch v2.6.34

macvlan: allow multiple driver backends

2010-02-04T04:20:33+00:00

This makes it possible to hook into the macvlan driver
from another kernel module. In particular, the goal is
to extend it with the macvtap backend that provides
a tun/tap compatible interface directly on the macvlan
device.

Signed-off-by: Arnd Bergmann 
Signed-off-by: David S. Miller

net: maintain namespace isolation between vlan and real device

2010-02-04T04:20:32+00:00

In the vlan and macvlan drivers, the start_xmit function forwards
data to the dev_queue_xmit function for another device, which may
potentially belong to a different namespace.

To make sure that classification stays within a single namespace,
this resets the potentially critical fields.

Signed-off-by: Arnd Bergmann 
Signed-off-by: David S. Miller

macvlan: add GRO bit to features mask

2010-01-16T09:05:38+00:00

Allow macvlan devices to support GRO.

Signed-off-by: Patrick Mullaney 
Acked-by: Patrick McHardy 
Signed-off-by: David S. Miller

netdevice: provide common routine for macvlan and vlan operstate management

2009-12-03T23:59:22+00:00

Provide common routine for the transition of operational state for a leaf
device during a root device transition.

Signed-off-by: Patrick Mullaney 
Acked-by: Arnd Bergmann 
Acked-by: Patrick McHardy 
Signed-off-by: David S. Miller

Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6

2009-11-29T08:57:15+00:00

Conflicts:
	drivers/ieee802154/fakehard.c
	drivers/net/e1000e/ich8lan.c
	drivers/net/e1000e/phy.c
	drivers/net/netxen/netxen_nic_init.c
	drivers/net/wireless/ath/ath9k/main.c

macvlan: export macvlan mode through netlink

2009-11-26T23:53:10+00:00

In order to support all three modes of macvlan at
runtime, extend the existing netlink protocol
to allow choosing the mode per macvlan slave
interface.

This depends on a matching patch to iproute2
in order to become accessible in user land.

Signed-off-by: Arnd Bergmann 
Acked-by: Patrick McHardy 
Signed-off-by: David S. Miller

macvlan: implement bridge, VEPA and private mode

2009-11-26T23:53:07+00:00

This allows each macvlan slave device to be in one
of three modes, depending on the use case:

MACVLAN_PRIVATE:
  The device never communicates with any other device
  on the same upper_dev. This even includes frames
  coming back from a reflective relay, where supported
  by the adjacent bridge.

MACVLAN_VEPA:
  The new Virtual Ethernet Port Aggregator (VEPA) mode,
  we assume that the adjacent bridge returns all frames
  where both source and destination are local to the
  macvlan port, i.e. the bridge is set up as a reflective
  relay.
  Broadcast frames coming in from the upper_dev get
  flooded to all macvlan interfaces in VEPA mode.
  We never deliver any frames locally.

MACVLAN_BRIDGE:
  We provide the behavior of a simple bridge between
  different macvlan interfaces on the same port. Frames
  from one interface to another one get delivered directly
  and are not sent out externally. Broadcast frames get
  flooded to all other bridge ports and to the external
  interface, but when they come back from a reflective
  relay, we don't deliver them again.
  Since we know all the MAC addresses, the macvlan bridge
  mode does not require learning or STP like the bridge
  module does.

Based on an earlier patch "macvlan: Reflect macvlan packets
meant for other macvlan devices" by Eric Biederman.

Signed-off-by: Arnd Bergmann 
Acked-by: Patrick McHardy 
Cc: Eric Biederman 
Signed-off-by: David S. Miller

macvlan: cleanup rx statistics

2009-11-26T23:53:02+00:00

We have very similar code for rx statistics in
two places in the macvlan driver, with a third
one being added in the next patch.

Consolidate them into one function to improve
overall readability of the driver.

Signed-off-by: Arnd Bergmann 
Acked-by: Patrick McHardy 
Signed-off-by: David S. Miller

macvlan: fix gso_max_size setting

2009-11-23T22:18:53+00:00

gso_max_size must be set based on the value of the underlying device to
support devices not using the full 64k.

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller

macvlan: Precise RX stats accounting

2009-11-18T07:51:57+00:00

With multi queue devices, its possible that several cpus call
macvlan RX routines simultaneously for the same macvlan device.

We update RX stats counter without any locking, so we can
get slightly wrong counters.

One possible fix is to use percpu counters, to get precise
accounting and also get guarantee of no cache line ping pongs
between cpus.

Note: this adds 16 bytes (32 bytes on 64bit arches) of percpu
data per macvlan device.

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller