Re: local multicast routing

[Brian Haley <brian.haley@xxxxxx>]

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