|To:||Jeff Garzik <jgarzik@xxxxxxxxx>|
|Subject:||Re: multiple unicast mac address (was Re: netdev_ops retraction)|
|From:||Rick Payne <rickp@xxxxxxxxxxxxxx>|
|Date:||Thu, 31 Jul 2003 16:09:26 +0100|
|References:||<20030730184416.GI22222@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <2147483647.1059659359@xxxxxxxxxxxxxxxxxxxx> <3F292B38.4070508@xxxxxxxxx>|
--On Thursday, July 31, 2003 10:44 am -0400 Jeff Garzik <jgarzik@xxxxxxxxx> wrote:
Hardware that filters N MAC addresses (unicast filtering) doesn't have a terribly standard interface, and the unicast filter must be adjusted at
Indeed but where its possible to support it, it can be - and those cards will be specified by those who need it (for HA, VRRP etc).
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.
As I said - promiscuous mode and filtering on the receive side - which is what you have to resort to anyway for those cards that don't support it.
Alternatively, its just another patch people need to add to make things do what they want - just like the ARP patch.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: multiple unicast mac address (was Re: netdev_ops retraction), Jeff Garzik|
|Next by Date:||Re: [PATCH] 2.4.22-pre9-bk : bonding bug fixes, Jeff Garzik|
|Previous by Thread:||Re: multiple unicast mac address (was Re: netdev_ops retraction), Jeff Garzik|
|Next by Thread:||[PATCH] export correct symbols when INET not enabled, Stephen Hemminger|
|Indexes:||[Date] [Thread] [Top] [All Lists]|