Date: Fri, 06 May 2022 14:52:19 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 263817] dwc: dwc driver will re-count the number of uni-cast/multicast packets are sent/received Message-ID: <bug-263817-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263817 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 sta= ck 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-b91a48693= a5: Thu Apr 21 09:35:51 UTC 2022=20=20=20=20 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm= 64 root@generic:~ # ifconfig dwc0 dwc0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=3D8000b<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=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> root@generic:~ # ifconfig dwc0 192.168.3.129/24 root@generic:~ # ifconfig dwc0 dwc0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=3D8000b<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=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> Host Terminal 1 Check interface config $ ifconfig enp0s31f6 enp0s31f6: flags=3D4163<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 O= errs 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=3D0 ttl=3D64 time=3D0.426 ms --- 192.168.3.2 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev =3D 0.426/0.426/0.426/0.000 ms root@generic:~ # netstat -n -I dwc0 Name Mtu Network Address Ipkts Ierrs Idrop Opkts O= errs 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 by= tes 10:23:53.592175 fa:97:92:f6:f1:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x080= 6), 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 (0x080= 6), 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 (0x08= 00), 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 (0x08= 00), 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 doubl= ed 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-263817-227>