netdev
[Top] [All Lists]

Re: Promiscuous and Multicast semantics

To: netdev@xxxxxxxxxxx
Subject: Re: Promiscuous and Multicast semantics
From: Brad Hards <bhards@xxxxxxxxxxxxxx>
Date: Sun, 09 Sep 2001 19:51:54 +1000
Cc: Donald Becker <becker@xxxxxxxxx>
References: <Pine.LNX.4.10.10109081106320.4192-100000@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Donald Becker wrote:
<snip>
> Correct.  Every change to the Rx filter is communicated by a call to
>   net_device.set_multicast_list(dev)
Is this a "necessary", in that if that call is made, something has definately
changed?
 
> > What is the interaction between promiscuous mode and multicast mode? If I 
> > set
> > promiscuous mode, is there any required changes to multicast mode (enabled 
> > or
> > disabled)?
> 
> You should refer to the code in pci-skeleton.c or the older
> (ISA-oriented) skeleton.c to confirm your understanding.
OK, that did help, although having your explaination to read with the code
certainly made it a lot easier. Thanks very much for the assistance.
 
<snip>
> Most of my drivers use the module parameter 'multicast_filter_limit' to
> treat too many multicast addresses as the equivalent of ALLMULTI.  The
> default value is set based on the multicast filter size and how painful
> it is to set the multicast list.
The CDC Ethernet descriptor actually specifies how many filters are available
(if any) for this device, and I was planning to use that, rather than a module
parameter, since the driver can conceivably support a number of different
devices on the same host. Does this seem reasonable?
 
<snip>
> Keep in mind that a single write the Ethernet chip (even on PCI) might
> cost the same as executing thousands of cached instructions.  Doing an
> unconditional write might look simpler, but keeping the old state around
> to avoid a duplicate write is now well worth the complexity.
Going back to my first question, does this mean that the higher level net code
will shield the driver from calls to .set_multicast_list() where no change
would have occurred (such as changing the multicast list while promiscuous
mode is enabled)? Or does the driver have to do this, if required?

After all that, I have two more questions:
1. Do the higher level networking functions "know" or care whether perfect
multicast filtering or hashing is being used? Or does some upper level
networking function always apply filtering, on the assumption that some form
of hashed multicast is (or may be) in use?

2. In pci-skeleton, AcceptMyPhys seems to be asserted in any case. Can the "do
not receive directed packets" (essentially !AcceptMyPhys) case be communicated
to a driver?

Brad

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