public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
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

  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