From: Stephen Hemminger <stephen@networkplumber.org>
To: "Linus Lüssing" <linus.luessing@c0d3.blue>
Cc: netdev@vger.kernel.org, "David S . Miller" <davem@davemloft.net>,
Felix Fietkau <nbd@nbd.name>,
Nikolay Aleksandrov <nikolay@cumulusnetworks.com>,
bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org
Subject: Re: [PATCH net-next v4] bridge: multicast to unicast
Date: Thu, 19 Jan 2017 11:05:20 -0800 [thread overview]
Message-ID: <20170119110520.24dfd34d@xeon-e3> (raw)
In-Reply-To: <20170119024510.3284-1-linus.luessing@c0d3.blue>
On Thu, 19 Jan 2017 03:45:10 +0100
Linus Lüssing <linus.luessing@c0d3.blue> wrote:
> From: Felix Fietkau <nbd@nbd.name>
>
> Implements an optional, per bridge port flag and feature to deliver
> multicast packets to any host on the according port via unicast
> individually. This is done by copying the packet per host and
> changing the multicast destination MAC to a unicast one accordingly.
>
> multicast-to-unicast works on top of the multicast snooping feature of
> the bridge. Which means unicast copies are only delivered to hosts which
> are interested in it and signalized this via IGMP/MLD reports
> previously.
>
> This feature is intended for interface types which have a more reliable
> and/or efficient way to deliver unicast packets than broadcast ones
> (e.g. wifi).
>
> However, it should only be enabled on interfaces where no IGMPv2/MLDv1
> report suppression takes place. This feature is disabled by default.
>
> The initial patch and idea is from Felix Fietkau.
>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> [linus.luessing@c0d3.blue: various bug + style fixes, commit message]
> Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
>
In general this looks good.
One issue I see is how existing entries are handled when the bridge port flags
are changed dynamically. It might be better to always record the necessary data
in the bridge_port_group and not have a per-entry flag bit. In your current
patch the API changes the response to future IGMP but does not take instant
effect. Code would be simpler if there was less logic to handle per-entry flags.
Also, you might want to add sysfs interface for the attribute as well.
prev parent reply other threads:[~2017-01-19 19:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-19 2:45 [PATCH net-next v4] bridge: multicast to unicast Linus Lüssing
2017-01-19 9:53 ` Nikolay Aleksandrov
2017-01-19 19:05 ` Stephen Hemminger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170119110520.24dfd34d@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=linus.luessing@c0d3.blue \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).