[Top] [All Lists]

Re: multiple unicast mac address (was Re: netdev_ops retraction)

To: Rick Payne <rickp@xxxxxxxxxxxxxx>
Subject: Re: multiple unicast mac address (was Re: netdev_ops retraction)
From: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Thu, 31 Jul 2003 10:44:08 -0400
Cc: netdev@xxxxxxxxxxx
In-reply-to: <2147483647.1059659359@xxxxxxxxxxxxxxxxxxxx>
Organization: none
References: <20030730184416.GI22222@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <2147483647.1059659359@xxxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk
Rick Payne wrote:

--On Wednesday, July 30, 2003 7:44 pm +0100 Matthew Wilcox <willy@xxxxxxxxxx> wrote:

+       void    (*set_multicast_list)(struct net_device *dev);
+       int     (*set_mac_address)(struct net_device *dev, void *addr);

Talking of which - is there any appetite for a patch that allows multiple unicast mac addresses to be set on an ethernet interface? Its certainly much neater for things like VRRP and HA stuff if an ethernet device is able to continue accepting packets for its original MAC address, as well as the 'virtual MAC address'.

Obviously I'm not talking about generated packets (they will still take the MAC address from dev->dev_addr) - I'm talking about the hardware filter on the ethernet cards themselves. (In some cases, the software concerned may want to set_mac_address - thus updating dev->dev_addr, and then also add the original mac address to the 'unicast accept list' for instance).

This feature request comes up about once a year. Search the archives for responses...

Hardware that filters N MAC addresses (unicast filtering) doesn't have a terribly standard interface, and the unicast filter must be adjusted at different times on different hardware. Also, chip bugs lead one to think unicast filtering will work where it doesn't. Also, chip limits for some of the more popular chips are unknown. Also, the need for this feature is very uncommon, and can be achieved in other ways.


<Prev in Thread] Current Thread [Next in Thread>