linux.git/drivers/net/macvlan.c, branch v2.6.33

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

vlan/macvlan: propagate transmission state to upper layers

2009-11-13T22:07:33+00:00

Both vlan and macvlan devices usually don't use a qdisc and immediately
queue packets to the underlying device. Propagate transmission state of
the underlying device to the upper layers so they can react on congestion
and/or inform the sending process.

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

net: Support specifying the network namespace upon device creation.

2009-11-08T08:53:51+00:00

There is no good reason to not support userspace specifying the
network namespace during device creation, and it makes it easier
to create a network device and pass it to a child network namespace
with a well known name.

We have to be careful to ensure that the target network namespace
for the new device exists through the life of the call.  To keep
that logic clear I have factored out the network namespace grabbing
logic into rtnl_link_get_net.

In addtion we need to continue to pass the source network namespace
to the rtnl_link_ops.newlink method so that we can find the base
device source network namespace.

Signed-off-by: Eric W. Biederman 
Acked-by: Eric Dumazet

net: add a list_head parameter to dellink() method

2009-10-28T09:22:07+00:00

Adding a list_head parameter to rtnl_link_ops->dellink() methods
allow us to queue devices on a list, in order to dismantle
them all at once.

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