Re: [PATCH net-next] bridge: multicast to unicast

From: IgorMitsyanko
Date: Wed Jan 11 2017 - 07:15:58 EST


On 01/11/2017 02:30 PM, Felix Fietkau wrote:
On 2017-01-11 12:26, IgorMitsyanko wrote:
On 01/11/2017 12:27 AM, Felix Fietkau wrote:
On 2017-01-10 11:56, Johannes Berg wrote:
On Tue, 2017-01-10 at 05:18 +0100, Linus LÃssing wrote:
On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
I wonder if MAC80211 should be doing IGMP snooping and not bridge
in this environment.
In the long term, yes. For now, not quite sure.
There's no "for now" in the kernel. Code added now will have to be
maintained essentially forever.
I'm not sure that putting the IGMP snooping code in mac80211 is a good
idea, that would be quite a bit of code duplication.
This implementation works, it's very simple, and it's quite flexible for
a number of use cases.

Is there any remaining objection to merging this in principle (aside
from potential issues with the code)?

- Felix


Hi Felix, can we consider two examples configurations with multicast
traffic:

1. AP is a source of multicast traffic itself, no bridge on AP. For
example, wireless video server streaming to several clients.
In this situation, we can not make use of possible advantages given by
mc-to-uc conversion?
You could simply put the AP interface in a bridge, no need to have any
other bridge members present.

2. A configuration with AP + STA + 3 client devices behind STA.
----|client 1|
|
| mc |----|AP|----|STA|---|---|client 2|
|server| |
----|client 3|

Multicast server behind AP streams MC video traffic. All 3 clients
behind the STA have joined the multicast group.
I'm not sure if this case will be handled correctly with mc-to-uc
conversion in bridge on AP?
What do you mean by "3 client devices behind STA"? Are you using a
4-addr STA, multicast routing, or some kind of vendor specific "client
bridge" hackery?

3 client devices connected by backbone Ethernet network. Generic
case is probably STA/AP operating in 4-addr mode (more or less standard
solution as far as I know).

"Client bridge" approach should not concern us here I think, it will
seem to AP and AP's bridge as a single client.


- Felix