Re: multicast: same port, different IP address?
From: Jeremy Jackson
Date: Wed Apr 08 2009 - 15:27:44 EST
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...
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