From: "Linus Lüssing" <linus.luessing@web.de>
To: 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.] [PATCH 2/3] batman-adv: Announce new capability via multicast TVLV
Date: Thu, 16 May 2013 20:19:45 +0200 [thread overview]
Message-ID: <20130516181945.GC22374@Linus-Debian> (raw)
In-Reply-To: <20130511231113.GE901@ritirata.org>
On Sun, May 12, 2013 at 01:11:13AM +0200, Antonio Quartulli wrote:
> On Sat, May 11, 2013 at 07:23:26PM +0200, Linus Lüssing wrote:
> > /**
> > + * batadv_mcast_tvlv_ogm_handler_v1 - process incoming multicast tvlv container
> > + * @bat_priv: the bat priv with all the soft interface information
> > + * @orig: the orig_node of the ogm
> > + * @flags: flags indicating the tvlv state (see batadv_tvlv_handler_flags)
> > + * @tvlv_value: tvlv buffer containing the multicast data
> > + * @tvlv_value_len: tvlv buffer length
> > + */
> > +static void batadv_mcast_tvlv_ogm_handler_v1(struct batadv_priv *bat_priv,
> > + struct batadv_orig_node *orig,
> > + uint8_t flags,
> > + void *tvlv_value,
> > + uint16_t tvlv_value_len)
> > +{
> > + uint8_t mcast_flags = BATADV_NO_FLAGS;
> > +
> > + /* only fetch the tvlv value if the handler wasn't called via the
> > + * CIFNOTFND flag and if there is data to fetch
> > + */
> > + if (!(flags & BATADV_TVLV_HANDLER_OGM_CIFNOTFND) &&
> > + (tvlv_value) && (tvlv_value_len == 1))
> just for style reason I'd suggest to use sizeof(mcast_flags)
> instead of 1. and there is no need for parentheses around
> tvlv_value.
>
> > + mcast_flags = *(unsigned char *)tvlv_value;
>
> mcast_flags is uint8_t, therefore (even if it may practically be the same) you
> should use the same type for the cast.
ok
>
> > +
> > + if (!(mcast_flags & BATADV_MCAST_LISTENER_ANNOUNCEMENT) &&
> > + orig->mcast_flags & BATADV_MCAST_LISTENER_ANNOUNCEMENT) {
> > + atomic_inc(&bat_priv->mcast_num_non_aware);
> > + } else if (mcast_flags & BATADV_MCAST_LISTENER_ANNOUNCEMENT &&
> > + !(orig->mcast_flags & BATADV_MCAST_LISTENER_ANNOUNCEMENT)) {
> > + atomic_dec(&bat_priv->mcast_num_non_aware);
> > + }
> > +
> > + orig->mcast_flags = mcast_flags;
> > +}
>
> > diff --git a/originator.c b/originator.c
> > index 5d53d2f..acc0c2d 100644
> > --- a/originator.c
> > +++ b/originator.c
> > @@ -257,6 +257,9 @@ struct batadv_orig_node *batadv_get_orig_node(struct batadv_priv *bat_priv,
> > reset_time = jiffies - 1 - msecs_to_jiffies(BATADV_RESET_PROTECTION_MS);
> > orig_node->bcast_seqno_reset = reset_time;
> > orig_node->batman_seqno_reset = reset_time;
> > +#ifdef CONFIG_BATMAN_ADV_MCAST_OPTIMIZATIONS
> > + orig_node->mcast_flags = BATADV_MCAST_LISTENER_ANNOUNCEMENT;
> > +#endif
>
> why do you start assuming that an originator has the optimisation enabled? would
> it be better to wait for the first mcast tvlv from it to claim this?
Because it is easier code-wise. I had it the other way round first
and issuing an atomic_inc(&bat_priv->mcast_num_non_ware) in
batadv_get_orig_node(), but then I ended up counting up too many
times because I was increasing that counter for secondary
interface originators, too while not decreasing it again because
no TVLV handler will be called for these. And within
batadv_get_orig_node() I don't see an easy way to determine
whether I was called for a primary or secondary interface
originator.
>
> > +/* multicast capabilities */
> > +enum batadv_mcast_flags {
> > + BATADV_MCAST_LISTENER_ANNOUNCEMENT = BIT(0),
> > +};
> > +
>
> > diff --git a/types.h b/types.h
> > index 5d73a75..4ef5fb9 100644
> > --- a/types.h
> > +++ b/types.h
> > @@ -146,6 +146,9 @@ struct batadv_orig_node {
> > unsigned long last_seen;
> > unsigned long bcast_seqno_reset;
> > unsigned long batman_seqno_reset;
> > +#ifdef CONFIG_BATMAN_ADV_MCAST_OPTIMIZATIONS
> > + uint8_t mcast_flags;
> > +#endif
> > uint8_t capabilities;
> > atomic_t last_ttvn;
> > uint32_t tt_crc;
> > @@ -569,6 +572,7 @@ struct batadv_priv {
> > #endif
> > #ifdef CONFIG_BATMAN_ADV_MCAST_OPTIMIZATIONS
> > atomic_t mcast_group_awareness;
> > + atomic_t mcast_num_non_aware;
>
> why isn't this variable in the mcast_priv struct? It is not a user knob (as far
> as I can see)
You're right, will move it.
>
> Cheers,
>
> --
> Antonio Quartulli
>
> ..each of us alone is worth nothing..
> Ernesto "Che" Guevara
Cheers, Linus
next prev parent reply other threads:[~2013-05-16 18:19 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-11 17:23 [B.A.T.M.A.N.] Basic Multicast Optimizations Linus Lüssing
2013-05-11 17:23 ` [B.A.T.M.A.N.] [PATCH 1/3] batman-adv: Multicast Listener Announcements via Translation Table Linus Lüssing
2013-05-11 22:55 ` Antonio Quartulli
2013-05-16 18:16 ` Linus Lüssing
2013-05-16 19:36 ` Antonio Quartulli
2013-05-11 17:23 ` [B.A.T.M.A.N.] [PATCH 2/3] batman-adv: Announce new capability via multicast TVLV Linus Lüssing
2013-05-11 23:11 ` Antonio Quartulli
2013-05-16 18:19 ` Linus Lüssing [this message]
2013-05-16 19:41 ` Antonio Quartulli
2013-05-16 22:34 ` Linus Lüssing
2013-05-11 17:23 ` [B.A.T.M.A.N.] [PATCH 3/3] batman-adv: Modified forwarding behaviour for multicast packets Linus Lüssing
2013-05-11 23:29 ` Antonio Quartulli
2013-05-16 18:22 ` Linus Lüssing
2013-05-16 19:43 ` Antonio Quartulli
2013-05-16 11:51 ` [B.A.T.M.A.N.] Basic Multicast Optimizations Simon Wunderlich
2013-05-16 17:42 ` Linus Lüssing
2013-05-16 18:31 ` Simon Wunderlich
2013-05-17 1:38 ` Linus Lüssing
2013-05-17 10:24 ` Simon Wunderlich
-- strict thread matches above, loose matches on Subject: below --
2013-06-10 6:28 Linus Lüssing
2013-06-10 6:28 ` [B.A.T.M.A.N.] [PATCH 2/3] batman-adv: Announce new capability via multicast TVLV 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=20130516181945.GC22374@Linus-Debian \
--to=linus.luessing@web.de \
--cc=b.a.t.m.a.n@lists.open-mesh.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