Re: [PATCH v3 net-next 4/4] tcp: implement coalescing on backlog queue

2018-11-28 Thread Neal Cardwell
ut increase on a receiver > without GRO, but the spectacular gain is really on > 1000x release_sock() latency reduction I have measured. > > Signed-off-by: Eric Dumazet > Cc: Neal Cardwell > Cc: Yuchung Cheng > --- Acked-by: Neal Cardwell Thanks! neal

Re: [PATCH v3 net-next 2/4] tcp: take care of compressed acks in tcp_add_reno_sack()

2018-11-28 Thread Neal Cardwell
t; account how many ACK were coalesced, this information > will be available in skb_shinfo(skb)->gso_segs > > Signed-off-by: Eric Dumazet > --- Acked-by: Neal Cardwell Thanks! neal

Re: [PATCH v2 net-next 4/4] tcp: implement coalescing on backlog queue

2018-11-27 Thread Neal Cardwell
ut increase on a receiver > without GRO, but the spectacular gain is really on > 1000x release_sock() latency reduction I have measured. > > Signed-off-by: Eric Dumazet > Cc: Neal Cardwell > Cc: Yuchung Cheng > --- ... > + if (TCP_SKB_CB(tail)->end_seq != TCP_SKB_CB(skb)-&g

Re: [PATCH v2 net-next 3/4] tcp: make tcp_space() aware of socket backlog

2018-11-27 Thread Neal Cardwell
situation. > > Reported-by: Jean-Louis Dupond > Signed-off-by: Eric Dumazet > --- Acked-by: Neal Cardwell Nice. Thanks! neal

Re: [PATCH v2 net-next 2/4] tcp: take care of compressed acks in tcp_add_reno_sack()

2018-11-27 Thread Neal Cardwell
On Tue, Nov 27, 2018 at 10:57 AM Eric Dumazet wrote: > > Neal pointed out that non sack flows might suffer from ACK compression > added in the following patch ("tcp: implement coalescing on backlog queue") > > Instead of tweaking tcp_add_backlog() we can take into > account how many ACK were

Re: [PATCH v2 net-next 1/4] tcp: hint compiler about sack flows

2018-11-27 Thread Neal Cardwell
On Tue, Nov 27, 2018 at 10:57 AM Eric Dumazet wrote: > > Tell the compiler that most TCP flows are using SACK these days. > > There is no need to add the unlikely() clause in tcp_is_reno(), > the compiler is able to infer it. > > Signed-off-by: Eric Dumazet > --- Acked-

Re: [PATCH net-next 2/3] tcp: implement coalescing on backlog queue

2018-11-22 Thread Neal Cardwell
On Wed, Nov 21, 2018 at 12:52 PM Eric Dumazet wrote: > > In case GRO is not as efficient as it should be or disabled, > we might have a user thread trapped in __release_sock() while > softirq handler flood packets up to the point we have to drop. > > This patch balances work done from user thread

Re: [PATCH net-next 3/3] tcp: get rid of tcp_tso_should_defer() dependency on HZ/jiffies

2018-11-11 Thread Neal Cardwell
reduces bursts for HZ=100 or HZ=250 kernels, making TCP > behavior more uniform. > > Signed-off-by: Eric Dumazet > Acked-by: Soheil Hassas Yeganeh > --- Nice. Thanks! Acked-by: Neal Cardwell neal

Re: [PATCH net-next 2/3] tcp: refine tcp_tso_should_defer() after EDT adoption

2018-11-11 Thread Neal Cardwell
cs to avoid overflows. > > Signed-off-by: Eric Dumazet > Acked-by: Soheil Hassas Yeganeh > --- > net/ipv4/tcp_output.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) Thanks! Acked-by: Neal Cardwell neal

Re: [PATCH net-next 1/3] tcp: do not try to defer skbs with eor mark (MSG_EOR)

2018-11-11 Thread Neal Cardwell
t; > Signed-off-by: Eric Dumazet > Acked-by: Soheil Hassas Yeganeh > --- > net/ipv4/tcp_output.c | 4 > 1 file changed, 4 insertions(+) Thanks! Acked-by: Neal Cardwell neal

Re: [PATCH net-next] net_sched: sch_fq: add dctcp-like marking

2018-11-11 Thread Neal Cardwell
t fq ce_threshold 2.5ms > > Signed-off-by: Eric Dumazet > --- Very nice! Thanks, Eric. :-) Acked-by: Neal Cardwell neal

[PATCH net-next] tcp_bbr: update comments to reflect pacing_margin_percent

2018-11-08 Thread Neal Cardwell
pdate an old comment to reflect the new approach. Signed-off-by: Neal Cardwell Signed-off-by: Yuchung Cheng Signed-off-by: Soheil Hassas Yeganeh Signed-off-by: Eric Dumazet --- net/ipv4/tcp_bbr.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/net/ipv4/

[PATCH net-next 2/2] tcp_bbr: centralize code to set gains

2018-10-16 Thread Neal Cardwell
Centralize the code that sets gains used for computing cwnd and pacing rate. This simplifies the code and makes it easier to change the state machine or (in the future) dynamically change the gain values and ensure that the correct gain values are always used. Signed-off-by: Neal Cardwell Signed

[PATCH net-next 0/2] tcp_bbr: TCP BBR changes for EDT pacing model

2018-10-16 Thread Neal Cardwell
second patch adjusts the TCP BBR logic to centralize the setting of gain values, to simplify the code and prepare for future changes. Neal Cardwell (2): tcp_bbr: adjust TCP BBR for departure time pacing tcp_bbr: centralize code to set gains net/ipv4/tcp_bbr.c | 77 +

[PATCH net-next 1/2] tcp_bbr: adjust TCP BBR for departure time pacing

2018-10-16 Thread Neal Cardwell
ng in_network down (pacing_gain < 1.0), then in_network goes below target upon an ACK event This commit changes the BBR state machine to use this estimated "packets in network" value to make its decisions. Signed-off-by: Neal Cardwell Signed-off-by: Yuchung Cheng Signed-off-by: Eric D

Re: Why not use all the syn queues? in the function "tcp_conn_request", I have some questions.

2018-09-08 Thread Neal Cardwell
On Sat, Sep 8, 2018 at 11:23 AM Ttttabcd wrote: > > Thank you very much for your previous answer, sorry for the inconvenience. > > But now I want to ask you one more question. > > The question is why we need two variables to control the syn queue? > > The first is the "backlog" parameter of the

Re: Why not use all the syn queues? in the function "tcp_conn_request", I have some questions.

2018-09-04 Thread Neal Cardwell
On Tue, Sep 4, 2018 at 1:48 AM Ttttabcd wrote: > > Hello everyone,recently I am looking at the source code for handling TCP > three-way handshake(Linux Kernel version 4.18.5). > > I found some strange places in the source code for handling syn messages. > > in the function "tcp_conn_request" > >

[PATCH net] tcp_bbr: fix bw probing to raise in-flight data for very small BDPs

2018-07-27 Thread Neal Cardwell
ngestion control") Signed-off-by: Neal Cardwell Acked-by: Yuchung Cheng Acked-by: Soheil Hassas Yeganeh Acked-by: Priyaranjan Jha Reviewed-by: Eric Dumazet --- net/ipv4/tcp_bbr.c | 4 1 file changed, 4 insertions(+) diff --git a/net/ipv4/tcp_bbr.c b/net/ipv4/tcp_bbr.c index

Re: [PATCH net-next] tcp: ack immediately when a cwr packet arrives

2018-07-24 Thread Neal Cardwell
On Tue, Jul 24, 2018 at 1:42 PM Lawrence Brakmo wrote: > > Note that without this fix the 99% latencies when doing 10KB RPCs > in a congested network using DCTCP are 40ms vs. 190us with the patch. > Also note that these 40ms high tail latencies started after commit >

Re: [PATCH net-next] tcp: ack immediately when a cwr packet arrives

2018-07-24 Thread Neal Cardwell
On Tue, Jul 24, 2018 at 1:07 PM Yuchung Cheng wrote: > > On Mon, Jul 23, 2018 at 7:23 PM, Daniel Borkmann wrote: > > Should this go to net tree instead where all the other fixes went? > I am neutral but this feels more like a feature improvement I agree this feels like a feature improvement

Re: [PATCH net-next] tcp: ack immediately when a cwr packet arrives

2018-07-23 Thread Neal Cardwell
. > Modified based on comments by Neal Cardwell > > Signed-off-by: Lawrence Brakmo > --- > net/ipv4/tcp_input.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) Seems like a nice mechanism to have, IMHO. Acked-by: Neal Cardwell Thanks! neal

Re: [PATCH net-next] tcp: expose both send and receive intervals for rate sample

2018-07-09 Thread Neal Cardwell
nding. It does seem to be showing up in patchwork now: https://patchwork.ozlabs.org/patch/941532/ And I can confirm I'm able to apply it to net-next. Acked-by: Neal Cardwell thanks, neal

Re: [PATCH net-next v3 0/2] tcp: fix high tail latencies in DCTCP

2018-07-07 Thread Neal Cardwell
p 99.9% > > 1MB RPCs2.6ms 5.5ms 43ms 208ms > > 10KB RPCs1.1ms 1.3ms 53ms 212ms > ... > > v2: Removed call to tcp_ca_event from tcp_send_ack since I added one in > > tcp_event_ack_sent. Based on Neal Cardwell > >

Re: [PATCH net-next v2 0/2] tcp: fix high tail latencies in DCTCP

2018-07-03 Thread Neal Cardwell
On Tue, Jul 3, 2018 at 11:10 AM Lawrence Brakmo wrote: > > On 7/2/18, 5:52 PM, "netdev-ow...@vger.kernel.org on behalf of Neal Cardwell" > wrote: > > On Mon, Jul 2, 2018 at 5:39 PM Lawrence Brakmo wrote: > > > > When have observed high tai

Re: [PATCH net-next v2 1/2] tcp: notify when a delayed ack is sent

2018-07-03 Thread Neal Cardwell
On Mon, Jul 2, 2018 at 7:49 PM Yuchung Cheng wrote: > > On Mon, Jul 2, 2018 at 2:39 PM, Lawrence Brakmo wrote: > > > > DCTCP depends on the CA_EVENT_NON_DELAYED_ACK and CA_EVENT_DELAYED_ACK > > notifications to keep track if it needs to send an ACK for packets that > > were received with a

Re: [PATCH net-next v2 0/2] tcp: fix high tail latencies in DCTCP

2018-07-02 Thread Neal Cardwell
t should be enough. This should reduce the extra load noticed in DCTCP environments, after congestion events. This is part 2 of our effort to reduce pure ACK packets. Signed-off-by: Eric Dumazet Acked-by: Soheil Hassas Yeganeh Acked-by: Yuchung Cheng

Re: [PATCH net-next 1/2] tcp: notify when a delayed ack is sent

2018-07-02 Thread Neal Cardwell
On Fri, Jun 29, 2018 at 9:48 PM Lawrence Brakmo wrote: > > DCTCP depends on the CA_EVENT_NON_DELAYED_ACK and CA_EVENT_DELAYED_ACK > notifications to keep track if it needs to send an ACK for packets that > were received with a particular ECN state but whose ACK was delayed. > > Under some

Re: [PATCH net-next 2/2] tcp: ack immediately when a cwr packet arrives

2018-07-02 Thread Neal Cardwell
On Sat, Jun 30, 2018 at 9:47 PM Lawrence Brakmo wrote: > I see two issues, one is that entering quickack mode as you > mentioned does not insure that it will still be on when the CWR > arrives. The second issue is that the problem occurs right after the > receiver sends a small reply which

Re: [PATCH net] tcp: prevent bogus FRTO undos with non-SACK flows

2018-06-30 Thread Neal Cardwell
ACK later (when we get an ACK that doesn't cover a retransmit). But that seems fine to me. I also cooked the new packetdrill test below to explicitly cover this case you are addressing (please let me know if you have an alternate suggestion). Tested-by: Neal Cardwell Acked-by: Neal Cardwell

Re: [PATCH net-next 0/2] tcp: fix high tail latencies in DCTCP

2018-06-30 Thread Neal Cardwell
On Fri, Jun 29, 2018 at 9:48 PM Lawrence Brakmo wrote: > > When have observed high tail latencies when using DCTCP for RPCs as > compared to using Cubic. For example, in one setup there are 2 hosts > sending to a 3rd one, with each sender having 3 flows (1 stream, > 1 1MB back-to-back RPCs and 1

Re: [PATCH net-next 2/2] tcp: ack immediately when a cwr packet arrives

2018-06-30 Thread Neal Cardwell
On Fri, Jun 29, 2018 at 9:48 PM Lawrence Brakmo wrote: > > We observed high 99 and 99.9% latencies when doing RPCs with DCTCP. The > problem is triggered when the last packet of a request arrives CE > marked. The reply will carry the ECE mark causing TCP to shrink its cwnd > to 1 (because there

Re: [PATCH net] tcp: prevent bogus FRTO undos with non-SACK flows

2018-06-29 Thread Neal Cardwell
On Fri, Jun 29, 2018 at 6:07 AM Ilpo Järvinen wrote: > > If SACK is not enabled and the first cumulative ACK after the RTO > retransmission covers more than the retransmitted skb, a spurious > FRTO undo will trigger (assuming FRTO is enabled for that RTO). > The reason is that any

Re: [PATCH net-next v2] tcp: force cwnd at least 2 in tcp_cwnd_reduction

2018-06-28 Thread Neal Cardwell
On Thu, Jun 28, 2018 at 4:20 PM Lawrence Brakmo wrote: > > I just looked at 4.18 traces and the behavior is as follows: > >Host A sends the last packets of the request > >Host B receives them, and the last packet is marked with congestion (CE) > >Host B sends ACKs for packets not

Re: [PATCH net] tcp: add one more quick ack after after ECN events

2018-06-27 Thread Neal Cardwell
d-off-by: Eric Dumazet > Reported-by: Neal Cardwell > Cc: Lawrence Brakmo > --- > net/ipv4/tcp_input.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Acked-by: Neal Cardwell Thanks, Eric! neal

Re: [PATCH net-next v2] tcp: force cwnd at least 2 in tcp_cwnd_reduction

2018-06-27 Thread Neal Cardwell
On Tue, Jun 26, 2018 at 10:34 PM Lawrence Brakmo wrote: > The only issue is if it is safe to always use 2 or if it is better to > use min(2, snd_ssthresh) (which could still trigger the problem). Always using 2 SGTM. I don't think we need min(2, snd_ssthresh), as that should be the same as just

Re: [PATCH net-next] tcp: remove one indentation level in tcp_create_openreq_child

2018-06-26 Thread Neal Cardwell
On Tue, Jun 26, 2018 at 11:46 AM Eric Dumazet wrote: > > Signed-off-by: Eric Dumazet > --- > net/ipv4/tcp_minisocks.c | 223 --- > 1 file changed, 113 insertions(+), 110 deletions(-) Yes, very nice clean-up! Thanks for doing this. Acked-by

Re: [PATCH net] sctp: not allow to set rto_min with a value below 200 msecs

2018-05-29 Thread Neal Cardwell
On Tue, May 29, 2018 at 11:45 AM Marcelo Ricardo Leitner < marcelo.leit...@gmail.com> wrote: > - patch2 - fix rtx attack vector >- Add the floor value to rto_min to HZ/20 (which fits the values > that Michael shared on the other email) I would encourage allowing minimum RTO values down

Re: [PATCH net-next 1/2] tcp: add max_quickacks param to tcp_incr_quickack and tcp_enter_quickack_mode

2018-05-22 Thread Neal Cardwell
On Tue, May 22, 2018 at 8:31 PM kbuild test robot wrote: > Hi Eric, > Thank you for the patch! Yet something to improve: > [auto build test ERROR on net/master] > [also build test ERROR on v4.17-rc6 next-20180517] > [cannot apply to net-next/master] > [if your patch is applied

Re: [PATCH net-next 2/2] tcp: do not aggressively quick ack after ECN events

2018-05-22 Thread Neal Cardwell
rent packet should be enough. > This should reduce the extra load noticed in DCTCP environments, > after congestion events. > This is part 2 of our effort to reduce pure ACK packets. > Signed-off-by: Eric Dumazet <eduma...@google.com> > --- Acked-by: Neal Cardwell <ncardw...@google.com> Thanks! neal

Re: [PATCH net-next 1/2] tcp: add max_quickacks param to tcp_incr_quickack and tcp_enter_quickack_mode

2018-05-22 Thread Neal Cardwell
<eduma...@google.com> > --- Acked-by: Neal Cardwell <ncardw...@google.com> Thanks! neal

Re: [PATCH v3 net-next 6/6] tcp: add tcp_comp_sack_nr sysctl

2018-05-17 Thread Neal Cardwell
t;eduma...@google.com> > --- Acked-by: Neal Cardwell <ncardw...@google.com> Thanks! neal

Re: [PATCH v3 net-next 5/6] tcp: add tcp_comp_sack_delay_ns sysctl

2018-05-17 Thread Neal Cardwell
On Thu, May 17, 2018 at 5:47 PM Eric Dumazet <eduma...@google.com> wrote: > This per netns sysctl allows for TCP SACK compression fine-tuning. > Its default value is 1,000,000, or 1 ms to meet TSO autosizing period. > Signed-off-by: Eric Dumazet <eduma...@google.com>

Re: [PATCH v3 net-next 3/6] tcp: add SACK compression

2018-05-17 Thread Neal Cardwell
t > expired. > A new SNMP counter is added in the following patch. > Two other patches add sysctls to allow changing the 1,000,000 and 44 > values that this commit hard-coded. > Signed-off-by: Eric Dumazet <eduma...@google.com> > --- Very nice. I like the constants and the min(rcv_rtt, srtt). Acked-by: Neal Cardwell <ncardw...@google.com> Thanks! neal

Re: [PATCH net-next 3/4] tcp: add SACK compression

2018-05-17 Thread Neal Cardwell
On Thu, May 17, 2018 at 11:40 AM Eric Dumazet <eric.duma...@gmail.com> wrote: > On 05/17/2018 08:14 AM, Neal Cardwell wrote: > > Is there a particular motivation for the cap of 127? IMHO 127 ACKs is quite > > a few to compress. Experience seems to show that it works well to

Re: [PATCH net-next 3/4] tcp: add SACK compression

2018-05-17 Thread Neal Cardwell
On Thu, May 17, 2018 at 8:12 AM Eric Dumazet wrote: > When TCP receives an out-of-order packet, it immediately sends > a SACK packet, generating network load but also forcing the > receiver to send 1-MSS pathological packets, increasing its > RTX queue length/depth, and thus

Re: [PATCH net-next 2/4] tcp: do not force quickack when receiving out-of-order packets

2018-05-17 Thread Neal Cardwell
but also > because of ACK compression or losses. > We plan to add SACK compression in the following patch, we > must therefore not call tcp_enter_quickack_mode() > Signed-off-by: Eric Dumazet <eduma...@google.com> > --- Acked-by: Neal Cardwell <ncardw...@google.com> Thanks! neal

Re: [PATCH net-next 4/4] tcp: add TCPAckCompressed SNMP counter

2018-05-17 Thread Neal Cardwell
d 119252 0.0 > Signed-off-by: Eric Dumazet <eduma...@google.com> > --- Acked-by: Neal Cardwell <ncardw...@google.com> Thanks! neal

Re: [PATCH net-next 1/4] tcp: use __sock_put() instead of sock_put() in tcp_clear_xmit_timers()

2018-05-17 Thread Neal Cardwell
On Thu, May 17, 2018 at 8:12 AM Eric Dumazet <eduma...@google.com> wrote: > Socket can not disappear under us. > Signed-off-by: Eric Dumazet <eduma...@google.com> > --- Acked-by: Neal Cardwell <ncardw...@google.com> Thanks! neal

Re: [PATCH net] tcp: purge write queue in tcp_connect_init()

2018-05-15 Thread Neal Cardwell
com> > Cc: Yuchung Cheng <ych...@google.com> > Cc: Neal Cardwell <ncardw...@google.com> > Reported-by: syzbot <syzkal...@googlegroups.com> > --- Acked-by: Neal Cardwell <ncardw...@google.com> Thanks, Eric! neal

Re: [PATCH net] tcp: restore autocorking

2018-05-03 Thread Neal Cardwell
;tcp: implement rb-tree based retransmit queue") > Signed-off-by: Eric Dumazet <eduma...@google.com> > Reported-by: Michael Wenig <mwe...@vmware.com> > Tested-by: Michael Wenig <mwe...@vmware.com> > --- Acked-by: Neal Cardwell <ncardw...@google.com> Nice. Thanks, Eric! neal

[PATCH net] tcp_bbr: fix to zero idle_restart only upon S/ACKed data

2018-05-01 Thread Neal Cardwell
arting). This commit is a stable candidate for kernels back as far as 4.9. Fixes: 0f8782ea1497 ("tcp_bbr: add BBR congestion control") Signed-off-by: Neal Cardwell <ncardw...@google.com> Signed-off-by: Yuchung Cheng <ych...@google.com> Signed-off-by: Soheil Hassas Yeganeh &l

Re: [PATCH net-next] tcp: remove mss check in tcp_select_initial_window()

2018-04-26 Thread Neal Cardwell
> (wscale is 11), we see the connection gets recvbuf limited at the > beginning of the connection and gets less throughput overall. > Signed-off-by: Wei Wang <wei...@google.com> > Acked-by: Eric Dumazet <eduma...@google.com> > Acked-by: Soheil Hassas Yeganeh <soh...@goog

packetdrill 2.0 release

2018-04-24 Thread Neal Cardwell
Hi All, We're happy to announce the 2.0 release of the Google version of the packetdrill network testing tool. The code may be found at the packetdrill-v2.0 tag in the Google packetdrill github repo: https://github.com/google/packetdrill The commit is here:

Re: [PATCH v3 net 2/5] tcp: prevent bogus FRTO undos with non-SACK flows

2018-04-04 Thread Neal Cardwell
On Wed, Apr 4, 2018 at 1:41 PM Yuchung Cheng <ych...@google.com> wrote: > On Wed, Apr 4, 2018 at 10:22 AM, Neal Cardwell <ncardw...@google.com> wrote: > > n Wed, Apr 4, 2018 at 1:13 PM Yuchung Cheng <ych...@google.com> wrote: > >> Agreed. That's a good point.

Re: [PATCH v3 net 2/5] tcp: prevent bogus FRTO undos with non-SACK flows

2018-04-04 Thread Neal Cardwell
n Wed, Apr 4, 2018 at 1:13 PM Yuchung Cheng wrote: > Agreed. That's a good point. And I would much preferred to rename that > to FLAG_ORIG_PROGRESS (w/ updated comment). > so I think we're in agreement to use existing patch w/ the new name > FLAG_ORIG_PROGRESS Yes, SGTM. I

Re: [PATCH v3 net 1/5] tcp: feed correct number of pkts acked to cc modules also in recovery

2018-04-04 Thread Neal Cardwell
On Wed, Apr 4, 2018 at 6:42 AM Ilpo Järvinen wrote: > On Wed, 28 Mar 2018, Yuchung Cheng wrote: ... > > Your patch looks good. Some questions / comments: The patch looks good to me as well (I read the Mar 28 version). Thanks for this fix, Ilpo. > Just to be sure that

Re: [PATCH v3 net 2/5] tcp: prevent bogus FRTO undos with non-SACK flows

2018-04-04 Thread Neal Cardwell
On Wed, Apr 4, 2018 at 6:35 AM Ilpo Järvinen wrote: > On Wed, 28 Mar 2018, Yuchung Cheng wrote: > > On Tue, Mar 13, 2018 at 3:25 AM, Ilpo Järvinen > > wrote: > > > > > > If SACK is not enabled and the first cumulative ACK after the RTO > >

Re: SO_TCP_NODELAY implementation in TCP stack

2018-04-02 Thread Neal Cardwell
On Sun, Apr 1, 2018 at 4:06 AM Naruto Nguyen wrote: > Hello everyone, > As I know we have a socket option SO_TCP_NODELAY to disable Nagle > Algorithm, and I found it is implemented in TCP/IP stack at >

Re: [PATCH net 4/5] tcp: prevent bogus undos when SACK is not enabled

2018-03-07 Thread Neal Cardwell
On Wed, Mar 7, 2018 at 7:59 AM, Ilpo Järvinen wrote: > A bogus undo may/will trigger when the loss recovery state is > kept until snd_una is above high_seq. If tcp_any_retrans_done > is zero, retrans_stamp is cleared in this transient state. On > the next ACK,

Re: [PATCH net 2/5] tcp: prevent bogus FRTO undos with non-SACK flows

2018-03-07 Thread Neal Cardwell
On Wed, Mar 7, 2018 at 7:59 AM, Ilpo Järvinen wrote: > > In a non-SACK case, any non-retransmitted segment acknowledged will > set FLAG_ORIG_SACK_ACKED in tcp_clean_rtx_queue even if there is > no indication that it would have been delivered for real (the > scoreboard

Re: [PATCH net-next 2/2] tcp_bbr: remove bbr->tso_segs_goal

2018-02-28 Thread Neal Cardwell
On Wed, Feb 28, 2018 at 5:40 PM, Eric Dumazet <eduma...@google.com> wrote: > Its value is computed then immediately used, > there is no need to store it. > > Signed-off-by: Eric Dumazet <eduma...@google.com> > --- Acked-by: Neal Cardwell <ncardw...@google.com>

Re: [PATCH net-next 1/2] tcp_bbr: better deal with suboptimal GSO (II)

2018-02-28 Thread Neal Cardwell
) for CC wanting to override sysctl_tcp_min_tso_segs > > Next patch will remove bbr->tso_segs_goal since it does not have > to be persistent. > > Signed-off-by: Eric Dumazet <eduma...@google.com> > --- Acked-by: Neal Cardwell <ncardw...@google.com> Looks great to me. Thanks, Eric! neal

Re: [PATCH net] tcp: restrict F-RTO to work-around broken middle-boxes

2018-02-21 Thread Neal Cardwell
On Wed, Feb 21, 2018 at 7:38 AM, Teodor Milkov wrote: > Here they are: > > > http://vps3.avodz.org/tmp/frto-4.14.11-linux.pcap.xz - 3.3 MB/s > > http://vps3.avodz.org/tmp/frto-4.14.11-windows.pcap.xz - connection > completely froze and eventually timed out > >

Re: [PATCH net] tcp_bbr: better deal with suboptimal GSO

2018-02-21 Thread Neal Cardwell
>1746 >1781 >1718 > > Fixes: 0f8782ea1497 ("tcp_bbr: add BBR congestion control") > Signed-off-by: Eric Dumazet <eduma...@google.com> > Reported-by: Oleksandr Natalenko <oleksa...@natalenko.name> > --- > net/ipv4/tcp_output.c |9 + > 1 file changed, 5 insertions(+), 4 deletions(-) Acked-by: Neal Cardwell <ncardw...@google.com> Thanks, Eric! neal

Re: [PATCH net] tcp: restrict F-RTO to work-around broken middle-boxes

2018-02-19 Thread Neal Cardwell
On Mon, Feb 19, 2018 at 11:17 AM, Teodor Milkov <t...@del.bg> wrote: > On 19.02.2018 15:38, Neal Cardwell wrote: >> >> On Sun, Feb 18, 2018 at 4:02 PM, Teodor Milkov <t...@del.bg> wrote: >>> >>> Hello, >>> >>> I've numerous re

Re: [PATCH net] tcp: restrict F-RTO to work-around broken middle-boxes

2018-02-19 Thread Neal Cardwell
On Sun, Feb 18, 2018 at 4:02 PM, Teodor Milkov wrote: > Hello, > > I've numerous reports from Windows users that after kernel upgrade from 4.9 > to 4.14 they experienced major slow downs and transfer stalls. > > After some digging, I found that the slowness starts with this commit: >

Re: TCP and BBR: reproducibly low cwnd and bandwidth

2018-02-16 Thread Neal Cardwell
On Fri, Feb 16, 2018 at 11:26 AM, Holger Hoffstätte wrote: > > BBR in general will run with lower cwnd than e.g. Cubic or others. > That's a feature and necessary for WAN transfers. Please note that there's no general rule about whether BBR will run with a lower or

Re: TCP and BBR: reproducibly low cwnd and bandwidth

2018-02-16 Thread Neal Cardwell
On Fri, Feb 16, 2018 at 11:43 AM, Eric Dumazet <eduma...@google.com> wrote: > > On Fri, Feb 16, 2018 at 8:33 AM, Neal Cardwell <ncardw...@google.com> wrote: > > Oleksandr, > > > > Thanks for the detailed report! Yes, this sounds like an issue in BBR. We > &

[PATCH net] tcp_bbr: fix pacing_gain to always be unity when using lt_bw

2018-01-31 Thread Neal Cardwell
for kernels back as far as 4.9. Fixes: 0f8782ea1497 ("tcp_bbr: add BBR congestion control") Signed-off-by: Neal Cardwell <ncardw...@google.com> Signed-off-by: Yuchung Cheng <ych...@google.com> Signed-off-by: Soheil Hassas Yeganeh <soh...@google.com> Reported-by: Beyers Cronje

Re: [PATCH net] bpf: always re-init the congestion control after switching to it

2018-01-23 Thread Neal Cardwell
On Tue, Jan 23, 2018 at 2:20 PM, Lawrence Brakmo wrote: > On 1/23/18, 9:30 AM, "Yuchung Cheng" wrote: > > The original patch that changes TCP's congestion control via eBPF only > re-initializes the new congestion control, if the BPF op is set to an >

Re: Linux ECN Handling

2018-01-03 Thread Neal Cardwell
On Tue, Jan 2, 2018 at 6:57 PM, Steve Ibanez wrote: > Hi Neal, > > Sorry, my last email was incorrect. It turns out the default tcp > congestion control alg that was being used on my client machines was > cubic instead of dctcp. That is why tp->processing_cwr field was never

Re: Linux ECN Handling

2018-01-02 Thread Neal Cardwell
On Tue, Jan 2, 2018 at 2:43 AM, Steve Ibanez wrote: > Hi Neal, > > Apologies for the delay, and happy new year! > > To answer your question, data is only transferred in one direction > (from the client to the server). The SeqNo in the pkts from the server > to the client is

Re: Linux ECN Handling

2017-12-20 Thread Neal Cardwell
On Wed, Dec 20, 2017 at 2:20 PM, Steve Ibanez wrote: > > Hi Neal, > > I added in some more printk statements and it does indeed look like > all of these calls you listed are being invoked successfully. I guess > this isn't too surprising given what the

Re: Linux ECN Handling

2017-12-19 Thread Neal Cardwell
On Tue, Dec 19, 2017 at 5:00 PM, Steve Ibanez wrote: > Hi Neal, > > I managed to track down the code path that the unACKed CWR packet is > taking. The tcp_rcv_established() function calls tcp_ack_snd_check() > at the end of step5 and then the return statement indicated below

Re: Linux ECN Handling

2017-12-19 Thread Neal Cardwell
On Tue, Dec 19, 2017 at 12:16 AM, Steve Ibanez wrote: > > Hi Neal, > > I started looking into this receiver ACKing issue today. Strangely, > when I tried adding printk statements at the top of the > tcp_v4_do_rcv(), tcp_rcv_established(), __tcp_ack_snd_check() and >

Re: [PATCH iproute2 1/1] ss: add missing path MTU parameter

2017-12-14 Thread Neal Cardwell
On Thu, Dec 14, 2017 at 2:23 PM, Roman Mashak wrote: > > Signed-off-by: Roman Mashak > --- ... > @@ -1967,6 +1968,8 @@ static void tcp_stats_print(struct tcpstat *s) > printf(" cwnd:%u", s->cwnd); > if (s->ssthresh) >

Re: [PATCH net] tcp: fix potential underestimation on rcv_rtt

2017-12-13 Thread Neal Cardwell
n. > Fix it by always using a min value of 1ms if ms timestamp is used. > > Fixes: 645f4c6f2ebd ("tcp: switch rcv_rtt_est and rcvq_space to high > resolution timestamps") > > Signed-off-by: Wei Wang <wei...@google.com> > Signed-off-by: Eric Dumazet <eduma.

Re: [PATCH net] tcp: refresh tcp_mstamp from timers callbacks

2017-12-12 Thread Neal Cardwell
;soh...@google.com> > Cc: Mike Maloney <malo...@google.com> > Cc: Neal Cardwell <ncardw...@google.com> > --- Acked-by: Neal Cardwell <ncardw...@google.com> Thanks, Eric! neal

Re: [PATCH net-next 3/3] tcp: smoother receiver autotuning

2017-12-11 Thread Neal Cardwell
t; Signed-off-by: Eric Dumazet <eduma...@google.com> > Acked-by: Soheil Hassas Yeganeh <soh...@google.com> > Acked-by: Wei Wang <wei...@google.com> > --- Acked-by: Neal Cardwell <ncardw...@google.com> Thanks, Eric! neal

Re: [PATCH net-next 2/3] tcp: avoid integer overflows in tcp_rcv_space_adjust()

2017-12-11 Thread Neal Cardwell
duma...@google.com> > Acked-by: Soheil Hassas Yeganeh <soh...@google.com> > Acked-by: Wei Wang <wei...@google.com> > --- Acked-by: Neal Cardwell <ncardw...@google.com> Thanks, Eric! neal

Re: [PATCH net-next 1/3] tcp: do not overshoot window_clamp in tcp_rcv_space_adjust()

2017-12-11 Thread Neal Cardwell
Yeganeh <soh...@google.com> > Acked-by: Wei Wang <wei...@google.com> > --- Acked-by: Neal Cardwell <ncardw...@google.com> Thanks, Eric! neal

Re: [PATCH net 0/3] TCP BBR sampling fixes for loss recovery undo

2017-12-07 Thread Neal Cardwell
On Thu, Dec 7, 2017 at 12:43 PM, Neal Cardwell <ncardw...@google.com> wrote: > This patch series has a few minor bug fixes for cases where spurious > loss recoveries can trick BBR estimators into estimating that the > available bandwidth is much lower than the true available bandw

[PATCH net 0/3] TCP BBR sampling fixes for loss recovery undo

2017-12-07 Thread Neal Cardwell
This patch series has a few minor bug fixes for cases where spurious loss recoveries can trick BBR estimators into estimating that the available bandwidth is much lower than the true available bandwidth. In both cases the fix here is to just reset the estimator upon loss recovery undo. Neal

[PATCH net 2/3] tcp_bbr: reset full pipe detection on loss recovery undo

2017-12-07 Thread Neal Cardwell
to spuriously estimate that the pipe is full. Since spurious loss recovery means that our overall sending will have slowed down spuriously, this commit gives a flow more time to probe robustly for bandwidth and decide the pipe is really full. Signed-off-by: Neal Cardwell <ncardw...@google.com> Re

[PATCH net 3/3] tcp_bbr: reset long-term bandwidth sampling on loss recovery undo

2017-12-07 Thread Neal Cardwell
rates high enough to trigger long-term bandwidth estimation. To avoid that problem, this commit resets long-term bandwidth sampling on loss recovery undo events. Signed-off-by: Neal Cardwell <ncardw...@google.com> Reviewed-by: Yuchung Cheng <ych...@google.com> Acked-by: Soheil Hassas

[PATCH net 1/3] tcp_bbr: record "full bw reached" decision in new full_bw_reached bit

2017-12-07 Thread Neal Cardwell
k the pipe is full. Note that this fix intentionally reduces the width of the full_bw_cnt counter, since we have never used the most significant bit. Signed-off-by: Neal Cardwell <ncardw...@google.com> Reviewed-by: Yuchung Cheng <ych...@google.com> Acked-by: Soheil Hassas Yeganeh <soh...@

Re: [PATCH net] tcp: use current time in tcp_rcv_space_adjust()

2017-12-06 Thread Neal Cardwell
> Using an old timestamp leads to autotuning lags. > > Fixes: 645f4c6f2ebd ("tcp: switch rcv_rtt_est and rcvq_space to high > resolution timestamps") > Signed-off-by: Eric Dumazet <eduma...@google.com> > Cc: Wei Wang <wei...@google.com> > Cc: Neal Cardwell &l

Re: Linux ECN Handling

2017-12-05 Thread Neal Cardwell
On Tue, Dec 5, 2017 at 12:22 AM, Steve Ibanez wrote: > Hi Neal, > > Happy to help out :) And thanks for the tip! > > I was able to track down where the missing bytes that you pointed out > are being lost. It turns out the destination host seems to be > misbehaving. I

Re: Linux ECN Handling

2017-12-01 Thread Neal Cardwell
On Mon, Nov 27, 2017 at 1:49 PM, Steve Ibanez wrote: > > Hi Neal, > > I tried out your new suggested patches and indeed it looks like it is > working. The duration of the freezes looks like it has reduced from an > RTO to 10ms (tcp probe reports SRTT measurements of about

Re: Linux ECN Handling

2017-11-21 Thread Neal Cardwell
o patches together in your test set-up? (1) commit 1ade85cd788cfed0433a83da03e299f396769c73 Author: Neal Cardwell <ncardw...@google.com> Date: Tue Nov 21 22:33:30 2017 -0500 tcp: allow TLP in CWR (Also allows TLP in disorder, though this is somewhat academic, since in disor

Re: Linux ECN Handling

2017-11-21 Thread Neal Cardwell
On Tue, Nov 21, 2017 at 10:51 AM, Yuchung Cheng <ych...@google.com> wrote: > On Tue, Nov 21, 2017 at 7:01 AM, Neal Cardwell <ncardw...@google.com> wrote: >> >> The original motivation for only allowing TLP in the CA_Open state was >> to be conservative and avoid

Re: Linux ECN Handling

2017-11-21 Thread Neal Cardwell
On Tue, Nov 21, 2017 at 12:58 AM, Steve Ibanez wrote: > Hi Neal, > > I tried your suggestion to disable tcp_tso_should_defer() and it does > indeed look like it is preventing the host from entering timeouts. > I'll have to do a bit more digging to try and find where the

Re: Linux ECN Handling

2017-11-20 Thread Neal Cardwell
On Mon, Nov 20, 2017 at 2:31 AM, Steve Ibanez wrote: > Hi Folks, > > I wanted to check back in on this for another update and to solicit > some more suggestions. I did a bit more digging to try an isolate the > problem. Going back to one of your Oct 19 trace snapshots

[PATCH net] tcp: when scheduling TLP, time of RTO should account for current ACK

2017-11-17 Thread Neal Cardwell
elayed ACKs), then the TLP timer fires too quickly. Fixes: df92c8394e6e ("tcp: fix xmit timer to only be reset if data ACKed/SACKed") Signed-off-by: Neal Cardwell <ncardw...@google.com> Signed-off-by: Yuchung Cheng <ych...@google.com> Signed-off-by: Eric Dumazet <eduma..

Re: [PATCH v2 net-next] tcp: allow drivers to tweak TSQ logic

2017-11-12 Thread Neal Cardwell
hannes Berg <johannes.b...@intel.com> > Cc: Toke Høiland-Jørgensen <t...@toke.dk> > Cc: Kir Kolyshkin <k...@openvz.org> > --- Nice. Thanks, Eric! Acked-by: Neal Cardwell <ncardw...@google.com> neal

Re: [PATCH net-next] tcp: tcp_mtu_probing() cleanup

2017-11-03 Thread Neal Cardwell
...@google.com> > --- > net/ipv4/tcp_timer.c | 31 ++- > 1 file changed, 14 insertions(+), 17 deletions(-) Acked-by: Neal Cardwell <ncardw...@google.com> Thanks, Eric! neal

Re: [PATCH net-next] tcp: tcp_fragment() should not assume rtx skbs

2017-11-02 Thread Neal Cardwell
ersion) > for rtx-rb-tree to fix the bug. > > Fixes: e2080072ed2d ("tcp: new list for sent but unacked skbs for RACK > recovery") > Signed-off-by: Eric Dumazet <eduma...@google.com> Acked-by: Neal Cardwell <ncardw...@google.com> Thanks, Eric! neal

Re: [PATCH net] tcp: fix tcp_mtu_probe() vs highest_sack

2017-10-31 Thread Neal Cardwell
ted-by: Alexei Starovoitov <alexei.starovoi...@gmail.com> > Reported-by: Roman Gushchin <g...@fb.com> > Reported-by: Oleksandr Natalenko <oleksa...@natalenko.name> > --- > include/net/tcp.h |6 +++--- > net/ipv4/tcp_output.c |3 ++- > 2 files changed, 5 insertions(+), 4 deletions(-) Acked-by: Neal Cardwell <ncardw...@google.com> Nice catch, indeed. Thanks, Eric! neal

Re: Linux ECN Handling

2017-10-23 Thread Neal Cardwell
On Mon, Oct 23, 2017 at 6:15 PM, Steve Ibanez wrote: > Hi All, > > I upgraded the kernel on all of our machines to Linux > 4.13.8-041308-lowlatency. However, I'm still observing the same > behavior where the source enters a timeout when the CWND=1MSS and it > receives ECN

Re: [REGRESSION] Warning in tcp_fastretrans_alert() of net/ipv4/tcp_input.c

2017-09-15 Thread Neal Cardwell
On Fri, Sep 15, 2017 at 1:03 AM, Oleksandr Natalenko wrote: > Hi. > > I've applied your test patch but it doesn't fix the issue for me since the > warning is still there. > > Were you able to reproduce it? Hi, Thanks for testing that. That is a very useful data point.

  1   2   3   4   >