Matt Garman wrote: > On Thu, Feb 18, 2010 at 10:28:39AM -0500, Brian Haley wrote: >> Matt Garman wrote: >>> Say I have two multicast programs running on the same machine. >>> One is a sending program, and one is a receiving program. The >>> receiving program has joined the group to which the sender in >>> sending. >>> >>> How does the Linux kernel route these packets? I.e., are the >>> packets just pushed out to the switch for routing, or is the >>> kernel smart enough to do some "local delivery" and directly >>> deliver packets to the listener? >> Multicast packets are always looped-back by default in Linux. You >> can turn this behavior off by setting the IP_MULTICAST_LOOP socket >> option to zero. > > So if I'm seeing delays in a local-send-and-receive multicast > scenario, the "local loop back" behavior eliminates the networking > hardware as the culprit, correct? The kernel code shows the looped-back copy never hits the hardware. > Next question, then: are there queues/buffers involved in the Linux > kernel's multicast implementation? > > What I am seeing---in exactly a local send and receive > situation---are latency problems that look like queueing delays. Well, the data is going to be cloned and queued to every socket that has a matching listener... > Where might I start to probe to investigate the source of these > delays? If you think you're seeing a performance problem, you should write-up a good explanation and send it to netdev@xxxxxxxxxxxxxxx, which is where the kernel network developers hang out. Someone that knows the multicast code better might give you a few suggestions then. -Brian -- 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
