[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.