On Sun, 9 Sep 2001, Brad Hards wrote:
> 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?
No, there are cases where set_multicast_list() is called without a
change in the Rx filter. It's usually called three times when the
interface is started, when you would expect that just once would do.
(Cf. the ioctl() calls from 'ifconfig'.)
> > 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?
No. Imagine the case where you have a 512 bin statistical filter. That
doesn't mean you can effectively filter 511 Ethernet addresses. And if
you have over a few dozen multicast addresses, you are likely changing
the list very frequently.
I once investigated adding a time component to the code for loading the
multicast filter. If the multicast list changed frequently, it would
remain in Rx-all-multicast mode. Once the list stopped being changed,
the driver would load the filter. I never found a real environment
where this extra complexity made a significant difference. It's very
easy to put in "optimizations" like this without taking into account
how expensive complexity is for long-term maintenance.
> 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?
The generic interface control levels don't filter out all non-changes.
The driver should keep track if anything has changed.
Even if the upper levels did perfectly minimize the changes, the driver
has additional knowledge. For instance adding to the multicast list might
still result in the same hash filter setting.
> After all that, I have two more questions:
> 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?
No.
Note that not all Ethernet chips support turning off reception of
directed unicast packets.
> 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?
There is always additional software filtering for multicast addresses.
With IPv4 multicast this needs to be done anyway, since in a foolish
economy they under-mapped the IP multicast
Here is a snip from something I wrote a while back:
http://www.scyld.com/expert/multicast.html
________________________________________________________________
Mapping of Multicast IP Addresses to Ethernet Addresses.
As explained above, Ethernet has a 48 bit destination address field, with 47
bits in multicast address range. IP has a 32 bit address, with
28 bits in the multicast address range. The obvious solution is to set a fixed
value for the 20 leading Ethernet address bits, and directly
map the 28 IP multicast address bits in the remaining Ethernet address bits.
Even better, use a fixed assigned value for the 16 leading
address bits and directly substitute the IP multicast address for the remaining
32 bits.
In this case, the Internet designers failed to select the obvious method in
favor of an approach that is less good. The prefix 01:00:5e
identifies the frame as multicast, the next bit is always 0 and only 23 bits
are left to the multicast address. The 23 least significant bits
of the IP multicast group are placed in the frame. With the ignored five
high-order bits, the mapping is obviously not one-to-one. 32
different IP multicast groups being mapped to the same Ethernet multicast
address.
This means that the Ethernet layer acts as an imperfect filter, and the IP
layer must do further filtering on the datagrams from the
data-link layer.
________________
Donald Becker becker@xxxxxxxxx
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
Annapolis MD 21403 410-990-9993
|