Felix Fietkau
2017-Jan-11 11:30 UTC
[Bridge] [PATCH net-next] bridge: multicast to unicast
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? - Felix
IgorMitsyanko
2017-Jan-11 12:15 UTC
[Bridge] [PATCH net-next] bridge: multicast to unicast
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
Felix Fietkau
2017-Jan-11 12:21 UTC
[Bridge] [PATCH net-next] bridge: multicast to unicast
On 2017-01-11 13:15, IgorMitsyanko wrote:> 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).If the AP is running in 4-addr mode, it will need to have a bridge interface anyway, because the link to the STA will be split out into a separate virtual interface (AP_VLAN iftype). In this case you don't actually need any multicast-to-unicast conversion, because the multicast traffic will be unicast on 802.11 already (due to use of 4-addr mode). - Felix