[Bug 263817] dwc: dwc driver will re-count the number of uni-cast/multicast packets are sent/received

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 06 May 2022 14:52:19 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263817

            Bug ID: 263817
           Summary: dwc: dwc driver will re-count the number of
                    uni-cast/multicast packets are sent/received
           Product: Base System
           Version: CURRENT
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: jiahali@blackberry.com

Overview
--------
The number of unicast packets that the dwc driver sent/received will be
recorded by using the IFCOUNTER_IPACKETS/IFCOUNTER_OPACKETS macros when the
tx/rx interrupts are invoked.(See if_dwc.c/dwc_rxfinish_one() and
if_dwc.c/dwc_txfinish_locked())


The number of multicast packets will also be recorded at the networking stack
using IFCOUNTER_IMCASTS/IFCOUNTER_OMCASTS macros.(For example,
/trunk/io-sock/sys/net/if_ethersubr.c/ether_input_internal())


However, the dwc driver will register a callout function, dwc_tick(), which
will read the driver's registers, dwc_harvest_stats, to count how many
unicast/multicast packets are sent/received. The recalculation issue also
exists in Freebsd's current release image.

Actual Results
--------------
Steps for reproducing

1. Set up

In dwc driver's Freebsd terminal

root@generic:~ # uname -a
FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n254961-b91a48693a5:
Thu Apr 21 09:35:51 UTC 2022    
root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64

root@generic:~ # ifconfig dwc0
dwc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE>
        ether fa:97:92:f6:f1:09
        inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

root@generic:~ # ifconfig dwc0 192.168.3.129/24
root@generic:~ # ifconfig dwc0
dwc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE>
        ether fa:97:92:f6:f1:09
        inet 192.168.3.129 netmask 0xffffff00 broadcast 192.168.3.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

Host Terminal 1

Check interface config
$ ifconfig enp0s31f6
enp0s31f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.3.2  netmask 255.255.255.0  broadcast 192.168.3.255
        inet6 fe80::f897:92ff:fef6:f102  prefixlen 64  scopeid 0x20<link>
        ether 8c:8c:aa:c1:2b:c3  txqueuelen 1000  (Ethernet)
        RX packets 1662  bytes 516194 (516.1 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10885  bytes 1346113 (1.3 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0xae380000-ae3a0000

Run the tcpdump on interface 'enp0s31f6"
sudo tcpdump -U -pi enp0s31f6 -en


2. Test Results
In dwc driver's Freebsd terminal

root@generic:~ # netstat -n -I dwc0
Name    Mtu Network       Address              Ipkts Ierrs Idrop    Opkts Oerrs
 Coll
dwc0   1500 <Link#1>      fa:97:92:f6:f1:09       24     0     0       74     0
    0
dwc0      - 192.168.3.0/2 192.168.3.129            6     -     -        4     -
    -

root@generic:~ # ping -c 1 192.168.3.2
PING 192.168.3.2 (192.168.3.2): 56 data bytes
64 bytes from 192.168.3.2: icmp_seq=0 ttl=64 time=0.426 ms

--- 192.168.3.2 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.426/0.426/0.426/0.000 ms

root@generic:~ # netstat -n -I dwc0
Name    Mtu Network       Address              Ipkts Ierrs Idrop    Opkts Oerrs
 Coll
dwc0   1500 <Link#1>      fa:97:92:f6:f1:09       26     0     0       78     0
    0
dwc0      - 192.168.3.0/2 192.168.3.129            7     -     -        5     -
    -


Packets captured by the tcpdump at Host Terminal 1

$ sudo tcpdump -U -pi enp0s31f6 -en
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s31f6, link-type EN10MB (Ethernet), capture size 262144 bytes
10:23:53.592175 fa:97:92:f6:f1:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806),
length 60: Request who-has 192.168.3.2 tell 192.168.3.129, length 46
10:23:53.592188 8c:8c:aa:c1:2b:c3 > fa:97:92:f6:f1:09, ethertype ARP (0x0806),
length 42: Reply 192.168.3.2 is-at 8c:8c:aa:c1:2b:c3, length 28
10:23:53.592320 fa:97:92:f6:f1:09 > 8c:8c:aa:c1:2b:c3, ethertype IPv4 (0x0800),
length 98: 192.168.3.129 > 192.168.3.2: ICMP echo request, id 59653, seq 0,
length 64
10:23:53.592342 8c:8c:aa:c1:2b:c3 > fa:97:92:f6:f1:09, ethertype IPv4 (0x0800),
length 98: 192.168.3.2 > 192.168.3.129: ICMP echo reply, id 59653, seq 0,
length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel


Analysis
--------------

The change in the netstat results, Ipkts and Opkts, shows that there were 4
packets sent and 4 packets received at the link-layer level, which is doubled
the actual number of packets.

I tried to use the gdb debugger to go through the increments of the counters
step by step. And I found that IFCOUNTER_IPACKETS, IFCOUNTER_OPACKETS,
IFCOUNTER_IMCASTS, and IFCOUNTER_OMCASTS are involved.

-- 
You are receiving this mail because:
You are the assignee for the bug.