From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: Jiri Pirko <jiri@mellanox.com>
Cc: Sven Eckelmann <sven@narfation.org>,
The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] [RFC v3 14/19] batman-adv: Add multicast_mode mesh genl configuration
Date: Sat, 5 Jan 2019 16:02:32 +0100 [thread overview]
Message-ID: <20190105150232.GO21623@otheros> (raw)
In-Reply-To: <20190104084345.GC21282@nanopsycho.orion>
On Fri, Jan 04, 2019 at 08:51:56AM +0000, Jiri Pirko wrote:
> Fri, Jan 04, 2019 at 08:44:38AM CET, sven@narfation.org wrote:
> >On Friday, 4 January 2019 02.57.26 CET Linus Lüssing wrote:
> >> On Fri, Dec 07, 2018 at 02:58:41PM +0100, Sven Eckelmann wrote:
> >> > diff --git a/net/batman-adv/netlink.c b/net/batman-adv/netlink.c
> >> > index 8e3a1b6e..32762003 100644
> >> > --- a/net/batman-adv/netlink.c
> >> > +++ b/net/batman-adv/netlink.c
> >> > @@ -155,6 +155,7 @@ static const struct nla_policy batadv_netlink_policy[NUM_BATADV_ATTR] = {
> >> > [BATADV_ATTR_GW_SEL_CLASS] = { .type = NLA_U32 },
> >> > [BATADV_ATTR_HOP_PENALTY] = { .type = NLA_U8 },
> >> > [BATADV_ATTR_LOG_LEVEL] = { .type = NLA_U32 },
> >> > + [BATADV_ATTR_MULTICAST_MODE] = { .type = NLA_U8 },
> >> > };
> >>
> >> Since the name is more generic than just a flag, would it make
> >> sense to make this a U32, just to stay flexible for the future?
>
> If the attribute is supposed to be just a bool, the name would be
> probably better to change to "BATADV_ATTR_MULTICAST_ENABLED" or
> something.
Hm, BATADV_ATTR_MULTICAST_ENABLED sounds confusing to me. In a
layer 2 mesh network, multicast always needs to be enabled for
things like IP to work.
So setting this to 0 does not disable multicast.
What this option does is using "classic flooding" (0) for
multicast packets or dropping/unicasting if possible, if IGMP/MLD
snooping detected such potential (1).
And since there were many discussions regarding which additional
techniques and algorithms could be implemented I would expect more
options to follow.
And for complementary techniques, a bitfield of 32 bits size
could be useful, I guess?
next prev parent reply other threads:[~2019-01-05 15:02 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-07 13:58 [B.A.T.M.A.N.] [RFC v3 00/19] batman-adv: netlink restructuring, part 2 Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 01/19] batman-adv: Move common genl doit code pre/post hooks Sven Eckelmann
2018-12-30 16:57 ` Linus Lüssing
2018-12-31 19:08 ` Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 02/19] batman-adv: Prepare framework for mesh genl config Sven Eckelmann
2018-12-31 11:09 ` Linus Lüssing
2018-12-31 19:11 ` Sven Eckelmann
2019-01-07 18:49 ` Linus Lüssing
2019-01-08 7:54 ` Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 03/19] batman-adv: Prepare framework for hardif " Sven Eckelmann
2018-12-31 11:59 ` Linus Lüssing
2018-12-31 19:17 ` Sven Eckelmann
2019-01-04 0:39 ` Linus Lüssing
2019-01-04 7:52 ` Sven Eckelmann
2019-01-05 15:12 ` Linus Lüssing
2019-01-05 17:22 ` Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 04/19] batman-adv: Prepare framework for vlan " Sven Eckelmann
2019-01-04 1:53 ` Linus Lüssing
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 05/19] batman-adv: Add aggregated_ogms mesh genl configuration Sven Eckelmann
2019-01-04 1:40 ` Linus Lüssing
2019-01-04 7:59 ` Sven Eckelmann
2019-01-04 2:06 ` Linus Lüssing
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 06/19] batman-adv: Add ap_isolation mesh/vlan " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 07/19] batman-adv: Add bonding mesh " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 08/19] batman-adv: Add bridge_loop_avoidance " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 09/19] batman-adv: Add distributed_arp_table " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 10/19] batman-adv: Add fragmentation " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 11/19] batman-adv: Add gateway " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 12/19] batman-adv: Add hop_penalty " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 13/19] batman-adv: Add log_level " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 14/19] batman-adv: Add multicast_mode " Sven Eckelmann
2019-01-04 1:57 ` Linus Lüssing
2019-01-04 7:44 ` Sven Eckelmann
2019-01-04 8:51 ` Jiri Pirko
2019-01-05 15:02 ` Linus Lüssing [this message]
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 15/19] batman-adv: Add network_coding " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 16/19] batman-adv: Add orig_interval " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 17/19] batman-adv: Add elp_interval hardif " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 18/19] batman-adv: Add throughput_override " Sven Eckelmann
2018-12-07 13:58 ` [B.A.T.M.A.N.] [RFC v3 19/19] batman-adv: Trigger genl notification on sysfs config change Sven Eckelmann
2019-01-04 2:29 ` Linus Lüssing
2019-01-04 7:58 ` Sven Eckelmann
2019-01-05 15:03 ` Linus Lüssing
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=20190105150232.GO21623@otheros \
--to=linus.luessing@c0d3.blue \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=jiri@mellanox.com \
--cc=sven@narfation.org \
/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).