Hello TerraMaster Engineering,
I am just wondering whether some of the SMB speed issues with TOS 6.0 and the new devices based on the 10GBE "Marvell AQtion (aka Aquantia AQC113CS) Network Adapter" (Linux "atlantic") driver are related to the obvious inability to support Generic Receive Offload (GRO) with the current driver:
Using F4-424 MAX, latest TOS 6.0.519-00144 ("Linux f4-424max 6.1.58+ #208 SMP PREEMPT_DYNAMIC Sun Sep 29 09:49:15 CST 2024 x86_64 x86_64 x86_64 GNU/Linux") - atlantic driver version unfortunately unknown, "lspci" returns
03:00.0 "0200" "1d6a" "14c0" -r03 "1d6a" "0001"
04:00.0 "0200" "1d6a" "14c0" -r03 "1d6a" "0001"
Capabilities: [d0] Vital Product Data
Product Name: Marvell AQtion Network Adapter
Read-only fields:
[PN] Part number: 00B1A113
[V0] Vendor specific: MAC Addr: 6C:BF:B5:04:0D:79
[V1] Vendor specific: Bundle Version: 1.3.30
[V2] Vendor specific: Fw Version: 1.0.120
[RV] Reserved: checksum good, 0 byte(s) reserved
End
The current combination of adaper and kernel driver DOES NOT seem to SUPPORT GRO:
from: https://stackoverflow.com/a/47423189
"Generic Receive Offload (GRO) is a software technique in Linux to aggregate multiple incoming packets belonging to the same stream. The linked article claims that CPU utilization is reduced because, instead of each packet traversing the network stack individually, a single aggregated packet traverses the network stack. (...)
As you can see, GRO aggregation is at the very bottom of the call stack. You can also see how much work is done afterwards. Imagine how much overhead you'll have if each of these functions would operate on a single MTU."
tnasadm@f4-424max:/# dmesg | grep GRO
[ 68.137904] TCP: bond0: Driver has suspect GRO implementation, TCP performance may be compromised.
tnasadm@f4-424max:/# ethtool -k bond0 | grep gro
rx-gro-hw: off [fixed]
rx-gro-list: off
rx-udp-gro-forwarding: off
tnasadm@f4-424max:/# ethtool -k eth0 | grep gro
rx-gro-hw: off [fixed]
rx-gro-list: off
rx-udp-gro-forwarding: off
tnasadm@f4-424max:/# ethtool -k eth1 | grep gro
rx-gro-hw: off [fixed]
rx-gro-list: off
rx-udp-gro-forwarding: off
and shows PACKET LOSS (a relatively large number of packets dropped) in a balance-alb bond setup:
tnasadm@f4-424max:/# netstat -i
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
bond0 1500 2429303 0 497542 0 1040754 0 1 0 BMmRU
docker0 1500 0 0 0 0 0 0 0 0 BMU
eth0 1500 1829523 0 0 0 539708 0 0 0 BMsRU
eth1 1500 599738 0 0 0 501001 0 0 0 BMsRU
lo 65536 1746289 0 0 0 1746289 0 0 0 LRU
Also, it looks like the firmware of the Marvell AQtion (aka Aquantia AQC113CS) NICs is ancient (from lspci, assuming it's either 1.3.30 or even 1.0.120 as reported there) - but station-drivers.com has:
Marvell/Aquantia AQC113CS (10Gbps) Firmware Version 1.5.42 (Windows-only firmware update, but seemingly appropriate for the devices in the F4-424 MAX), as can be seen from updatedata.xml:
<pciid vid="1d6a" did="04c0" sdid="0001" svid="1d6a" />
(1) Are these issues already known to TerraMaster Engineering/ Support?
(2) What is your plan to address/fix them to get GRO working?
(3) Is it supported (i.e. will it keep my warranty intact) to boot into Windows from USB NVMe and update the NIC's firmware to the version above?
Looking forward to your feedback on the whole issue, especially all 3 questions above...
Many thanks!
awl29
I am just wondering whether some of the SMB speed issues with TOS 6.0 and the new devices based on the 10GBE "Marvell AQtion (aka Aquantia AQC113CS) Network Adapter" (Linux "atlantic") driver are related to the obvious inability to support Generic Receive Offload (GRO) with the current driver:
Using F4-424 MAX, latest TOS 6.0.519-00144 ("Linux f4-424max 6.1.58+ #208 SMP PREEMPT_DYNAMIC Sun Sep 29 09:49:15 CST 2024 x86_64 x86_64 x86_64 GNU/Linux") - atlantic driver version unfortunately unknown, "lspci" returns
03:00.0 "0200" "1d6a" "14c0" -r03 "1d6a" "0001"
04:00.0 "0200" "1d6a" "14c0" -r03 "1d6a" "0001"
Capabilities: [d0] Vital Product Data
Product Name: Marvell AQtion Network Adapter
Read-only fields:
[PN] Part number: 00B1A113
[V0] Vendor specific: MAC Addr: 6C:BF:B5:04:0D:79
[V1] Vendor specific: Bundle Version: 1.3.30
[V2] Vendor specific: Fw Version: 1.0.120
[RV] Reserved: checksum good, 0 byte(s) reserved
End
The current combination of adaper and kernel driver DOES NOT seem to SUPPORT GRO:
from: https://stackoverflow.com/a/47423189
"Generic Receive Offload (GRO) is a software technique in Linux to aggregate multiple incoming packets belonging to the same stream. The linked article claims that CPU utilization is reduced because, instead of each packet traversing the network stack individually, a single aggregated packet traverses the network stack. (...)
As you can see, GRO aggregation is at the very bottom of the call stack. You can also see how much work is done afterwards. Imagine how much overhead you'll have if each of these functions would operate on a single MTU."
tnasadm@f4-424max:/# dmesg | grep GRO
[ 68.137904] TCP: bond0: Driver has suspect GRO implementation, TCP performance may be compromised.
tnasadm@f4-424max:/# ethtool -k bond0 | grep gro
rx-gro-hw: off [fixed]
rx-gro-list: off
rx-udp-gro-forwarding: off
tnasadm@f4-424max:/# ethtool -k eth0 | grep gro
rx-gro-hw: off [fixed]
rx-gro-list: off
rx-udp-gro-forwarding: off
tnasadm@f4-424max:/# ethtool -k eth1 | grep gro
rx-gro-hw: off [fixed]
rx-gro-list: off
rx-udp-gro-forwarding: off
and shows PACKET LOSS (a relatively large number of packets dropped) in a balance-alb bond setup:
tnasadm@f4-424max:/# netstat -i
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
bond0 1500 2429303 0 497542 0 1040754 0 1 0 BMmRU
docker0 1500 0 0 0 0 0 0 0 0 BMU
eth0 1500 1829523 0 0 0 539708 0 0 0 BMsRU
eth1 1500 599738 0 0 0 501001 0 0 0 BMsRU
lo 65536 1746289 0 0 0 1746289 0 0 0 LRU
Also, it looks like the firmware of the Marvell AQtion (aka Aquantia AQC113CS) NICs is ancient (from lspci, assuming it's either 1.3.30 or even 1.0.120 as reported there) - but station-drivers.com has:
Marvell/Aquantia AQC113CS (10Gbps) Firmware Version 1.5.42 (Windows-only firmware update, but seemingly appropriate for the devices in the F4-424 MAX), as can be seen from updatedata.xml:
<pciid vid="1d6a" did="04c0" sdid="0001" svid="1d6a" />
(1) Are these issues already known to TerraMaster Engineering/ Support?
(2) What is your plan to address/fix them to get GRO working?
(3) Is it supported (i.e. will it keep my warranty intact) to boot into Windows from USB NVMe and update the NIC's firmware to the version above?
Looking forward to your feedback on the whole issue, especially all 3 questions above...
Many thanks!
awl29
Statistics: Posted by awl29 — Today, 00:33