diff for duplicates of <20170109133032.221f8669@xeon-e3> diff --git a/a/1.txt b/N1/1.txt index 4a71c8c..97f9b3f 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,29 +1,29 @@ On Mon, 9 Jan 2017 22:23:45 +0100 -Linus Lüssing <linus.luessing@c0d3.blue> wrote: +Linus L=C3=BCssing <linus.luessing@c0d3.blue> wrote: > On Mon, Jan 09, 2017 at 12:44:19PM +0100, M. Braun wrote: -> > Am 09.01.2017 um 09:08 schrieb Johannes Berg: +> > Am 09.01.2017 um 09:08 schrieb Johannes Berg: =20 > > > Does it make sense to implement the two in separate layers though? -> > > +> > >=20 > > > Clearly, this part needs to be implemented in the bridge layer due to > > > the snooping knowledge, but the code is very similar to what mac80211 -> > > has now. -> > -> > Does the bridge always know about all stations connected? -> +> > > has now. =20 +> >=20 +> > Does the bridge always know about all stations connected? =20 +>=20 > The bridge does not always know about all stations, especially the > silent ones like in your DVB-T example. -> +>=20 > However, concerning IP multicast, there is IGMP/MLD. So the bridge > does know about all stations which are interested in a specific IP > multicast stream. -> +>=20 > (As long as there is a querier on the link, which periodically > queriers for IGMP/MLD reports from any listener. If there is no > querier then the bridge multicast snooping, including the bridge > multicast-to-unicast will fall back to flooding) -> -> +>=20 +>=20 > So if your television example uses IP multicast properly, it is > completely doable with the bridge multicast-to-unicast, thanks to > IGMP/MLD. diff --git a/a/content_digest b/N1/content_digest index 50131c5..5f44f23 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -8,45 +8,45 @@ "ref\06f5ec9f1-800a-2bc4-2f41-9d803343bb22@fami-braun.de\0" "ref\020170109212345.GA5513@otheros\0" "From\0Stephen Hemminger <stephen@networkplumber.org>\0" - "Subject\0Re: [Bridge] [PATCH net-next] bridge: multicast to unicast\0" + "Subject\0Re: [PATCH net-next] bridge: multicast to unicast\0" "Date\0Mon, 9 Jan 2017 13:30:32 -0800\0" "To\0Linus L\303\274ssing <linus.luessing@c0d3.blue>\0" - "Cc\0netdev@vger.kernel.org" - bridge@lists.linux-foundation.org - linux-wireless@vger.kernel.org - linux-kernel@vger.kernel.org - M. Braun <michael-dev@fami-braun.de> + "Cc\0M. Braun <michael-dev@fami-braun.de>" Johannes Berg <johannes@sipsolutions.net> + Felix Fietkau <nbd@nbd.name> + netdev@vger.kernel.org David S . Miller <davem@davemloft.net> - " Felix Fietkau <nbd@nbd.name>\0" + bridge@lists.linux-foundation.org + linux-kernel@vger.kernel.org + " linux-wireless@vger.kernel.org\0" "\00:1\0" "b\0" "On Mon, 9 Jan 2017 22:23:45 +0100\n" - "Linus L\303\274ssing <linus.luessing@c0d3.blue> wrote:\n" + "Linus L=C3=BCssing <linus.luessing@c0d3.blue> wrote:\n" "\n" "> On Mon, Jan 09, 2017 at 12:44:19PM +0100, M. Braun wrote:\n" - "> > Am 09.01.2017 um 09:08 schrieb Johannes Berg: \n" + "> > Am 09.01.2017 um 09:08 schrieb Johannes Berg: =20\n" "> > > Does it make sense to implement the two in separate layers though?\n" - "> > > \n" + "> > >=20\n" "> > > Clearly, this part needs to be implemented in the bridge layer due to\n" "> > > the snooping knowledge, but the code is very similar to what mac80211\n" - "> > > has now. \n" - "> > \n" - "> > Does the bridge always know about all stations connected? \n" - "> \n" + "> > > has now. =20\n" + "> >=20\n" + "> > Does the bridge always know about all stations connected? =20\n" + ">=20\n" "> The bridge does not always know about all stations, especially the\n" "> silent ones like in your DVB-T example.\n" - "> \n" + ">=20\n" "> However, concerning IP multicast, there is IGMP/MLD. So the bridge\n" "> does know about all stations which are interested in a specific IP\n" "> multicast stream.\n" - "> \n" + ">=20\n" "> (As long as there is a querier on the link, which periodically\n" "> queriers for IGMP/MLD reports from any listener. If there is no\n" "> querier then the bridge multicast snooping, including the bridge\n" "> multicast-to-unicast will fall back to flooding)\n" - "> \n" - "> \n" + ">=20\n" + ">=20\n" "> So if your television example uses IP multicast properly, it is\n" "> completely doable with the bridge multicast-to-unicast, thanks to\n" "> IGMP/MLD.\n" @@ -54,4 +54,4 @@ "I wonder if MAC80211 should be doing IGMP snooping and not bridge\n" in this environment. -bd9952b181ae885c1ad74815d6a0a87ffda23d7d25ae4475e97fda82feeb545c +77892011aa522cf86b7336c945441edf1d126d5e3486d19674d5d1f55ce4b2d8
diff --git a/a/content_digest b/N2/content_digest index 50131c5..a520ab2 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -8,17 +8,17 @@ "ref\06f5ec9f1-800a-2bc4-2f41-9d803343bb22@fami-braun.de\0" "ref\020170109212345.GA5513@otheros\0" "From\0Stephen Hemminger <stephen@networkplumber.org>\0" - "Subject\0Re: [Bridge] [PATCH net-next] bridge: multicast to unicast\0" + "Subject\0Re: [PATCH net-next] bridge: multicast to unicast\0" "Date\0Mon, 9 Jan 2017 13:30:32 -0800\0" "To\0Linus L\303\274ssing <linus.luessing@c0d3.blue>\0" - "Cc\0netdev@vger.kernel.org" - bridge@lists.linux-foundation.org - linux-wireless@vger.kernel.org - linux-kernel@vger.kernel.org - M. Braun <michael-dev@fami-braun.de> + "Cc\0M. Braun <michael-dev@fami-braun.de>" Johannes Berg <johannes@sipsolutions.net> + Felix Fietkau <nbd@nbd.name> + netdev@vger.kernel.org David S . Miller <davem@davemloft.net> - " Felix Fietkau <nbd@nbd.name>\0" + bridge@lists.linux-foundation.org + linux-kernel@vger.kernel.org + " linux-wireless@vger.kernel.org\0" "\00:1\0" "b\0" "On Mon, 9 Jan 2017 22:23:45 +0100\n" @@ -54,4 +54,4 @@ "I wonder if MAC80211 should be doing IGMP snooping and not bridge\n" in this environment. -bd9952b181ae885c1ad74815d6a0a87ffda23d7d25ae4475e97fda82feeb545c +9708121e62aa43954a45df2f5fbcd2df00e80a7c0bd1c2f6b30025c5364b8396
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.