netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [NET 00/02]: MACVLAN driver
@ 2007-06-19 13:08 Patrick McHardy
  2007-06-19 13:08 ` [ETHERNET 01/02]: Validate new address in eth_mac_addr Patrick McHardy
                   ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Patrick McHardy @ 2007-06-19 13:08 UTC (permalink / raw)
  To: davem; +Cc: netdev, Patrick McHardy

These patches add a rewritten version of Ben's macvlan driver, which
allows to create virtual ethernet devices. The underlying device is
put in promiscous mode and packets are demuxed based on MAC address.
It behaves similar to bridge devices in that packets are visible on
the real device before delivery to the macvlan driver. The driver
supports all features of the underlying device except VLAN
acceleration, this is currently very hard to support. I might look
into this in the future.

The main downside of this driver is that it adds another hook in
netif_receive_skb, unfortunately that is unavoidable. When not
compiled in the hook vanishes of course.

Usage is simple:

# ip link add link eth0 type macvlan

Will create a macvlan0 device with a random MAC address on top of
eth0. No iproute patches are required.


Please apply, thanks.


 MAINTAINERS                |    6 +
 drivers/net/Kconfig        |   10 +
 drivers/net/Makefile       |    1 +
 drivers/net/macvlan.c      |  468 ++++++++++++++++++++++++++++++++++++++++++++
 include/linux/if_macvlan.h |    9 +
 include/linux/netdevice.h  |    2 +
 net/core/dev.c             |   26 +++
 net/ethernet/eth.c         |    3 +
 8 files changed, 525 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/macvlan.c
 create mode 100644 include/linux/if_macvlan.h

Patrick McHardy (2):
      [ETHERNET]: Validate new address in eth_mac_addr
      [NET]: Add MACVLAN driver

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: [NET 00/02]: MACVLAN driver
@ 2007-06-24  4:52 Mark Smith
  0 siblings, 0 replies; 13+ messages in thread
From: Mark Smith @ 2007-06-24  4:52 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: netdev

(Applogies for not maintaining thread id, I'm not subscribed.)

>> We don't have any clean interfaces by which to do this MAC
>> programming, and we do need something for it soon.


>Yep, that's been on my long term wish list for a while, as well.

>Overall I would like to see a more flexible way of allowing the net 
>stack to learn each NIC's RX filter capabilities, and exploiting them. 
>Plenty of NICs, even 100Mbps ones, support RX filter management that 
>allows scanning for $hw_limit unicast addresses, before having to put 
>the hardware into promisc mode.
>

A thought I had when I discovered this ability in the
Natsemi/NS83815 chip was to use these RX filters for perfect multicast
DA matching until they ran out, and then reverting to the normal
Multicast DA matching mechanisms.

Another alternative use I thought of was to use these filters to filter
out different ethernet protocol types e.g. if an interface is only
going to be processing IPv4 packets, program these filters to only
accept frames with type 0800 for IP and 0806 for ARP, reverting to
non-filtering if there are too many protocol types, as per the way the
interfaces operate today.

I think it could be useful to expose the ability to have the NIC ignore
broadcast packets, or more generally, expose the three catagories of
address recognition that NICs seem to allow to be enabled / disabled -
unicast, multicast and broadcast.

If an interface then didn't need to have broadcast reception enabled
e.g. an IPv6 only interface (or Appletalk), then it wouldn't be,
preventing the host from having to process broadcasts it's going to
ignore anyway.

A future common scenario where this ability might be useful would be
LANs with a mix of IPv4 only, IPv4/IPv6 and IPv6-only nodes.

The ability to enable/disable unicast, multicast and broadcast address
recognition individually on a NIC seems to be widespread -  I've found
that the original early to mid 90s Ne2K chip, the NS8390D, the Netgear
FA311/FA312 chip, the NS83815 and the SMC Epic/100 chip all have
specific individual register values for those three types of addresses.

Regards,
Mark.

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2007-06-24  5:44 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-06-19 13:08 [NET 00/02]: MACVLAN driver Patrick McHardy
2007-06-19 13:08 ` [ETHERNET 01/02]: Validate new address in eth_mac_addr Patrick McHardy
2007-06-19 13:08 ` [NET 02/02]: Add MACVLAN driver Patrick McHardy
2007-06-19 16:00 ` [NET 00/02]: " Stephen Hemminger
2007-06-19 19:53   ` Chris Leech
2007-06-19 21:14   ` Patrick McHardy
2007-06-19 22:29     ` Stephen Hemminger
2007-06-19 22:48     ` David Miller
2007-06-19 23:44       ` Patrick McHardy
2007-06-20  6:34       ` Jeff Garzik
2007-06-20 19:35         ` Prafulla Deuskar
2007-06-21 14:57           ` Patrick McHardy
  -- strict thread matches above, loose matches on Subject: below --
2007-06-24  4:52 Mark Smith

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).