All of lore.kernel.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 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.