On 08/25/2017 06:52 PM, Eric Dumazet wrote:
> On Fri, 2017-08-25 at 18:17 -0700, Florian Fainelli wrote:
>> On 08/25/2017 04:57 PM, Eric Dumazet wrote:
>>> On Fri, 2017-08-25 at 16:18 -0700, Florian Fainelli wrote:
>>>
>>>> Eric, are there areas of the stack where we are allowed to drop packets,
>>>> not propagate that back to write(2) and also not increment any counter
>>>> either, or maybe I am not looking where I should...
>>>
>>> What happens if you increase these sysctls ?
>>
>> I don't see packet loss after I tweak these two sysctls according to
>> your suggestions.
>>
>> Tweaking eth0's sysctls did not change anything, but tweaking gphy's
>> sysctl resolved the loss. This was a little surprising considering that
>> gphy is an IFF_NO_QUEUE interface and eth0 is the conduit interface that
>> does the real transmission.
>>
>> Does that make sense with respect to what I reported earlier? Should I
>> try to dump the neigh stats?
>
> Note that if you had TCP traffic, the neighbour would be constantly
> confirmed and no losses would happen.
OK, that still sounds like quite a lot for a not so long UDP session (60
seconds).
I was finally able to get a better capture by switching to an ARM64
kernel, and as confirmed this is all coming from the neighbour code:
# Event count (approx.): 1970
#
# Children Self Trace output
# ........ ........
....................................................................
#
3.10% 3.10% skbaddr=0xffffffc2fa22a800 protocol=2048
location=0xffffff80086e53f4
|
---write
el0_svc_naked
sys_write
vfs_write
__vfs_write
sock_write_iter
sock_sendmsg
inet_sendmsg
udp_sendmsg
udp_send_skb
ip_send_skb
ip_local_out
ip_output
ip_finish_output
ip_finish_output2
neigh_resolve_output
__neigh_event_send
kfree_skb
kfree_skb
3.10% 3.10% skbaddr=0xffffffc2fa22a900 protocol=2048
location=0xffffff80086e53f4
|
---write
el0_svc_naked
sys_write
vfs_write
__vfs_write
sock_write_iter
sock_sendmsg
inet_sendmsg
udp_sendmsg
udp_send_skb
ip_send_skb
ip_local_out
ip_output
ip_finish_output
ip_finish_output2
neigh_resolve_output
__neigh_event_send
kfree_skb
kfree_skb
3.10% 3.10% skbaddr=0xffffffc2fa22aa00 protocol=2048
location=0xffffff80086e53f4
|
---write
el0_svc_naked
sys_write
vfs_write
__vfs_write
sock_write_iter
sock_sendmsg
inet_sendmsg
udp_sendmsg
udp_send_skb
ip_send_skb
ip_local_out
ip_output
ip_finish_output
ip_finish_output2
neigh_resolve_output
__neigh_event_send
kfree_skb
kfree_skb
>
> I guess we should an SNMP counter for packets dropped in neigh queues.
It would. Since the call trace involves udp_send_skb() how come we are
not returning an error to write(2)? are there other code paths where the
neighbor code can do drops like these?
--
Florian
