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: >> On Wed, Apr 8, 2009 at 11:52 AM, Lawrence MacIntyre >> <macintyrelp@xxxxxxxx> wrote: >> > If all nodes need all of those messages, then you should probably use one >> > multicast address and multiple ports. This will reduce the routing >> > overhead. However, if different nodes need different messages, then you >> > would increase the network overhead by sending all messages to all nodes. >> >> 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. I got the suggestion to use the 239.0.0.0/8 multicast address space from our network engineer. He said that one is typically designated for internal networks, where as the rest of the multicast address space is designated for Internet use. (Meaning, we could use the other addresses, but (in addition to our internal multicast traffic) we're also receiving multicast data from outside our network. In other words, limiting ourselves to 239.x.x.x should hopefully reduce the chances of mixups.) 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. 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? -- 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
