[Bug 263817] dwc: dwc driver will re-count the number of uni-cast/multicast packets are sent/received
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 263817] dwc: dwc driver will re-count the number of sent/received uni-cast mac address packets and multicast mac address packets"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 263817] dwc: dwc driver will re-count the number of sent/received uni-cast mac address packets and multicast mac address packets"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 263817] dwc: dwc driver will re-count the number of sent/received uni-cast mac address packets and multicast mac address packets"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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.