On Sunday 18 November 2012 16:50:32 Alexander Stadler wrote:
> Nobody here to answer the rather simple question? (see below)

I don't think these patches are important enough to trigger a kernel rebuild
for all AA targets, but that is just my opinion.

> 
> On Sa, 10.11.2012, 19:15, Alexander Stadler wrote:
> > Can someone please answer what the criterias for backports into
> > attitude_adjustment are?
> > Jow just closes it as a ticket (https://dev.openwrt.org/ticket/12355).
> > And no response here.
> > Thats not so great for collaboration.
> > In this case I ask because of r33686 and r33687 (r33887), see below.
> >
> > Thanks
> >
> > Alex
> >
> > On Mi, 7.11.2012, 22:38, Alexander Stadler wrote:
> >> 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
> >>
> >
> >
> > _______________________________________________
> > 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
> 
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to