netdev
[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: jamal <hadi@xxxxxxxxxx>
Date: 03 Aug 2003 15:06:07 -0400
Cc: Jeff Garzik <jgarzik@xxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <2147483647.1059667766@xxxxxxxxxxxxxxxxxxxx>
Organization: jamalopolis
References: <20030730184416.GI22222@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <2147483647.1059659359@xxxxxxxxxxxxxxxxxxxx> <3F292B38.4070508@xxxxxxxxx> <2147483647.1059667766@xxxxxxxxxxxxxxxxxxxx>
Reply-to: hadi@xxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
Last discussion that happened:

http://marc.theaimsgroup.com/?t=104163060100001&r=1&w=2

cheers,
jamal


On Thu, 2003-07-31 at 11:09, Rick Payne wrote:
> --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.
> 
> Rick
> 
> 


<Prev in Thread] Current Thread [Next in Thread>
  • Re: multiple unicast mac address (was Re: netdev_ops retraction), jamal <=