On 2016/4/12 10:59, Yang Yingliang wrote:
On 2016/4/11 20:13, Eric Dumazet wrote:
On Mon, 2016-04-11 at 19:57 +0800, Yang Yingliang wrote:
On 2016/4/8 22:44, Eric Dumazet wrote:
On Fri, 2016-04-08 at 19:18 +0800, Yang Yingliang wrote:
I expand tcp_adv_win_scale and tcp_rmem. It has
On 2016/4/11 20:13, Eric Dumazet wrote:
On Mon, 2016-04-11 at 19:57 +0800, Yang Yingliang wrote:
On 2016/4/8 22:44, Eric Dumazet wrote:
On Fri, 2016-04-08 at 19:18 +0800, Yang Yingliang wrote:
I expand tcp_adv_win_scale and tcp_rmem. It has no effect.
Try :
echo -2 >/proc/sys/net/i
On 2016/4/9 1:04, Eric Dumazet wrote:
On Fri, 2016-04-08 at 12:53 -0400, David Miller wrote:
From: Eric Dumazet <eric.duma...@gmail.com>
Date: Fri, 08 Apr 2016 07:44:25 -0700
On Fri, 2016-04-08 at 19:18 +0800, Yang Yingliang wrote:
I expand tcp_adv_win_scale and tcp_rmem.
On 2016/4/8 22:44, Eric Dumazet wrote:
On Fri, 2016-04-08 at 19:18 +0800, Yang Yingliang wrote:
I expand tcp_adv_win_scale and tcp_rmem. It has no effect.
Try :
echo -2 >/proc/sys/net/ipv4/tcp_adv_win_scale
And restart your flows.
cat /proc/sys/net/ipv4/tcp_rmem
10240 2097152 10485
On 2016/4/7 22:51, Eric Dumazet wrote:
On Thu, 2016-04-07 at 03:21 -0700, Eric Dumazet wrote:
Please do not send patches before really understanding the issue you
have.
Having a backlog of 12506206 bytes is ridiculous. Dropping packets is
absolutely fine if this ever happens.
Something is
On 2016/3/30 21:47, Eric Dumazet wrote:
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
On 2016/3/30 20:56, Sergei Shtylyov wrote:
Hello.
On 3/30/2016 8:16 AM, Yang Yingliang wrote:
When task A hold the sk owned in tcp_sendmsg, if lots of packets
arrive and the packets will be added to backlog queue. The packets
will be handled in release_sock called from tcp_sendmsg. When
On 2016/3/30 13:34, Eric Dumazet wrote:
On Tue, 2016-03-29 at 22:25 -0700, Eric Dumazet wrote:
On Wed, 2016-03-30 at 13:16 +0800, Yang Yingliang wrote:
When task A hold the sk owned in tcp_sendmsg, if lots of packets
arrive and the packets will be added to backlog queue. The packets
On 2016/3/30 13:25, Eric Dumazet wrote:
On Wed, 2016-03-30 at 13:16 +0800, Yang Yingliang wrote:
When task A hold the sk owned in tcp_sendmsg, if lots of packets
arrive and the packets will be added to backlog queue. The packets
will be handled in release_sock called from tcp_sendmsg. When
are handled. This may leads to the
new packets be dropped because the lenth is too big. So set the
lenth to 0 immediately after it's detached from sk.
Signed-off-by: Yang Yingliang <yangyingli...@huawei.com>
---
net/core/sock.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/so
Hi,
I got a tap device refcnt leak message when I was detaching the device
and it's deadloop for waiting the usage count decrease to 0.
The log is:
unregister_netdevice: waiting for pae_tap0 to become free. Usage count = 1
Unfortunately, it happened only once unit now, I cannot reproduce
11 matches
Mail list logo
