optimization
> to further reduce the number of keepalive probes in the presence of
> packet retransmit.
>
> c. Use the elapsed time (instead of the 0-window probe counter) in
> evaluating tcp keepalive timeout.
>
> Thanks to Eric Dumazet, Neal Cardwell, and Yuchung Che
On Wed, Jan 13, 2021 at 12:49 PM Eric Dumazet wrote:
>
> On Wed, Jan 13, 2021 at 9:12 PM Enke Chen wrote:
> >
> > From: Enke Chen
> >
> > The TCP session does not terminate with TCP_USER_TIMEOUT when data
> > remain untransmitted due to zero window.
> >
> > The number of unanswered zero-window p
On Tue, Jan 12, 2021 at 2:31 PM Enke Chen wrote:
>
> From: Enke Chen
>
> In this patch two issues with TCP keepalives are fixed:
>
> 1) TCP keepalive does not timeout when there are data waiting to be
>delivered and then the connection got broken. The TCP keepalive
>timeout is not evaluat
for a fastopen socket. Doing this we will mark all of
> > the packets related to the fastopen SYN as lost.
> >
> > Signed-off-by: Alexander Duyck
> > ---
> >
>
> SGTM, thanks !
>
> Signed-off-by: Eric Dumazet
Nice work. I tested and verified it works with our pa
On Sat, Dec 12, 2020 at 11:01 AM Alexander Duyck
wrote:
>
> On Sat, Dec 12, 2020 at 10:34 AM Yuchung Cheng wrote:
> >
> > On Fri, Dec 11, 2020 at 5:28 PM Alexander Duyck
> > wrote:
> > >
> > > From: Alexander Duyck
> > >
> > &g
On Fri, Dec 11, 2020 at 5:28 PM Alexander Duyck
wrote:
>
> From: Alexander Duyck
>
> There are cases where a fastopen SYN may trigger either a ICMP_TOOBIG
> message in the case of IPv6 or a fragmentation request in the case of
> IPv4. This results in the socket stalling for a second or more as it
On Fri, Dec 11, 2020 at 1:51 PM Alexander Duyck
wrote:
>
> On Fri, Dec 11, 2020 at 11:18 AM Eric Dumazet wrote:
> >
> > On Fri, Dec 11, 2020 at 6:15 PM Alexander Duyck
> > wrote:
> > >
> > > On Fri, Dec 11, 2020 at 8:22 AM Eric Dumazet wrote:
> > > >
> > > > On Fri, Dec 11, 2020 at 5:03 PM Alex
On Wed, Dec 5, 2018 at 4:08 AM Rafael David Tinoco
wrote:
>
> On 12/5/18 4:58 AM, Greg Kroah-Hartman wrote:
> > On Tue, Dec 04, 2018 at 07:09:46PM -0200, Rafael David Tinoco wrote:
> >> On 12/4/18 8:48 AM, Greg Kroah-Hartman wrote:
> >>> This is the start of the stable review cycle for the 4.19.7
warning but want
to nail the bigger issue first.
>
> On středa 27. září 2017 2:18:32 CEST Yuchung Cheng wrote:
>> On Tue, Sep 26, 2017 at 5:12 PM, Yuchung Cheng wrote:
>> > On Tue, Sep 26, 2017 at 6:10 AM, Roman Gushchin wrote:
>> >>> On Wed, Sep 20,
On Tue, Sep 26, 2017 at 5:12 PM, Yuchung Cheng wrote:
> On Tue, Sep 26, 2017 at 6:10 AM, Roman Gushchin wrote:
>>> On Wed, Sep 20, 2017 at 6:46 PM, Roman Gushchin wrote:
>>> >
>>> > > Hello.
>>> > >
>>> > > Since, IIRC, v
On Tue, Sep 26, 2017 at 6:10 AM, Roman Gushchin wrote:
>> On Wed, Sep 20, 2017 at 6:46 PM, Roman Gushchin wrote:
>> >
>> > > Hello.
>> > >
>> > > Since, IIRC, v4.11, there is some regression in TCP stack resulting in
>> > > the
>> > > warning shown below. Most of the time it is harmless, but rar
On Wed, Sep 20, 2017 at 6:46 PM, Roman Gushchin wrote:
>
> > Hello.
> >
> > Since, IIRC, v4.11, there is some regression in TCP stack resulting in the
> > warning shown below. Most of the time it is harmless, but rarely it just
> > causes either freeze or (I believe, this is related too) panic in
On Tue, Apr 12, 2016 at 2:40 PM, Ben Greear wrote:
> On 04/12/2016 01:29 PM, Eric Dumazet wrote:
>>
>> On Tue, 2016-04-12 at 13:23 -0700, Ben Greear wrote:
>>
>>> It worked well enough for years that I didn't even know other algorithms
>>> were
>>> available. It was broken around 4.0 time, and I
On Tue, Apr 12, 2016 at 7:52 AM, Eric Dumazet wrote:
>
> On Tue, 2016-04-12 at 12:17 +, Machani, Yaniv wrote:
> > Hi,
> > After updating from Kernel 3.14 to Kernel 4.4 we have seen a TCP
> > performance degradation over Wi-Fi.
> > In 3.14 kernel, TCP got to its max throughout after less than
On Wed, Jan 6, 2016 at 10:19 AM, Yuchung Cheng wrote:
> On Wed, Jan 6, 2016 at 8:50 AM, Oleksandr Natalenko
> wrote:
>>
>> Unfortunately, the patch didn't help -- I've got the same stacktrace with
>> slightly different offset (+3) within the function.
>>
may
not be the culprit of this div0 issue because I wasn't able to
reproduce exactly your issue on our servers. But I will post the fix
today and CC you.
>
>
> On December 22, 2015 4:10:32 AM EET, Yuchung Cheng wrote:
> >On Mon, Dec 21, 2015
On Mon, Dec 21, 2015 at 12:25 PM, Oleksandr Natalenko
wrote:
> Commit 3759824da87b30ce7a35b4873b62b0ba38905ef5 (tcp: PRR uses CRB mode by
> default and SS mode conditionally) introduced changes to net/ipv4/tcp_input.c
> tcp_cwnd_reduction() that, possibly, cause division by zero, and therefore,
>
On Mon, Oct 26, 2015 at 2:35 PM, Andreas Petlund wrote:
>
>
> > On 26 Oct 2015, at 15:50, Neal Cardwell wrote:
> >
> > On Fri, Oct 23, 2015 at 4:50 PM, Bendik Rønning Opstad
> > wrote:
> >> @@ -2409,6 +2412,15 @@ static int do_tcp_setsockopt(struct sock *sk, int
> >> level,
> > ...
> >> +
On Fri, Oct 23, 2015 at 1:50 PM, Bendik Rønning Opstad
wrote:
>
> This is a request for comments.
>
> Redundant Data Bundling (RDB) is a mechanism for TCP aimed at reducing
> the latency for applications sending time-dependent data.
> Latency-sensitive applications or services, such as online game
On Tue, Jan 13, 2015 at 1:10 PM, Debabrata Banerjee wrote:
>
> Comment in tcp_cwnd_restart() was referencing the wrong RFC for the algorithm
> it's implementing.
>
> Signed-off-by: Debabrata Banerjee
> ---
> net/ipv4/tcp_output.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -
On Wed, Jan 7, 2015 at 12:37 PM, Erik Grinaker wrote:
> On 07 Jan 2015, at 15:58, Eric Dumazet wrote:
>> On Wed, 2015-01-07 at 13:31 +, Erik Grinaker wrote:
>>> On 06 Jan 2015, at 22:00, Yuchung Cheng wrote:
>>>> On Tue, Jan 6, 2015 at 1:04 PM, Erik Grinaker
On Tue, Jan 6, 2015 at 1:04 PM, Erik Grinaker wrote:
>
>> On 06 Jan 2015, at 20:26, Erik Grinaker wrote:
>>
>>>
>>> On 06 Jan 2015, at 20:13, Eric Dumazet wrote:
>>>
>>> On Tue, 2015-01-06 at 19:42 +, Erik Grinaker wrote:
>>>
The transfer on the functioning Netherlands server does indee
On Tue, Jan 6, 2015 at 11:01 AM, Erik Grinaker wrote:
>
>> On 06 Jan 2015, at 18:33, Yuchung Cheng wrote:
>>
>> On Tue, Jan 6, 2015 at 10:17 AM, Erik Grinaker wrote:
>>>
>>>> On 06 Jan 2015, at 17:20, Eric Dumazet wrote:
>>>> On Tue, 2015-0
On Tue, Jan 6, 2015 at 10:17 AM, Erik Grinaker wrote:
>
>> On 06 Jan 2015, at 17:20, Eric Dumazet wrote:
>> On Tue, 2015-01-06 at 16:11 +, Erik Grinaker wrote:
On 06 Jan 2015, at 16:04, Eric Dumazet wrote:
On Tue, 2015-01-06 at 15:14 +, Erik Grinaker wrote:
> (CCing Yuchung
On Tue, Aug 12, 2014 at 2:45 AM, Andrey Vagin wrote:
> We don't know right timestamp for repaired skb-s. Wrong RTT estimations
> isn't good, because some congestion modules heavily depends on it.
>
> This patch adds the TCPCB_REPAIRED flag, which is included in
> TCPCB_RETRANS.
>
> Thanks to Eric
On Mon, May 5, 2014 at 3:25 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> This is all the code that saves connection information
> between different sockets. Not really essential for
> small systems.
>
> Saves about 5.5k text
>
>textdata bss dec hex filename
> 492952 19571
On Wed, Feb 12, 2014 at 3:35 AM, Daniel Borkmann wrote:
> (please cc netdev)
>
> On 02/12/2014 11:25 AM, Quinn Wood wrote:
>>
>> If program on host A spoofs the source address of an outgoing IPv4 packet
>> then
>> places that address in the first 32 bits of a UDP payload, a program on
>> host B
>>
On Thu, Oct 24, 2013 at 2:31 AM, Weiping Pan wrote:
> The parameter req is not used since
> 375fe02c9179(tcp: consolidate SYNACK RTT sampling)
Hi Weiping:
I just sent a bug-fix "tcp: fix SYNACK RTT estimation in Fast Open"
that will also take care of this redundant parameter. Thanks.
.
>
> Signed
socket.file = NULL
>> tun_free_netdev()
>> sk_release_sock()
>> sock_release(sock->file == NULL)
>> iput(SOCK_INODE(sock)) <== dereference on NULL pointer
>>
>> This patch just removes zeroing of socket's file from __tun_detach().
>
On Mon, Jul 16, 2012 at 6:03 AM, Piotr Sawuk wrote:
> On Mo, 16.07.2012, 13:46, Eric Dumazet wrote:
>> On Mon, 2012-07-16 at 13:33 +0200, Piotr Sawuk wrote:
>>> On Sa, 14.07.2012, 01:55, Stephen Hemminger wrote:
>>> > I am not sure if the is really necessary since the most
>>> > of the stats are a
30 matches
Mail list logo
