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 >
next prev parent 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: linkBe 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.