All of lore.kernel.org
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, vyasevich@gmail.com, linux-sctp@vger.kernel.org
Subject: Re: [PATCH v5] sctp: be more restrictive in transport selection on bundled sacks
Date: Sat, 30 Jun 2012 08:26:47 -0400	[thread overview]
Message-ID: <20120630122647.GA22647@neilslaptop.think-freely.org> (raw)
In-Reply-To: <20120629.163408.1111786778802302299.davem@davemloft.net>

On Fri, Jun 29, 2012 at 04:34:08PM -0700, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Fri, 29 Jun 2012 16:15:29 -0400
> 
> > +	/* Has this transport moved the ctsn since we last sacked */
> > +	__u32 sack_generation;
> > +
>  ...
> > +		__u32	sack_generation;
> 
> These are __u32 but they only take on the value '1' or '0'.  Please
> use bool and give it a more reasonable name, a name that describes
> how it is really a predicate.
> 
This is wrong.  Its a counter that increments every time we call sctp_make_sack,
so that we can create a unique generation identifier for use in tagging which
transports move ctsn in a given generation.  It saves us from having to iterate
over a list every time we send a sack. 

> > -		struct sctp_association *asoc;
> >  		struct timer_list *timer;
> > -		asoc = pkt->transport->asoc;
> > +		struct sctp_association *asoc = pkt->transport->asoc;
> > +
> 
> Please leave asoc where it was, on the first line.  We encourage
> listing local variables such that the longest lines come first,
> then gradually shorter and short lines.
> 
> > +	/*
> > +	 * Once we have a sack generated, check to see what our sack
> > +	 * generation is, if its 0, reset the transports to 0, and reset
> 
> Please format:
> 
>   /* Like
>    * this.
>    */
> 
> Thanks.
> 
Very well, I'll repost in the next few days
Neil

> 

WARNING: multiple messages have this Message-ID (diff)
From: Neil Horman <nhorman@tuxdriver.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, vyasevich@gmail.com, linux-sctp@vger.kernel.org
Subject: Re: [PATCH v5] sctp: be more restrictive in transport selection on bundled sacks
Date: Sat, 30 Jun 2012 12:26:47 +0000	[thread overview]
Message-ID: <20120630122647.GA22647@neilslaptop.think-freely.org> (raw)
In-Reply-To: <20120629.163408.1111786778802302299.davem@davemloft.net>

On Fri, Jun 29, 2012 at 04:34:08PM -0700, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Fri, 29 Jun 2012 16:15:29 -0400
> 
> > +	/* Has this transport moved the ctsn since we last sacked */
> > +	__u32 sack_generation;
> > +
>  ...
> > +		__u32	sack_generation;
> 
> These are __u32 but they only take on the value '1' or '0'.  Please
> use bool and give it a more reasonable name, a name that describes
> how it is really a predicate.
> 
This is wrong.  Its a counter that increments every time we call sctp_make_sack,
so that we can create a unique generation identifier for use in tagging which
transports move ctsn in a given generation.  It saves us from having to iterate
over a list every time we send a sack. 

> > -		struct sctp_association *asoc;
> >  		struct timer_list *timer;
> > -		asoc = pkt->transport->asoc;
> > +		struct sctp_association *asoc = pkt->transport->asoc;
> > +
> 
> Please leave asoc where it was, on the first line.  We encourage
> listing local variables such that the longest lines come first,
> then gradually shorter and short lines.
> 
> > +	/*
> > +	 * Once we have a sack generated, check to see what our sack
> > +	 * generation is, if its 0, reset the transports to 0, and reset
> 
> Please format:
> 
>   /* Like
>    * this.
>    */
> 
> Thanks.
> 
Very well, I'll repost in the next few days
Neil

> 

  reply	other threads:[~2012-06-30 12:27 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-26 20:31 [PATCH] sctp: be mroe restrictive in transport selection on bundled sacks Neil Horman
2012-06-26 20:31 ` Neil Horman
2012-06-27  4:05 ` David Miller
2012-06-27  4:05   ` David Miller
2012-06-27 10:24   ` Neil Horman
2012-06-27 10:24     ` Neil Horman
2012-06-27 13:20     ` Vlad Yasevich
2012-06-27 13:20       ` Vlad Yasevich
2012-06-27 13:22       ` Neil Horman
2012-06-27 13:22         ` Neil Horman
2012-06-27 14:23 ` [PATCH v2] sctp: be more " Neil Horman
2012-06-27 15:10   ` Vlad Yasevich
2012-06-27 17:28     ` Neil Horman
2012-06-27 19:44       ` Vlad Yasevich
2012-06-27 19:44         ` Vlad Yasevich
2012-06-28 15:33         ` Neil Horman
2012-06-28 15:33           ` Neil Horman
2012-06-28 15:58           ` Vlad Yasevich
2012-06-28 15:58             ` Vlad Yasevich
2012-06-28 18:07             ` Neil Horman
2012-06-28 18:07               ` Neil Horman
2012-06-28 18:22               ` Vlad Yasevich
2012-06-28 18:22                 ` Vlad Yasevich
2012-06-28 18:36                 ` Neil Horman
2012-06-28 18:36                   ` Neil Horman
2012-06-28 20:14                 ` Neil Horman
2012-06-28 20:14                   ` Neil Horman
2012-06-29 16:34 ` [PATCH v3] " Neil Horman
2012-06-29 18:29   ` Vlad Yasevich
2012-06-29 18:43     ` Neil Horman
2012-06-29 19:15       ` Vlad Yasevich
2012-06-29 19:21         ` Neil Horman
2012-06-29 19:24 ` [PATCH v4] " Neil Horman
2012-06-29 19:24   ` Neil Horman
2012-06-29 20:15 ` [PATCH v5] " Neil Horman
2012-06-29 20:15   ` Neil Horman
2012-06-29 20:19   ` Vlad Yasevich
2012-06-29 20:19     ` Vlad Yasevich
2012-06-29 23:34   ` David Miller
2012-06-29 23:34     ` David Miller
2012-06-30 12:26     ` Neil Horman [this message]
2012-06-30 12:26       ` Neil Horman
2012-07-01  0:38       ` David Miller
2012-07-01  0:38         ` David Miller
2012-06-30 13:04 ` [PATCH v6] " Neil Horman
2012-06-30 13:04   ` Neil Horman
2012-07-01  0:39   ` David Miller
2012-07-01  0:39     ` David Miller
2012-07-01  3:17     ` Vlad Yasevich
2012-07-01  3:17       ` Vlad Yasevich
2012-07-01  5:44       ` David Miller
2012-07-01  5:44         ` David Miller
2012-07-01 12:47     ` Neil Horman
2012-07-01 12:47       ` Neil Horman
2012-07-01 21:43       ` David Miller
2012-07-01 21:43         ` David Miller
2012-07-01 23:44         ` Neil Horman
2012-07-01 23:44           ` Neil Horman
2012-07-02 12:25           ` Neil Horman
2012-07-02 12:25             ` Neil Horman
2012-07-03  0:10             ` David Miller
2012-07-03  0:10               ` David Miller
2012-07-03 18:45             ` Jan Ceuleers
2012-07-03 18:45               ` Jan Ceuleers
2012-07-03 23:42               ` Neil Horman
2012-07-03 23:42                 ` Neil Horman

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=20120630122647.GA22647@neilslaptop.think-freely.org \
    --to=nhorman@tuxdriver.com \
    --cc=davem@davemloft.net \
    --cc=linux-sctp@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vyasevich@gmail.com \
    /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.