public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Marek Lindner <lindner_marek@yahoo.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.] [RFC] batman-adv: turn tt commit code into routing protocol agnostic API
Date: Thu, 26 Apr 2012 13:49:29 +0800	[thread overview]
Message-ID: <201204261349.30120.lindner_marek@yahoo.de> (raw)
In-Reply-To: <20120424131556.GD1015@ritirata.org>


Hi,

> thank you for your effort in improving the TT code :)

I try to make the TT code a better place.  ;-)


> > +	if (hard_iface == primary_if)
> > +		tt_num_changes = tt_append_changes(bat_priv,
> > +						   &hard_iface->packet_buff,
> > +						   &hard_iface->packet_len,
> > +						   BATMAN_OGM_HLEN);
> > +
> > +	if (tt_num_changes > 0)
> > +		batman_ogm_packet->tt_num_changes = tt_num_changes;
> > +	else
> > +		batman_ogm_packet->tt_num_changes = 0;
> 
> Do we really need this if-loop? Am I wrong or tt_num_changes can only be >=
> 0 ?

Right, strictly speaking it is not needed. However, tt_append_changes() is 
defined as returning int, hence the calling function can't rely on this 
assumption.


> > -int tt_changes_fill_buffer(struct bat_priv *bat_priv,
> > -			   unsigned char *buff, int buff_len)
> > +static void tt_realloc_packet_buff(unsigned char **packet_buff,
> > +				   int *packet_buff_len, int min_packet_len,
> > +				   int new_packet_len)
> > +{
> > +	unsigned char *new_buff;
> > +
> > +	new_buff = kmalloc(new_packet_len, GFP_ATOMIC);
> > +
> > +	/* keep old buffer if kmalloc should fail */
> > +	if (new_buff) {
> > +		memcpy(new_buff, *packet_buff, min_packet_len);
> > +		kfree(*packet_buff);
> > +		*packet_buff = new_buff;
> > +		*packet_buff_len = new_packet_len;
> > +	}
> 
> I took quite a while to understand what happens to packet_buff_len if
> kmalloc failed. Actually it correctly stores the "previous" buffer size, so
> the rest of the code will handle kmalloc failures the right way. :)

Actually, this part of the code did not change. Check realloc_packet_buffer() 
in send.c and you will find the same function.


> > +}
> > +
> > +static void tt_prepare_packet_buff(struct bat_priv *bat_priv,
> > +				   unsigned char **packet_buff,
> > +				   int *packet_buff_len, int min_packet_len)
> > +{
> > +	struct hard_iface *primary_if;
> > +	int req_len;
> > +
> > +	primary_if = primary_if_get_selected(bat_priv);
> > +
> > +	req_len = min_packet_len;
> > +	req_len += tt_len((uint8_t)atomic_read(&bat_priv->tt_local_changes));
> 
> This cast is also in the current code. But why not removing it? atomic_t is
> an int, the tt_len() argument too.

No idea why the cast is there. I'll remove it.  :-)


> > +
> > +	/* if we have too many changes for one packet don't send any
> > +	 * and wait for the tt table request which will be fragmented */
> 
> please fix this comment. */ must be on a new line.

Ok, I'll fix it. Just a quick reminder that this is old code as well ..


> > +static int tt_changes_fill_buff(struct bat_priv *bat_priv,
> > +				unsigned char **packet_buff,
> > +				int *packet_buff_len, int min_packet_len)
> > 
> >  {
> > 
> > -	int count = 0, tot_changes = 0;
> > 
> >  	struct tt_change_node *entry, *safe;
> > 
> > +	int count = 0, tot_changes = 0, new_len;
> > +	unsigned char *tt_buff;
> > +
> 
> As suggesting on IRC we should lock the "read and copy procedure".
> I'd call lock() here.
> 
> > +	tt_prepare_packet_buff(bat_priv, packet_buff,
> > +			       packet_buff_len, min_packet_len);
> > 
> > -	if (buff_len > 0)
> > -		tot_changes = buff_len / tt_len(1);
> > +	new_len = *packet_buff_len - min_packet_len;
> > 
> > 
> > 
> > +	tt_buff = *packet_buff + min_packet_len;
> > +
> > +	if (new_len > 0)
> > +		tot_changes = new_len / tt_len(1);
> > 
> >  	spin_lock_bh(&bat_priv->tt_changes_list_lock);
> >  	atomic_set(&bat_priv->tt_local_changes, 0);
> > 
> > @@ -290,7 +339,7 @@ int tt_changes_fill_buffer(struct bat_priv *bat_priv,
> > 
> >  	list_for_each_entry_safe(entry, safe, &bat_priv->tt_changes_list,
> >  	
> >  				 list) {
> >  		
> >  		if (count < tot_changes) {
> > 
> > -			memcpy(buff + tt_len(count),
> > +			memcpy(tt_buff + tt_len(count),
> > 
> >  			       &entry->change, sizeof(struct tt_change));
> >  			
> >  			count++;
> >  		
> >  		}
> 
> and I'd call unlock() after having copied everything to the tt_buff and
> emptied the changes list. Can we directly use
> bat_priv->tt_changes_list_lock ? It seems to be the case :)

I'd rather move the locking into a separate patch to make it easier to trace 
the change.


> > 
> >  	/* all the reset entries have now to be effectively counted as local
> >  	
> >  	 * entries */
> >  	
> >  	atomic_add(changed_num, &bat_priv->num_local_tt);
> >  	tt_local_purge_pending_clients(bat_priv);
> > 
> > +	bat_priv->tt_crc = tt_local_crc(bat_priv);
> > 
> >  	/* Increment the TTVN only once per OGM interval */
> >  	atomic_inc(&bat_priv->ttvn);
> >  	bat_dbg(DBG_TT, bat_priv, "Local changes committed, updating to ttvn
> >  	%u\n",
> >  	
> >  		(uint8_t)atomic_read(&bat_priv->ttvn));
> >  	
> >  	bat_priv->tt_poss_change = false;
> > 
> > +
> > +	/* reset the sending counter */
> > +	atomic_set(&bat_priv->tt_ogm_append_cnt, TT_OGM_APPEND_MAX);
> > +
> > +	return tt_changes_fill_buff(bat_priv, packet_buff,
> > +				    packet_buff_len, packet_min_len);
> > +}
> 
> As you suggested on IRC, we may want to envelop this function with a
> lock/unlock to force exclusive access to the local table and to the event
> list.
>
> We should apply the same lock in tt_local_add()/del() I think.


Why do want to lock tt_changes_fill_buff() and tt_commit_changes() separately? 
We should already lock in tt_commit_changes() because the entire commit has to 
be an atomic operation. Several of the function calls in tt_commit_changes() 
depend on the fact that no client is purged or added while these functions 
run.

Thanks for your comments!

Cheers,
Marek

  reply	other threads:[~2012-04-26  5:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-23  8:35 [B.A.T.M.A.N.] [RFC] batman-adv: turn tt commit code into routing protocol agnostic API Marek Lindner
2012-04-24 13:15 ` Antonio Quartulli
2012-04-26  5:49   ` Marek Lindner [this message]
2012-04-29 17:11     ` Antonio Quartulli

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=201204261349.30120.lindner_marek@yahoo.de \
    --to=lindner_marek@yahoo.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