On Thu, 19 Jul 2012 12:51:44 -0400 Neil Horman <nhorman@xxxxxxxxxxxxx> wrote: [...] > > +pf_retrans - INTEGER > + The number of retransmissions that will be attempted on a given path > + before traffic is redirected to an alternate transport (should one > + exist). Note this is distinct from path_max_retrans, as a path that > + passes the pf_retrans threshold can still be used. Its only > + deprioritized when a transmission path is selected by the stack. This > + setting is primarily used to enable fast failover mechanisms without > + having to reduce path_max_retrans to a very low value. See: > + http://www.ietf.org/id/draft-nishida-tsvwg-sctp-failover-05.txt > + for details. Note also that a value of pf_retrans > path_max_retrans > + disables this feature > + > + Default: 0 > + > rto_initial - INTEGER [...] > diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h > index e4652fe..f70726c 100644 > --- a/include/net/sctp/structs.h > +++ b/include/net/sctp/structs.h > @@ -160,6 +160,7 @@ extern struct sctp_globals { > int max_retrans_association; > int max_retrans_path; > int max_retrans_init; > + int pf_retrans; [...] > > + /* This is the partially failed retrans value for the transport > + * and will be initialized from the assocs value. This can be changed > + * using the SCTP_PEER_ADDR_THLDS socket option > + */ > + int pf_retrans; > /* PMTU : The current known path MTU. */ > __u32 pathmtu; > > @@ -1660,6 +1667,8 @@ struct sctp_association { > */ > int max_retrans; > > + int pf_retrans; > + You've documented in one place, but not in the others. I suggest to include references like this /* See the description in struct sctp_transport */ at the two missing places. Nice feature, fbl -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
