Re: about usb3 <> ethernet adapters for raspberry pi 5

On 6/2/26 17:43, void wrote:
> Hi Mark,
> 
> On Fri, May 22, 2026 at 11:33:48PM -0700, Mark Millard wrote:
> 
>> # usbconfig -l -d ugen0.2
>> ugen0.2: <RTL8153 Gigabit Ethernet Adapter Realtek Semiconductor Corp.>
>> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA)
>> - - - - - - - - - - - - - - - - - - - - - - - - -
>> [ ID] Interval           Transfer     Bitrate         Retr
>> [  5]   0.00-10.03  sec  1.10 GBytes   940 Mbits/sec   50           
>> sender
>> [  5]   0.00-10.03  sec  1.10 GBytes   940 Mbits/sec
> 
> (snip)
> 
>> It turned out that different revisions behave very differently and the
>> prior cfg change that had been committed messed up the operation of
>> the rev I have access to. In the end, the original default cfg (0) was
>> restored and the other rev 0x31fd got a rev-specific Quirk for Realtek
>> RTL8153 to use UQ_CFG_INDEX_1 so if_cdce claims rev 0x31fd instead of
>> if_ure:
>>
>> -    USB_QUIRK(REALTEK, RTL8153, UQ_CFG_INDEX_1),
>> +    USB_QUIRK_REV(REALTEK, RTL8153, 0x31fd, 0x31fd, UQ_CFG_INDEX_1),
>>
>>
>> The non-0x31fd rev is the type of dongle that I normally use. I do have
>> at least one other type of dongle around that was historically slower
>> then the RTL8153 ones I have access to. But, back when the type of my
>> dongles that I use were speed up (2020-Sep?), I was also a tester for
>> the effort at that time.
> 
> Are you aware of any quirks required for this:
> 
> axge0 on uhub0
> axge0: <ASIX AX88179B, class 0/0, rev 3.20/2.00, addr 2> on usbus0

sys/dev/usb/net/if_axge.c does not have an explicit entry (yet?) for
AX88179B or XGE_FLAG_179B:

static const STRUCT_USB_HOST_ID axge_devs[] = {
#define	AXGE_DEV(v,p,i,...)	\
	{ USB_VPI(USB_VENDOR_##v, USB_PRODUCT_##v##_##p, i), __VA_ARGS__ }
	AXGE_DEV(ASIX, AX88178A, AXGE_FLAG_178A),
	AXGE_DEV(ASIX, AX88179, AXGE_FLAG_179, USB_DEV_BCD_LTEQ(0x0100)),
	AXGE_DEV(ASIX, AX88179, AXGE_FLAG_179A, USB_DEV_BCD_GTEQ(0x0200)),
	AXGE_DEV(BELKIN, B2B128, AXGE_FLAG_179),
	AXGE_DEV(DLINK, DUB1312, AXGE_FLAG_179),
	AXGE_DEV(LENOVO, GIGALAN, AXGE_FLAG_179),
	AXGE_DEV(SITECOMEU, LN032, AXGE_FLAG_179),
#undef AXGE_DEV
};

# grep -r AXGE_FLAG_179 /usr/src/dev/usb/net/if_axgereg.h
/usr/src/sys/dev/usb/net/if_axgereg.h:#define	AXGE_FLAG_179		0x2000	/*
AX88179 */
/usr/src/sys/dev/usb/net/if_axgereg.h:#define	AXGE_FLAG_179A		0x4000	/*
AX88179A */


# grep AX881 /usr/src/sys/dev/usb/usbdevs
product ASIX AX88172		0x1720	10/100 Ethernet
product ASIX AX88178		0x1780	AX88178
product ASIX AX88178A		0x178a	AX88178A USB 2.0 10/100/1000 Ethernet
product ASIX AX88179		0x1790	AX88179 USB 3.0 10/100/1000 Ethernet


> miibus0: <MII bus> on axge0
> ukphy0: <Generic IEEE 802.3u media interface>
>  PHY 3 on miibus0
>  ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
> 1000baseT-FDX
>  , 1000baseT-FDX-master
>  , auto, auto-flow
>  ue0: <USB Ethernet> on axge0
> 
> because iperf3 throughput is really poor (~225Mbit by default, ~300 Mbit
> with -lro -lso)
> 
> I'm wondering now if I should have gone with RTL8153, which was double
> the cost.

My understanding is that the speed issue is largely a relationship
between the driver and the actual device (not the marketing name for a
family on incompatible devices). The ones that I use and reported
on are an example . . .

As I understand the history for what I use, the speed of the ones that I
use is the result of a driver update by John-Mark Gurney:

QUOTE
author	John-Mark Gurney <[email protected]>	2020-09-12 00:33:11 +0000
committer	John-Mark Gurney <[email protected]>	2020-09-12 00:33:11 +0000

commit	7d5522e16a2970ade4e79e647842841cd32a19e1 (patch)
tree	8f70fc81f56b87d7604b7caeb026e11e7274db34 /sys/dev/usb/net/if_ure.c
parent	038fe1e3efae50220eb853bb88bccb2572a86de1 (diff)

A major update to the ure driver.

This update adds support for:
HW VLAN tagging
HW checksum offload for IPv4 and IPv6
tx and rx aggreegation (for full gige speeds)
multiple transactions

In my testing, I am able to get 900-950Mbps depending upon
TCP or UDP, which is a significant improvement over the previous
91Mbps (~8kint/sec*1500bytes/packet*1packet/int).
END QUOTE

So roughly a 10x speedup factor. (There are other more recent
improvments as well.)

(I was a tester at the time.)

Note that its prior speed was slower than what you are now trying to avoid.

RTL8153 is unclear:
I remind of the quirk added to avoid use of the same driver on a
different RTL8153, causing use of a different driver --in order to avoid
flapping up and down: totally unreliable using the driver my context
uses. RTL8153 is a marketing name for a wide variety of incompatible
devices as far as I can tell.

-- 
===
Mark Millard
marklmi at yahoo.com