From: Jiri Pirko <jiri@resnulli.us> To: Sven Eckelmann <sven@narfation.org> Cc: b.a.t.m.a.n@lists.open-mesh.org, Jiri Pirko <jiri@mellanox.com>, netdev@vger.kernel.org, linus.luessing@c0d3.blue Subject: Re: [RFC v4 00/19] batman-adv: netlink restructuring, part 2 Date: Sun, 27 Jan 2019 09:45:16 +0100 [thread overview] Message-ID: <20190127084516.GA2151@nanopsycho> (raw) In-Reply-To: <1895931.G10psR3j26@sven-edge> Sat, Jan 26, 2019 at 11:47:20AM CET, sven@narfation.org wrote: >On Saturday, 19 January 2019 16.56.07 CET Sven Eckelmann wrote: >[...] >> There were also two topics which were not yet really discussed and thus >> these requests (from Linus) were not yet implemented: > >@Jiri, @Linus maybe you can discuss these topics further and select the >correct solution. > >> * convert BATADV_ATTR_MULTICAST_MODE_ENABLED to an u32 and let don't handle >> it like a boolean. Instead use it to select how multicast traffic has to >> be handled: >> >> - 0: ignore multicast optimization and just flood it like broadcast >> traffic >> - 1: enabled multicast optimization >> - 2: undefined but also some kind of multicast optimization >> - 3: undefined but also some kind of multicast of optimization >> - ... > >Multicast mode is currently defined. > >* according to batctl manpage: > > multicast_mode|mm [0|1] > If no parameter is given the current multicast mode set‐ > ting is displayed. Otherwise the parameter is used to en‐ > able or disable multicast optimizations (i.e. disabling > means always sending own multicast frames via classic > flooding). > >* according to sysfs ABI: > > What: /sys/class/net/<mesh_iface>/mesh/multicast_mode > Date: Feb 2014 > Contact: Linus Lüssing <linus.luessing@web.de> > Description: > Indicates whether multicast optimizations are enabled > or disabled. If set to zero then all nodes in the > mesh are going to use classic flooding for any > multicast packet with no optimizations. > >Both define it as boolean value and therefore it was converted to a boolean >value (via u8) in netlink. > >But Linus now suggested that it is actually an u32. Most likely 0 == to >something like BATADV_MULTICAST_MODE_FLOODING. But I have no idea what 1 is or >what 2, 3, 4, .. would be. So I need some input here. > >And Jiri said that it should be renamed to BATADV_ATTR_MULTICAST_ENABLED - >which seems to suggest that he doesn't like the idea of a u32 for some reason >and prefers to use a boolean value. > >And now Linus even said that it should be a bit field - which makes it even >more vague to me and I have now absolutely no idea what should be implemented. If it is bool, it should be bool. If it is a bitfield (future more bits than one needed), it should be a bitfield. > >* BIT 0 for flooding vs ? >* BIT 1 for ? >* ... > >> * convert BATADV_ATTR_AGGREGATION_OGM_ENABLED to u32 and use it >> to mark which type of traffic should be aggregated: >> >> - bit 0: enable aggregation of OGM(2)s >> - bit 1: yet undefined packet type which allows some kind of aggregation >> - bit 2: yet undefined packet type which allows some kind of aggregation >> - ... > >Aggregated OGM is currently defined as: > > >* according to batctl manpage: > > aggregation|ag [0|1] > If no parameter is given the current aggregation setting > is displayed. Otherwise the parameter is used to enable or > disable OGM packet aggregation. > >* according to sysfs ABI: > > What: /sys/class/net/<mesh_iface>/mesh/aggregated_ogms > Date: May 2010 > Contact: Marek Lindner <mareklindner@neomailbox.ch> > Description: > Indicates whether the batman protocol messages of the > mesh <mesh_iface> shall be aggregated or not. > >So sysfs is only one possible backend for the batctl command. There is >currently nothing which I would assume to be aggregatable beside OGMs but let >us assume for now that there is now something and some way to aggregate things >beside OGMs in a save and backward compatible way. Let's call this FOO - so we >have BATADV_ATTR_AGGREGATION_OGM_ENABLED and >BATADV_ATTR_AGGREGATION_FOO_ENABLED. Or we have BATADV_ATTR_AGGREGATION as an >u32 and just use the second bit as marker for FOO (and of course the first bit >as marker for OGM). > >Would it now be more preferable to use BATADV_ATTR_AGGREGATION_OGM_ENABLED as >u8 (boolean) or to to switch to BATADV_ATTR_AGGREGATION (u32) & assign single >bits to packet types. > >Kind regards, > Sven
WARNING: multiple messages have this Message-ID (diff)
From: Jiri Pirko <jiri@resnulli.us> To: Sven Eckelmann <sven@narfation.org> Cc: b.a.t.m.a.n@lists.open-mesh.org, Jiri Pirko <jiri@mellanox.com>, netdev@vger.kernel.org, linus.luessing@c0d3.blue Subject: Re: [B.A.T.M.A.N.] [RFC v4 00/19] batman-adv: netlink restructuring, part 2 Date: Sun, 27 Jan 2019 09:45:16 +0100 [thread overview] Message-ID: <20190127084516.GA2151@nanopsycho> (raw) In-Reply-To: <1895931.G10psR3j26@sven-edge> Sat, Jan 26, 2019 at 11:47:20AM CET, sven@narfation.org wrote: >On Saturday, 19 January 2019 16.56.07 CET Sven Eckelmann wrote: >[...] >> There were also two topics which were not yet really discussed and thus >> these requests (from Linus) were not yet implemented: > >@Jiri, @Linus maybe you can discuss these topics further and select the >correct solution. > >> * convert BATADV_ATTR_MULTICAST_MODE_ENABLED to an u32 and let don't handle >> it like a boolean. Instead use it to select how multicast traffic has to >> be handled: >> >> - 0: ignore multicast optimization and just flood it like broadcast >> traffic >> - 1: enabled multicast optimization >> - 2: undefined but also some kind of multicast optimization >> - 3: undefined but also some kind of multicast of optimization >> - ... > >Multicast mode is currently defined. > >* according to batctl manpage: > > multicast_mode|mm [0|1] > If no parameter is given the current multicast mode set‐ > ting is displayed. Otherwise the parameter is used to en‐ > able or disable multicast optimizations (i.e. disabling > means always sending own multicast frames via classic > flooding). > >* according to sysfs ABI: > > What: /sys/class/net/<mesh_iface>/mesh/multicast_mode > Date: Feb 2014 > Contact: Linus Lüssing <linus.luessing@web.de> > Description: > Indicates whether multicast optimizations are enabled > or disabled. If set to zero then all nodes in the > mesh are going to use classic flooding for any > multicast packet with no optimizations. > >Both define it as boolean value and therefore it was converted to a boolean >value (via u8) in netlink. > >But Linus now suggested that it is actually an u32. Most likely 0 == to >something like BATADV_MULTICAST_MODE_FLOODING. But I have no idea what 1 is or >what 2, 3, 4, .. would be. So I need some input here. > >And Jiri said that it should be renamed to BATADV_ATTR_MULTICAST_ENABLED - >which seems to suggest that he doesn't like the idea of a u32 for some reason >and prefers to use a boolean value. > >And now Linus even said that it should be a bit field - which makes it even >more vague to me and I have now absolutely no idea what should be implemented. If it is bool, it should be bool. If it is a bitfield (future more bits than one needed), it should be a bitfield. > >* BIT 0 for flooding vs ? >* BIT 1 for ? >* ... > >> * convert BATADV_ATTR_AGGREGATION_OGM_ENABLED to u32 and use it >> to mark which type of traffic should be aggregated: >> >> - bit 0: enable aggregation of OGM(2)s >> - bit 1: yet undefined packet type which allows some kind of aggregation >> - bit 2: yet undefined packet type which allows some kind of aggregation >> - ... > >Aggregated OGM is currently defined as: > > >* according to batctl manpage: > > aggregation|ag [0|1] > If no parameter is given the current aggregation setting > is displayed. Otherwise the parameter is used to enable or > disable OGM packet aggregation. > >* according to sysfs ABI: > > What: /sys/class/net/<mesh_iface>/mesh/aggregated_ogms > Date: May 2010 > Contact: Marek Lindner <mareklindner@neomailbox.ch> > Description: > Indicates whether the batman protocol messages of the > mesh <mesh_iface> shall be aggregated or not. > >So sysfs is only one possible backend for the batctl command. There is >currently nothing which I would assume to be aggregatable beside OGMs but let >us assume for now that there is now something and some way to aggregate things >beside OGMs in a save and backward compatible way. Let's call this FOO - so we >have BATADV_ATTR_AGGREGATION_OGM_ENABLED and >BATADV_ATTR_AGGREGATION_FOO_ENABLED. Or we have BATADV_ATTR_AGGREGATION as an >u32 and just use the second bit as marker for FOO (and of course the first bit >as marker for OGM). > >Would it now be more preferable to use BATADV_ATTR_AGGREGATION_OGM_ENABLED as >u8 (boolean) or to to switch to BATADV_ATTR_AGGREGATION (u32) & assign single >bits to packet types. > >Kind regards, > Sven
next prev parent reply other threads:[~2019-01-27 8:54 UTC|newest] Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-19 15:56 [RFC v4 00/19] batman-adv: netlink restructuring, part 2 Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-19 15:56 ` [RFC v4 01/19] batman-adv: Move common genl doit code pre/post hooks Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-19 15:56 ` [RFC v4 02/19] batman-adv: Prepare framework for mesh genl config Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-19 15:56 ` [RFC v4 03/19] batman-adv: Prepare framework for hardif " Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-19 15:56 ` [RFC v4 04/19] batman-adv: Prepare framework for vlan " Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-21 9:44 ` Jiri Pirko 2019-01-21 9:44 ` [B.A.T.M.A.N.] " Jiri Pirko 2019-01-19 15:56 ` [RFC v4 05/19] batman-adv: Add aggregated_ogms mesh genl configuration Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-19 15:56 ` [RFC v4 06/19] batman-adv: Add ap_isolation mesh/vlan " Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-19 15:56 ` [RFC v4 07/19] batman-adv: Add bonding mesh " Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-19 15:56 ` [RFC v4 08/19] batman-adv: Add bridge_loop_avoidance " Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-19 15:56 ` [RFC v4 09/19] batman-adv: Add distributed_arp_table " Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-19 15:56 ` [RFC v4 10/19] batman-adv: Add fragmentation " Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-19 15:56 ` [RFC v4 11/19] batman-adv: Add gateway " Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-19 15:56 ` [RFC v4 12/19] batman-adv: Add hop_penalty " Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-19 15:56 ` [RFC v4 13/19] batman-adv: Add log_level " Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-19 15:56 ` [RFC v4 14/19] batman-adv: Add multicast_mode " Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-19 15:56 ` [RFC v4 15/19] batman-adv: Add network_coding " Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-19 15:56 ` [RFC v4 16/19] batman-adv: Add orig_interval " Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-19 15:56 ` [RFC v4 17/19] batman-adv: Add elp_interval hardif " Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-19 15:56 ` [RFC v4 18/19] batman-adv: Add throughput_override " Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-19 15:56 ` [RFC v4 19/19] batman-adv: Trigger genl notification on sysfs config change Sven Eckelmann 2019-01-19 15:56 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-21 9:47 ` [RFC v4 00/19] batman-adv: netlink restructuring, part 2 Jiri Pirko 2019-01-21 9:47 ` [B.A.T.M.A.N.] " Jiri Pirko 2019-01-26 10:47 ` Sven Eckelmann 2019-01-26 10:47 ` [B.A.T.M.A.N.] " Sven Eckelmann 2019-01-27 8:45 ` Jiri Pirko [this message] 2019-01-27 8:45 ` Jiri Pirko 2019-02-05 17:04 ` Simon Wunderlich 2019-02-05 19:24 ` Linus Lüssing 2019-02-06 18:20 ` Sven Eckelmann 2019-02-06 19:08 ` Linus Lüssing 2019-02-07 10:02 ` Sven Eckelmann
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=20190127084516.GA2151@nanopsycho \ --to=jiri@resnulli.us \ --cc=b.a.t.m.a.n@lists.open-mesh.org \ --cc=jiri@mellanox.com \ --cc=linus.luessing@c0d3.blue \ --cc=netdev@vger.kernel.org \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.