This and the following patch went into trunk r33686 and r33687 (r33887). What are the criterias for backports into attitude_adjustment? I'm asking because some make it into there directly and if this went upstream i thought its going to be a canditate soon.
Thanks! Alex On Mo, 1.10.2012, 17:49, Dave Täht wrote: > From: Dave Taht <[email protected]> > > Bugfix from linux head - don't delay acks from ECN congestion > experienced in some situations. > --- > ...net-next-tcp-ecn-dont-delay-ACKS-after-CE.patch | 63 > ++++++++++++++++++++ > 1 file changed, 63 insertions(+) > create mode 100644 > target/linux/generic/patches-3.3/050-net-next-tcp-ecn-dont-delay-ACKS-after-CE.patch > > diff --git > a/target/linux/generic/patches-3.3/050-net-next-tcp-ecn-dont-delay-ACKS-after-CE.patch > b/target/linux/generic/patches-3.3/050-net-next-tcp-ecn-dont-delay-ACKS-after-CE.patch > new file mode 100644 > index 0000000..547e4fa > --- /dev/null > +++ > b/target/linux/generic/patches-3.3/050-net-next-tcp-ecn-dont-delay-ACKS-after-CE.patch > @@ -0,0 +1,63 @@ > +From patchwork Mon Aug 6 21:04:43 2012 > +Content-Type: text/plain; charset="utf-8" > +MIME-Version: 1.0 > +Content-Transfer-Encoding: 7bit > +Subject: [net-next] tcp: ecn: dont delay ACKS after CE > +Date: Mon, 06 Aug 2012 11:04:43 -0000 > +From: Eric Dumazet <[email protected]> > +X-Patchwork-Id: 175453 > +Message-Id: <1344287083.26674.83.camel@edumazet-glaptop> > +To: David Miller <[email protected]> > +Cc: netdev <[email protected]>, > + Neal Cardwell <[email protected]> > + > +From: Eric Dumazet <[email protected]> > + > +While playing with CoDel and ECN marking, I discovered a > +non optimal behavior of receiver of CE (Congestion Encountered) > +segments. > + > +In pathological cases, sender has reduced its cwnd to low values, > +and receiver delays its ACK (by 40 ms). > + > +While RFC 3168 6.1.3 (The TCP Receiver) doesn't explicitly recommend > +to send immediate ACKS, we believe its better to not delay ACKS, because > +a CE segment should give same signal than a dropped segment, and its > +quite important to reduce RTT to give ECE/CWR signals as fast as > +possible. > + > +Note we already call tcp_enter_quickack_mode() from TCP_ECN_check_ce() > +if we receive a retransmit, for the same reason. > + > +Signed-off-by: Eric Dumazet <[email protected]> > +Cc: Neal Cardwell <[email protected]> > +Acked-by: Neal Cardwell <[email protected]> > + > +--- > +net/ipv4/tcp_input.c | 6 +++++- > + 1 file changed, 5 insertions(+), 1 deletion(-) > + > + > + > +-- > +To unsubscribe from this list: send the line "unsubscribe netdev" in > +the body of a message to [email protected] > +More majordomo info at http://vger.kernel.org/majordomo-info.html > + > +diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c > +index 2fd2bc9..fa2c2c2 100644 > +--- a/net/ipv4/tcp_input.c > ++++ b/net/ipv4/tcp_input.c > +@@ -237,7 +237,11 @@ static inline void TCP_ECN_check_ce(struct tcp_sock > *tp, const struct sk_buff *s > + tcp_enter_quickack_mode((struct sock *)tp); > + break; > + case INET_ECN_CE: > +- tp->ecn_flags |= TCP_ECN_DEMAND_CWR; > ++ if (!(tp->ecn_flags & TCP_ECN_DEMAND_CWR)) { > ++ /* Better not delay acks, sender can have a very low > cwnd */ > ++ tcp_enter_quickack_mode((struct sock *)tp); > ++ tp->ecn_flags |= TCP_ECN_DEMAND_CWR; > ++ } > + /* fallinto */ > + default: > + tp->ecn_flags |= TCP_ECN_SEEN; > -- > 1.7.9.5 > > _______________________________________________ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
