On Wed, 2009-04-08 at 13:18 -0500, Matt Garman wrote: > On Wed, Apr 8, 2009 at 12:55 PM, Jeremy Jackson <jerj@xxxxxxxxxxxx> wrote: > > On Wed, 2009-04-08 at 12:41 -0500, Matt Garman wrote: > >> The latter case is what we need. We are basically already using the > >> former, but since all messages aren't required at all sites, we're > >> trying to reduce network load. (We have lots of message types and > >> very high message volume.) > > > > To conserve resources, you should consider the choice of multicast > > addresses you use. You will want to choose them so that all your > > hardware, switches, routers, NICs, can use hardware filtering. Various > > NICs have different hardware multicast filter types/sizes, so I guess > > you'd have to consult the driver sources, but hardware filtering avoids > > interrupts for packets a machine isn't interested in, so it's worth > > while. > > We're using all Intel server NICs on our machines (e1000/igb driver). > Anyone know offhand what the filtering capabilities are? :) Reducing > interrupts is possibly worth pursuing. I can't say exactly, but I'd guess "good". But the devil is in the details, DEC tulip used hardware hash, but also had a small number of "perfect" address filters. The goal there would be to keep the number of MACs small, to fit in the "perfect" filters, or space the addresses to not collide in the same hash bucket. > On the other hand... how much filtering is done by the switch/router, > and how much is done by the NIC? I'm guessing it's all dependent on > the capabilities of the hardware itself? Some (possibly older) switches could do simple flooding only (ie treat multicast like broadcast). Most managed switches would let you enable IGMP snooping to do real multicast (only send to subscribed ports. Then there's configuring routers for multicast forwarding... -- Jeremy Jackson Coplanar Networks (519)489-4903 http://www.coplanar.net jerj@xxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
