[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1459345637.6473.205.camel@edumazet-glaptop3.roam.corp.google.com>
Date: Wed, 30 Mar 2016 06:47:17 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Yang Yingliang <yangyingliang@...wei.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH RFC] net: decrease the length of backlog queue
immediately after it's detached from sk
On Wed, 2016-03-30 at 13:56 +0800, Yang Yingliang wrote:
> Sorry, I made a mistake. I am very sure my kernel has these two patches.
> And I can get some dropping of the packets in 10Gb eth.
>
> # netstat -s | grep -i backlog
> TCPBacklogDrop: 4135
> # netstat -s | grep -i backlog
> TCPBacklogDrop: 4167
Sender will retransmit and the receiver backlog will lilely be emptied
before the packets arrive again.
Are you sure these are TCP drops ?
Which 10Gb NIC is it ? (ethtool -i eth0)
What is the max size of sendmsg() chunks are generated by your apps ?
Are they forcing small SO_RCVBUF or SO_SNDBUF ?
What percentage of drops do you have ?
Here (at Google), we have less than one backlog drop per billion
packets, on host facing the public Internet.
If a TCP sender sends a burst of tiny packets because it is misbehaving,
you absolutely will drop packets, especially if applications use
sendmsg() with very big lengths and big SO_SNDBUF.
Trying to not drop these hostile packets as you did is simply opening
your host to DOS attacks.
Eventually, we should even drop earlier in TCP stack (before taking
socket lock).
Powered by blists - more mailing lists