[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOFJUkhNnD2VVKAuNjU7yW8jh+XZMuzt5N_Qk6oiV21CNK6auQ@mail.gmail.com>
Date: Thu, 26 Apr 2012 16:29:34 +0200
From: Chris <xchris89x@...glemail.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: linux-kernel@...r.kernel.org, davem@...emloft.net
Subject: Re: many rx packets dropped since 2.6.37
2012/4/26 Eric Dumazet <eric.dumazet@...il.com>:
>> Okay this is a Fedora-16 VM under KVM with 4 minutes uptime only and dropwatch!
>>
>> 349 dropped packets in 4 minutes uptime??
>>
>
> yes, apparently.
>
> Mostely because of :
>
> 610 with invalid addresses
> 71 dropped because of missing route
> and IPReversePathFilter: 82
>
> It seems you have some work to do on your network config
What do you mean exactly?
This is netstat -s on the hostsystem with 24 days uptime. KVM guests
are connected via bridged networking.
# netstat -s
Ip:
14750606 total packets received
4394457 with invalid addresses
0 forwarded
0 incoming packets discarded
5461822 incoming packets delivered
5149263 requests sent out
Icmp:
136871 ICMP messages received
22 input ICMP message failed.
ICMP input histogram:
destination unreachable: 30
timeout in transit: 5
echo requests: 136809
echo replies: 27
149082 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 12269
echo request: 4
echo replies: 136809
IcmpMsg:
InType0: 27
InType3: 30
InType8: 136809
InType11: 5
OutType0: 136809
OutType3: 12269
OutType8: 4
Tcp:
430 active connections openings
32123 passive connection openings
117 failed connection attempts
39 connection resets received
2 connections established
5250012 segments received
4916354 segments send out
8781 segments retransmited
0 bad segments received.
70 resets sent
Udp:
74938 packets received
0 packets to unknown port received.
0 packet receive errors
75044 packets sent
UdpLite:
TcpExt:
2 invalid SYN cookies received
117 resets received for embryonic SYN_RECV sockets
809 TCP sockets finished time wait in fast timer
1 time wait sockets recycled by time stamp
2400 packets rejects in established connections because of timestamp
101608 delayed acks sent
978 delayed acks further delayed because of locked socket
Quick ack mode was activated 2993 times
36910 packets directly queued to recvmsg prequeue.
13392680 packets directly received from backlog
169 packets directly received from prequeue
4493014 packets header predicted
2027 packets header predicted and directly queued to user
109135 acknowledgments not containing data received
2686390 predicted acknowledgments
46 times recovered from packet loss due to SACK data
TCPDSACKUndo: 16
613 congestion windows recovered after partial ack
5 TCP data loss events
696 timeouts after SACK recovery
18 timeouts in loss state
46 fast retransmits
9 forward retransmits
193 retransmits in slow start
6614 other TCP timeouts
1 sack retransmits failed
3000 DSACKs sent for old packets
2091 DSACKs received
11 connections reset due to unexpected data
24 connections reset due to early user close
26 connections aborted due to timeout
TCPDSACKIgnoredOld: 1333
TCPDSACKIgnoredNoUndo: 407
TCPSackShifted: 28
TCPSackMerged: 93
TCPSackShiftFallback: 443
IpExt:
InMcastPkts: 952759
OutMcastPkts: 20
InBcastPkts: 887543
InOctets: 19724020920
OutOctets: 918687039
InMcastOctets: 73525673
OutMcastOctets: 4004
InBcastOctets: 139495386
>
>> [root@...t ~]# uname -r
>> 3.3.2-6.fc16.x86_64
>> [root@...t ~]# dropwatch -l kas
>> Initalizing kallsyms db
>> dropwatch> start
>> Enabling monitoring...
>> Kernel monitoring activated.
>> Issue Ctrl-C to stop monitoring
>> 1 drops at netlink_unicast+1bc
>
> this is a false positive, bugfix here :
> http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git;a=commitdiff;h=bfb253c9b277acd9f85b1886ff82b1dd5fbff2ae
Okay :)
>> 3 drops at ip_rcv_finish+f0
>> 1 drops at __netif_receive_skb+583
>> 1 drops at ip_rcv+d3
>> 9 drops at ip_rcv_finish+f0
>> 9 drops at ip_rcv_finish+f0
>> 1 drops at __netif_receive_skb+583
>> 6 drops at ip_rcv_finish+f0
>> 1 drops at nf_hook_slow+12b
>
> do you have drops at iptables level ?
I do not know. Should i turn off iptables for testing?
--
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists