Re: CFT: major update to if_ure
John-Mark Gurney wrote this message on Sat, Jul 25, 2020 at 16:13 -0700: > Hello, > > I'd like people who have ure (RealTek) based USB devices to test > review D25809[0]. > > 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). > > Thanks. > > [0] https://reviews.freebsd.org/D25809 This has now landed in: https://reviews.freebsd.org/rS365648 Let me know if there are any regressions. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFT: major update to if_ure
Ganbold Tsagaankhuu wrote this message on Wed, Aug 19, 2020 at 16:27 +0800: > On Tue, Jul 28, 2020 at 2:35 AM John-Mark Gurney wrote: > > > Ganbold Tsagaankhuu wrote this message on Mon, Jul 27, 2020 at 18:29 +0800: > > > On Mon, Jul 27, 2020 at 5:14 AM John-Mark Gurney > > wrote: > > > > > > > Ganbold Tsagaankhuu wrote this message on Sun, Jul 26, 2020 at 11:05 > > +0800: > > > > > On Sun, Jul 26, 2020 at 7:13 AM John-Mark Gurney > > > > wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > I'd like people who have ure (RealTek) based USB devices to test > > > > > > review D25809[0]. > > > > > > > > > > > > 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). > > > > > > > > > > Does performance improve for if_ure device on USB2? > > > > > I will try to test it in a couple of days on NanoPI R1 and R1S > > boards. > > > > > > > > Yes, it should. > > > > > > > > I never tested the before driver on USB2, but I'm now able to get > > > > 211Mbps TX and 190Mbps RX TCP, and 227Mbps TX and 225Mbps RX UDP. > > > > > > > > I believe it is likely that the same 91Mbps speed limit applied to > > > > USB2 as well. > > > > > > Couldn't find your iperf test scripts and I tested only tcp: > > > > My test script isn't performance, just features, and I'm thinking about > > how/where to publish it... > > > > You can also test UDP using -u w/ iperf3 and adjust the bandwidth w/ > > -b 300m (or other Mbps)... > > > > > root@nanopi-r1s-h5:~ # iperf3 -c 192.168.111.1 > > > Connecting to host 192.168.111.1, port 5201 > > > [ 5] local 192.168.111.10 port 28569 connected to 192.168.111.1 port > > 5201 > > > [ ID] Interval Transfer Bitrate Retr Cwnd > > > [ 5] 0.00-1.00 sec 27.4 MBytes 230 Mbits/sec0 95.4 KBytes > > > [ 5] 1.00-2.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > > > [ 5] 2.00-3.00 sec 27.7 MBytes 232 Mbits/sec0 95.4 KBytes > > > [ 5] 3.00-4.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > > > [ 5] 4.00-5.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > > > [ 5] 5.00-6.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > > > [ 5] 6.00-7.00 sec 27.7 MBytes 232 Mbits/sec0 95.4 KBytes > > > [ 5] 7.00-8.00 sec 27.7 MBytes 232 Mbits/sec0 95.4 KBytes > > > [ 5] 8.00-9.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > > > [ 5] 9.00-10.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > > > - - - - - - - - - - - - - - - - - - - - - - - - - > > > [ ID] Interval Transfer Bitrate Retr > > > [ 5] 0.00-10.00 sec 276 MBytes 232 Mbits/sec0 > > sender > > > [ 5] 0.00-10.79 sec 276 MBytes 215 Mbits/sec > > > receiver > > > > > > iperf Done. > > > root@nanopi-r1s-h5:~ # iperf3 -c 192.168.111.1 -R > > > Connecting to host 192.168.111.1, port 5201 > > > Reverse mode, remote host 192.168.111.1 is sending > > > [ 5] local 192.168.111.10 port 29384 connected to 192.168.111.1 port > > 5201 > > > [ ID] Interval Transfer Bitrate > > > [ 5] 0.00-1.00 sec 12.1 MBytes 102 Mbits/sec > > > [ 5] 1.00-2.00 sec 12.1 MBytes 102 Mbits/sec > > > [ 5] 2.00-3.00 sec 12.1 MBytes 101 Mbits/sec > > > [ 5] 3.00-4.00 sec 12.1 MBytes 102 Mbits/sec > > > [ 5] 4.00-5.00 sec 12.1 MBytes 102 Mbits/sec > > > [ 5] 5.00-6.00 sec 12.1 MBytes 102 Mbits/sec > > > [ 5] 6.00-7.00 sec 12.1 MBytes 101 Mbits/sec > > > [ 5] 7.00-8.00 sec 12.1 MBytes 102 Mbits/sec > > > [ 5] 8.00-9.00 sec 12.1 MBytes 101 Mbits/sec > > > [ 5] 9.00-10.00 sec 12.1 MBytes 102 Mbits/sec > > > - - - - - - - - - - - - - - - - - - - - - - - - - > > > [ ID] Interval Transfer Bitrate Retr > > > [ 5] 0.00-11.25 sec 121 MBytes 90.3 Mbits/sec 2539 > > > sender > > > [ 5] 0.00-10.00 sec 121 MBytes 101 Mbits/sec > > > receiver > > > > > > iperf Done. > > > root@nanopi-r1s-h5:~ # sysctl -a | grep cpu.0.freq > > > dev.cpu.0.freq_levels: 1248/-1 1008/-1 816/-1 624/-1 480/-1 > > > dev.cpu.0.freq: 1248 > > > > Hmmm... The reverse seems slow, but I can't think of why it'd be that > > slow though. When I did my tests on the USB2 ports, both directions > > were about the same speed... > > > > Thanks for the test! Great to hear things are working... > > When can you commit it? Plan on committing it this week... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@
Re: CFT: major update to if_ure
On Tue, Jul 28, 2020 at 2:35 AM John-Mark Gurney wrote: > Ganbold Tsagaankhuu wrote this message on Mon, Jul 27, 2020 at 18:29 +0800: > > On Mon, Jul 27, 2020 at 5:14 AM John-Mark Gurney > wrote: > > > > > Ganbold Tsagaankhuu wrote this message on Sun, Jul 26, 2020 at 11:05 > +0800: > > > > On Sun, Jul 26, 2020 at 7:13 AM John-Mark Gurney > > > wrote: > > > > > > > > > Hello, > > > > > > > > > > I'd like people who have ure (RealTek) based USB devices to test > > > > > review D25809[0]. > > > > > > > > > > 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). > > > > > > > > Does performance improve for if_ure device on USB2? > > > > I will try to test it in a couple of days on NanoPI R1 and R1S > boards. > > > > > > Yes, it should. > > > > > > I never tested the before driver on USB2, but I'm now able to get > > > 211Mbps TX and 190Mbps RX TCP, and 227Mbps TX and 225Mbps RX UDP. > > > > > > I believe it is likely that the same 91Mbps speed limit applied to > > > USB2 as well. > > > > Couldn't find your iperf test scripts and I tested only tcp: > > My test script isn't performance, just features, and I'm thinking about > how/where to publish it... > > You can also test UDP using -u w/ iperf3 and adjust the bandwidth w/ > -b 300m (or other Mbps)... > > > root@nanopi-r1s-h5:~ # iperf3 -c 192.168.111.1 > > Connecting to host 192.168.111.1, port 5201 > > [ 5] local 192.168.111.10 port 28569 connected to 192.168.111.1 port > 5201 > > [ ID] Interval Transfer Bitrate Retr Cwnd > > [ 5] 0.00-1.00 sec 27.4 MBytes 230 Mbits/sec0 95.4 KBytes > > [ 5] 1.00-2.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > > [ 5] 2.00-3.00 sec 27.7 MBytes 232 Mbits/sec0 95.4 KBytes > > [ 5] 3.00-4.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > > [ 5] 4.00-5.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > > [ 5] 5.00-6.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > > [ 5] 6.00-7.00 sec 27.7 MBytes 232 Mbits/sec0 95.4 KBytes > > [ 5] 7.00-8.00 sec 27.7 MBytes 232 Mbits/sec0 95.4 KBytes > > [ 5] 8.00-9.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > > [ 5] 9.00-10.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > > - - - - - - - - - - - - - - - - - - - - - - - - - > > [ ID] Interval Transfer Bitrate Retr > > [ 5] 0.00-10.00 sec 276 MBytes 232 Mbits/sec0 > sender > > [ 5] 0.00-10.79 sec 276 MBytes 215 Mbits/sec > > receiver > > > > iperf Done. > > root@nanopi-r1s-h5:~ # iperf3 -c 192.168.111.1 -R > > Connecting to host 192.168.111.1, port 5201 > > Reverse mode, remote host 192.168.111.1 is sending > > [ 5] local 192.168.111.10 port 29384 connected to 192.168.111.1 port > 5201 > > [ ID] Interval Transfer Bitrate > > [ 5] 0.00-1.00 sec 12.1 MBytes 102 Mbits/sec > > [ 5] 1.00-2.00 sec 12.1 MBytes 102 Mbits/sec > > [ 5] 2.00-3.00 sec 12.1 MBytes 101 Mbits/sec > > [ 5] 3.00-4.00 sec 12.1 MBytes 102 Mbits/sec > > [ 5] 4.00-5.00 sec 12.1 MBytes 102 Mbits/sec > > [ 5] 5.00-6.00 sec 12.1 MBytes 102 Mbits/sec > > [ 5] 6.00-7.00 sec 12.1 MBytes 101 Mbits/sec > > [ 5] 7.00-8.00 sec 12.1 MBytes 102 Mbits/sec > > [ 5] 8.00-9.00 sec 12.1 MBytes 101 Mbits/sec > > [ 5] 9.00-10.00 sec 12.1 MBytes 102 Mbits/sec > > - - - - - - - - - - - - - - - - - - - - - - - - - > > [ ID] Interval Transfer Bitrate Retr > > [ 5] 0.00-11.25 sec 121 MBytes 90.3 Mbits/sec 2539 > > sender > > [ 5] 0.00-10.00 sec 121 MBytes 101 Mbits/sec > > receiver > > > > iperf Done. > > root@nanopi-r1s-h5:~ # sysctl -a | grep cpu.0.freq > > dev.cpu.0.freq_levels: 1248/-1 1008/-1 816/-1 624/-1 480/-1 > > dev.cpu.0.freq: 1248 > > Hmmm... The reverse seems slow, but I can't think of why it'd be that > slow though. When I did my tests on the USB2 ports, both directions > were about the same speed... > > Thanks for the test! Great to hear things are working... > When can you commit it? thanks, Ganbold > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFT: major update to if_ure (RPi4B uefi/ACPI booted example's iperf3 output)
I had reason to switch to using the RPi4B, which happens to be booted from ACPI. The only Ethernet connection present for this test is via: Autoloading module: if_ure.ko ure0 on uhub1 ure0: on usbus0 add host 127.0.0.1: gateway lo0 fib 0: route already in table miibus0: on ure0 rgephy0: PHY 0 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto ue0: on ure0 ue0: Ethernet address: ### . . . ue0: flags=8843 metric 0 mtu 1500 options=68009b ether ### inet 192.168.1.133 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 # iperf3 -c 192.168.1.120 --get-server-output Connecting to host 192.168.1.120, port 5201 [ 5] local 192.168.1.133 port 15954 connected to 192.168.1.120 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 83.6 MBytes 702 Mbits/sec 797 17.1 KBytes [ 5] 1.00-2.00 sec 83.5 MBytes 700 Mbits/sec 797 7.13 KBytes [ 5] 2.00-3.00 sec 83.7 MBytes 702 Mbits/sec 783 1.43 KBytes [ 5] 3.00-4.00 sec 83.3 MBytes 699 Mbits/sec 813127 KBytes [ 5] 4.00-5.00 sec 82.8 MBytes 695 Mbits/sec 806 18.5 KBytes [ 5] 5.00-6.00 sec 83.9 MBytes 704 Mbits/sec 822 38.4 KBytes [ 5] 6.00-7.00 sec 83.7 MBytes 702 Mbits/sec 808 64.2 KBytes [ 5] 7.00-8.00 sec 83.1 MBytes 697 Mbits/sec 787 92.2 KBytes [ 5] 8.00-9.00 sec 83.2 MBytes 698 Mbits/sec 788 51.2 KBytes [ 5] 9.00-10.00 sec 83.1 MBytes 697 Mbits/sec 799 47.1 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 834 MBytes 700 Mbits/sec 8000 sender [ 5] 0.00-10.24 sec 834 MBytes 683 Mbits/sec receiver Server output: Accepted connection from 192.168.1.133, port 18615 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.133 port 15954 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 63.7 MBytes 535 Mbits/sec [ 5] 1.00-2.00 sec 83.3 MBytes 699 Mbits/sec [ 5] 2.00-3.00 sec 83.6 MBytes 701 Mbits/sec [ 5] 3.00-4.00 sec 83.5 MBytes 700 Mbits/sec [ 5] 4.00-5.00 sec 83.4 MBytes 699 Mbits/sec [ 5] 5.00-6.00 sec 83.5 MBytes 700 Mbits/sec [ 5] 6.00-7.00 sec 83.2 MBytes 698 Mbits/sec [ 5] 7.00-8.00 sec 83.5 MBytes 701 Mbits/sec [ 5] 8.00-9.00 sec 83.1 MBytes 697 Mbits/sec [ 5] 9.00-10.00 sec 83.4 MBytes 700 Mbits/sec [ 5] 10.00-10.24 sec 19.6 MBytes 693 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.24 sec 834 MBytes 683 Mbits/sec receiver iperf Done. # iperf3 -R -c 192.168.1.120 --get-server-output Connecting to host 192.168.1.120, port 5201 Reverse mode, remote host 192.168.1.120 is sending [ 5] local 192.168.1.133 port 55961 connected to 192.168.1.120 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 111 MBytes 933 Mbits/sec [ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec [ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec [ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec [ 5] 4.00-5.00 sec 111 MBytes 932 Mbits/sec [ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec [ 5] 6.00-7.00 sec 111 MBytes 933 Mbits/sec [ 5] 7.00-8.00 sec 111 MBytes 933 Mbits/sec [ 5] 8.00-9.00 sec 111 MBytes 933 Mbits/sec [ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.23 sec 1.09 GBytes 914 Mbits/sec 498 sender [ 5] 0.00-10.00 sec 1.09 GBytes 933 Mbits/sec receiver Server output: --- Server listening on 5201 --- Accepted connection from 192.168.1.133, port 51297 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.133 port 55961 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 87.5 MBytes 734 Mbits/sec 72 1.60 MBytes [ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec 92 1.60 MBytes [ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec 96191 KBytes [ 5] 3.00-4.00 sec
Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?)
[I figured out how it appeared to go faster than USB2.] On 2020-Jul-27, at 20:07, Mark Millard wrote: > On 2020-Jul-27, at 19:07, Mark Millard wrote: > >> On 2020-Jul-27, at 18:44, John-Mark Gurney wrote: >> >>> Mark Millard wrote this message on Mon, Jul 27, 2020 at 17:15 -0700: On 2020-Jul-27, at 16:43, Mark Millard wrote: > On 2020-Jul-26, at 18:20, John-Mark Gurney wrote: > >> Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 -0700: >>> For reference for what applying the patch >>> reported (see Hunk #14): >> >> Ok, updated it to be relative to r363583... >> >> I had made a white spcae commit to if_ure.c, but hadn't made the >> patch relative to it after that commit.. should work now.. > > I updated an old PowerMac G5 (2 sockets/2 cores each) to > head -r363590 with the update patch and tjen plugged in the > USB EtherNet device. The result (extracted from dmesg -a) > was: > > usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, > ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, > ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, > ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, > ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > ugen2.2: at usbus2 (disconnected) > uhub_reattach_port: could not allocate new device > > Unfortunately, I'd not tried a PowerMac with the type of > device before the update. I do not know if the above is > new behavior or not. > > The PowerMac is big-endian, which is what got me to think > about trying it there. The PowerMac is also 64-bit running > a 64-bit FreeBSD. Its USB is 2.0. > > (It also has 2 GigaBit EtherNet ports of its own so I'm not > likely to use a USB device outside special testing.) > I tried what normally shows as an axge0, but trying on the PowerMac G5. It got the same sort of messages as above. The problem does not seem to be tied to your patch. It does prevent my testing the patch on the G5. >>> >>> Yeah, I was going to say that the above messages are before any of >>> may changes get run, so it's unlikely a problem w/ my patch... >>> If the USB device can't get an address on the bus, then it can't >>> even ask what type of device it is to load the driver. >>> >>> Thanks for trying though, maybe someone on the -powerpc list knows >>> of a fix for that. >>> >> >> Turns out that having: >> >> hw.usb.xhci.use_polling=1 >> >> in /boot/loader.conf allowed the old PowerMac context to >> get: >> >> ugen2.2: at usbus2 >> ure0 numa-domain 0 on uhub2 >> ure0: on >> usbus2 >> miibus2: numa-domain 0 on ure0 >> rgephy0: PHY 0 on miibus2 >> rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >> 1000baseT-FDX, 1000baseT-FDX-master, auto >> ue0: on ure0 >> ue0: Ethernet address: ### >> ue0: link state changed to DOWN >> >> and: >> >> ue0: flags=8843 metric 0 mtu 1500 >> >> options=68009b >> ether ### >> inet 192.168.1.149 netmask 0xff00 broadcast 192.168.1.255 >> media: Ethernet autoselect (1000baseT ) >> status: active >> nd6 options=29 >> >> So, with that context, . . . >> (the two directions are widely mismatched) >> >> . . . > > The above is very odd for USB2 since USB2 is limited to > 480Mbits/sec, if I understand right. May be it is a mode > of use that is not getting data to send from USB > regularly at all, say internally generated data or > constant/repeated data only loaded from USB once? > > If yes, then comparing to receiving is not useful and > it need not be useful for comparing to data that does > come from USB transfers. > > I suppose another possibility is that it is an error > that it appears to be going as fast as it appears > above. I isolated the problem: it was not really using 192.168.1.149, but instead 192.168.1.145 (the builtin bge0). This is despite the -N and what the output reported. FYI: bge0: flags=8843 metric 0 mtu 1500 options=8009b ### inet 192.168.1.145 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT ) status: active nd6 options=23 ue0: flags=8843 metric 0 mtu 1500 options=68009b ### inet 192.168.1.149 netmask 0xff
Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?)
On 2020-Jul-27, at 19:07, Mark Millard wrote: > On 2020-Jul-27, at 18:44, John-Mark Gurney wrote: > >> Mark Millard wrote this message on Mon, Jul 27, 2020 at 17:15 -0700: >>> On 2020-Jul-27, at 16:43, Mark Millard wrote: >>> On 2020-Jul-26, at 18:20, John-Mark Gurney wrote: > Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 -0700: >> For reference for what applying the patch >> reported (see Hunk #14): > > Ok, updated it to be relative to r363583... > > I had made a white spcae commit to if_ure.c, but hadn't made the > patch relative to it after that commit.. should work now.. I updated an old PowerMac G5 (2 sockets/2 cores each) to head -r363590 with the update patch and tjen plugged in the USB EtherNet device. The result (extracted from dmesg -a) was: usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT ugen2.2: at usbus2 (disconnected) uhub_reattach_port: could not allocate new device Unfortunately, I'd not tried a PowerMac with the type of device before the update. I do not know if the above is new behavior or not. The PowerMac is big-endian, which is what got me to think about trying it there. The PowerMac is also 64-bit running a 64-bit FreeBSD. Its USB is 2.0. (It also has 2 GigaBit EtherNet ports of its own so I'm not likely to use a USB device outside special testing.) >>> >>> I tried what normally shows as an axge0, but >>> trying on the PowerMac G5. It got the same sort >>> of messages as above. The problem does not seem >>> to be tied to your patch. >>> >>> It does prevent my testing the patch on the G5. >> >> Yeah, I was going to say that the above messages are before any of >> may changes get run, so it's unlikely a problem w/ my patch... >> If the USB device can't get an address on the bus, then it can't >> even ask what type of device it is to load the driver. >> >> Thanks for trying though, maybe someone on the -powerpc list knows >> of a fix for that. >> > > Turns out that having: > > hw.usb.xhci.use_polling=1 > > in /boot/loader.conf allowed the old PowerMac context to > get: > > ugen2.2: at usbus2 > ure0 numa-domain 0 on uhub2 > ure0: on > usbus2 > miibus2: numa-domain 0 on ure0 > rgephy0: PHY 0 on miibus2 > rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT-FDX, 1000baseT-FDX-master, auto > ue0: on ure0 > ue0: Ethernet address: ### > ue0: link state changed to DOWN > > and: > > ue0: flags=8843 metric 0 mtu 1500 > > options=68009b > ether ### > inet 192.168.1.149 netmask 0xff00 broadcast 192.168.1.255 > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=29 > > So, with that context, . . . > (the two directions are widely mismatched) > > # iperf3 -c 192.168.1.120 -B 192.168.1.149 --get-server-output > Connecting to host 192.168.1.120, port 5201 > [ 5] local 192.168.1.149 port 31020 connected to 192.168.1.120 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 113 MBytes 949 Mbits/sec 12564 KBytes > [ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 98549 KBytes > [ 5] 2.00-3.00 sec 113 MBytes 944 Mbits/sec 94 1.06 MBytes > [ 5] 3.00-4.00 sec 112 MBytes 942 Mbits/sec 96719 KBytes > [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 98883 KBytes > [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 93439 KBytes > [ 5] 6.00-7.00 sec 112 MBytes 942 Mbits/sec 93221 KBytes > [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec 96419 KBytes > [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 94632 KBytes > [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 97175 KBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 871 sender > [ 5] 0.00
Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?)
On 2020-Jul-27, at 18:44, John-Mark Gurney wrote: > Mark Millard wrote this message on Mon, Jul 27, 2020 at 17:15 -0700: >> On 2020-Jul-27, at 16:43, Mark Millard wrote: >> >>> On 2020-Jul-26, at 18:20, John-Mark Gurney wrote: >>> Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 -0700: > For reference for what applying the patch > reported (see Hunk #14): Ok, updated it to be relative to r363583... I had made a white spcae commit to if_ure.c, but hadn't made the patch relative to it after that commit.. should work now.. >>> >>> I updated an old PowerMac G5 (2 sockets/2 cores each) to >>> head -r363590 with the update patch and tjen plugged in the >>> USB EtherNet device. The result (extracted from dmesg -a) >>> was: >>> >>> usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, >>> USB_ERR_TIMEOUT >>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, >>> ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, >>> USB_ERR_TIMEOUT >>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, >>> ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, >>> USB_ERR_TIMEOUT >>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, >>> ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, >>> USB_ERR_TIMEOUT >>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, >>> ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, >>> USB_ERR_TIMEOUT >>> ugen2.2: at usbus2 (disconnected) >>> uhub_reattach_port: could not allocate new device >>> >>> Unfortunately, I'd not tried a PowerMac with the type of >>> device before the update. I do not know if the above is >>> new behavior or not. >>> >>> The PowerMac is big-endian, which is what got me to think >>> about trying it there. The PowerMac is also 64-bit running >>> a 64-bit FreeBSD. Its USB is 2.0. >>> >>> (It also has 2 GigaBit EtherNet ports of its own so I'm not >>> likely to use a USB device outside special testing.) >>> >> >> I tried what normally shows as an axge0, but >> trying on the PowerMac G5. It got the same sort >> of messages as above. The problem does not seem >> to be tied to your patch. >> >> It does prevent my testing the patch on the G5. > > Yeah, I was going to say that the above messages are before any of > may changes get run, so it's unlikely a problem w/ my patch... > If the USB device can't get an address on the bus, then it can't > even ask what type of device it is to load the driver. > > Thanks for trying though, maybe someone on the -powerpc list knows > of a fix for that. > Turns out that having: hw.usb.xhci.use_polling=1 in /boot/loader.conf allowed the old PowerMac context to get: ugen2.2: at usbus2 ure0 numa-domain 0 on uhub2 ure0: on usbus2 miibus2: numa-domain 0 on ure0 rgephy0: PHY 0 on miibus2 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto ue0: on ure0 ue0: Ethernet address: ### ue0: link state changed to DOWN and: ue0: flags=8843 metric 0 mtu 1500 options=68009b ether ### inet 192.168.1.149 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 So, with that context, . . . (the two directions are widely mismatched) # iperf3 -c 192.168.1.120 -B 192.168.1.149 --get-server-output Connecting to host 192.168.1.120, port 5201 [ 5] local 192.168.1.149 port 31020 connected to 192.168.1.120 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 113 MBytes 949 Mbits/sec 12564 KBytes [ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 98549 KBytes [ 5] 2.00-3.00 sec 113 MBytes 944 Mbits/sec 94 1.06 MBytes [ 5] 3.00-4.00 sec 112 MBytes 942 Mbits/sec 96719 KBytes [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 98883 KBytes [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 93439 KBytes [ 5] 6.00-7.00 sec 112 MBytes 942 Mbits/sec 93221 KBytes [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec 96419 KBytes [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 94632 KBytes [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec 97175 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 871 sender [ 5] 0.00-10.62 sec 1.10 GBytes 887 Mbits/sec receiver Server output: --- Server listening on 5201 --
Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?)
On 2020-Jul-27, at 16:43, Mark Millard wrote: > On 2020-Jul-26, at 18:20, John-Mark Gurney wrote: > >> Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 -0700: >>> For reference for what applying the patch >>> reported (see Hunk #14): >> >> Ok, updated it to be relative to r363583... >> >> I had made a white spcae commit to if_ure.c, but hadn't made the >> patch relative to it after that commit.. should work now.. > > I updated an old PowerMac G5 (2 sockets/2 cores each) to > head -r363590 with the update patch and tjen plugged in the > USB EtherNet device. The result (extracted from dmesg -a) > was: > > usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > ugen2.2: at usbus2 (disconnected) > uhub_reattach_port: could not allocate new device > > Unfortunately, I'd not tried a PowerMac with the type of > device before the update. I do not know if the above is > new behavior or not. > > The PowerMac is big-endian, which is what got me to think > about trying it there. The PowerMac is also 64-bit running > a 64-bit FreeBSD. Its USB is 2.0. > > (It also has 2 GigaBit EtherNet ports of its own so I'm not > likely to use a USB device outside special testing.) > I tried what normally shows as an axge0, but trying on the PowerMac G5. It got the same sort of messages as above. The problem does not seem to be tied to your patch. It does prevent my testing the patch on the G5. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?)
On 2020-Jul-26, at 18:20, John-Mark Gurney wrote: > Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 -0700: >> For reference for what applying the patch >> reported (see Hunk #14): > > Ok, updated it to be relative to r363583... > > I had made a white spcae commit to if_ure.c, but hadn't made the > patch relative to it after that commit.. should work now.. I updated an old PowerMac G5 (2 sockets/2 cores each) to head -r363590 with the update patch and tjen plugged in the USB EtherNet device. The result (extracted from dmesg -a) was: usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT ugen2.2: at usbus2 (disconnected) uhub_reattach_port: could not allocate new device Unfortunately, I'd not tried a PowerMac with the type of device before the update. I do not know if the above is new behavior or not. The PowerMac is big-endian, which is what got me to think about trying it there. The PowerMac is also 64-bit running a 64-bit FreeBSD. Its USB is 2.0. (It also has 2 GigaBit EtherNet ports of its own so I'm not likely to use a USB device outside special testing.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510) (example PowerMac problem?)
Mark Millard wrote this message on Mon, Jul 27, 2020 at 17:15 -0700: > On 2020-Jul-27, at 16:43, Mark Millard wrote: > > > On 2020-Jul-26, at 18:20, John-Mark Gurney wrote: > > > >> Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 -0700: > >>> For reference for what applying the patch > >>> reported (see Hunk #14): > >> > >> Ok, updated it to be relative to r363583... > >> > >> I had made a white spcae commit to if_ure.c, but hadn't made the > >> patch relative to it after that commit.. should work now.. > > > > I updated an old PowerMac G5 (2 sockets/2 cores each) to > > head -r363590 with the update patch and tjen plugged in the > > USB EtherNet device. The result (extracted from dmesg -a) > > was: > > > > usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > > USB_ERR_TIMEOUT > > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, > > ignored) > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > > USB_ERR_TIMEOUT > > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, > > ignored) > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > > USB_ERR_TIMEOUT > > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, > > ignored) > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > > USB_ERR_TIMEOUT > > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, > > ignored) > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > > USB_ERR_TIMEOUT > > ugen2.2: at usbus2 (disconnected) > > uhub_reattach_port: could not allocate new device > > > > Unfortunately, I'd not tried a PowerMac with the type of > > device before the update. I do not know if the above is > > new behavior or not. > > > > The PowerMac is big-endian, which is what got me to think > > about trying it there. The PowerMac is also 64-bit running > > a 64-bit FreeBSD. Its USB is 2.0. > > > > (It also has 2 GigaBit EtherNet ports of its own so I'm not > > likely to use a USB device outside special testing.) > > > > I tried what normally shows as an axge0, but > trying on the PowerMac G5. It got the same sort > of messages as above. The problem does not seem > to be tied to your patch. > > It does prevent my testing the patch on the G5. Yeah, I was going to say that the above messages are before any of may changes get run, so it's unlikely a problem w/ my patch... If the USB device can't get an address on the bus, then it can't even ask what type of device it is to load the driver. Thanks for trying though, maybe someone on the -powerpc list knows of a fix for that. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFT: major update to if_ure
Ganbold Tsagaankhuu wrote this message on Mon, Jul 27, 2020 at 18:29 +0800: > On Mon, Jul 27, 2020 at 5:14 AM John-Mark Gurney wrote: > > > Ganbold Tsagaankhuu wrote this message on Sun, Jul 26, 2020 at 11:05 +0800: > > > On Sun, Jul 26, 2020 at 7:13 AM John-Mark Gurney > > wrote: > > > > > > > Hello, > > > > > > > > I'd like people who have ure (RealTek) based USB devices to test > > > > review D25809[0]. > > > > > > > > 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). > > > > > > Does performance improve for if_ure device on USB2? > > > I will try to test it in a couple of days on NanoPI R1 and R1S boards. > > > > Yes, it should. > > > > I never tested the before driver on USB2, but I'm now able to get > > 211Mbps TX and 190Mbps RX TCP, and 227Mbps TX and 225Mbps RX UDP. > > > > I believe it is likely that the same 91Mbps speed limit applied to > > USB2 as well. > > Couldn't find your iperf test scripts and I tested only tcp: My test script isn't performance, just features, and I'm thinking about how/where to publish it... You can also test UDP using -u w/ iperf3 and adjust the bandwidth w/ -b 300m (or other Mbps)... > root@nanopi-r1s-h5:~ # iperf3 -c 192.168.111.1 > Connecting to host 192.168.111.1, port 5201 > [ 5] local 192.168.111.10 port 28569 connected to 192.168.111.1 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 27.4 MBytes 230 Mbits/sec0 95.4 KBytes > [ 5] 1.00-2.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > [ 5] 2.00-3.00 sec 27.7 MBytes 232 Mbits/sec0 95.4 KBytes > [ 5] 3.00-4.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > [ 5] 4.00-5.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > [ 5] 5.00-6.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > [ 5] 6.00-7.00 sec 27.7 MBytes 232 Mbits/sec0 95.4 KBytes > [ 5] 7.00-8.00 sec 27.7 MBytes 232 Mbits/sec0 95.4 KBytes > [ 5] 8.00-9.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > [ 5] 9.00-10.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 276 MBytes 232 Mbits/sec0 sender > [ 5] 0.00-10.79 sec 276 MBytes 215 Mbits/sec > receiver > > iperf Done. > root@nanopi-r1s-h5:~ # iperf3 -c 192.168.111.1 -R > Connecting to host 192.168.111.1, port 5201 > Reverse mode, remote host 192.168.111.1 is sending > [ 5] local 192.168.111.10 port 29384 connected to 192.168.111.1 port 5201 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.00 sec 12.1 MBytes 102 Mbits/sec > [ 5] 1.00-2.00 sec 12.1 MBytes 102 Mbits/sec > [ 5] 2.00-3.00 sec 12.1 MBytes 101 Mbits/sec > [ 5] 3.00-4.00 sec 12.1 MBytes 102 Mbits/sec > [ 5] 4.00-5.00 sec 12.1 MBytes 102 Mbits/sec > [ 5] 5.00-6.00 sec 12.1 MBytes 102 Mbits/sec > [ 5] 6.00-7.00 sec 12.1 MBytes 101 Mbits/sec > [ 5] 7.00-8.00 sec 12.1 MBytes 102 Mbits/sec > [ 5] 8.00-9.00 sec 12.1 MBytes 101 Mbits/sec > [ 5] 9.00-10.00 sec 12.1 MBytes 102 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-11.25 sec 121 MBytes 90.3 Mbits/sec 2539 > sender > [ 5] 0.00-10.00 sec 121 MBytes 101 Mbits/sec > receiver > > iperf Done. > root@nanopi-r1s-h5:~ # sysctl -a | grep cpu.0.freq > dev.cpu.0.freq_levels: 1248/-1 1008/-1 816/-1 624/-1 480/-1 > dev.cpu.0.freq: 1248 Hmmm... The reverse seems slow, but I can't think of why it'd be that slow though. When I did my tests on the USB2 ports, both directions were about the same speed... Thanks for the test! Great to hear things are working... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510)
On 2020-Jul-26, at 18:20, John-Mark Gurney wrote: > Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 -0700: >> For reference for what applying the patch >> reported (see Hunk #14): > > Ok, updated it to be relative to r363583... > > I had made a white spcae commit to if_ure.c, but hadn't made the > patch relative to it after that commit.. should work now.. That worked after I upgraded to -r363590 as what to start from ( upgraded from -r363510 ). Only a quick, basic test on a cortexA72 aarch64 system with a USB3 EtherNet device so far: # iperf3 -c 192.168.1.120 --get-server-output Connecting to host 192.168.1.120, port 5201 [ 5] local 192.168.1.148 port 63238 connected to 192.168.1.120 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 91.8 MBytes 770 Mbits/sec 821 91.3 KBytes [ 5] 1.00-2.00 sec 92.2 MBytes 774 Mbits/sec 865 51.1 KBytes [ 5] 2.00-3.00 sec 92.2 MBytes 773 Mbits/sec 844 29.9 KBytes [ 5] 3.00-4.00 sec 91.3 MBytes 766 Mbits/sec 826 65.4 KBytes [ 5] 4.00-5.00 sec 91.2 MBytes 765 Mbits/sec 828 44.1 KBytes [ 5] 5.00-6.00 sec 91.6 MBytes 768 Mbits/sec 862 4.28 KBytes [ 5] 6.00-7.00 sec 91.1 MBytes 765 Mbits/sec 842 5.70 KBytes [ 5] 7.00-8.00 sec 91.5 MBytes 767 Mbits/sec 844 78.1 KBytes [ 5] 8.00-9.00 sec 92.1 MBytes 772 Mbits/sec 855 58.3 KBytes [ 5] 9.00-10.00 sec 91.6 MBytes 769 Mbits/sec 844 17.1 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 917 MBytes 769 Mbits/sec 8431 sender [ 5] 0.00-10.19 sec 916 MBytes 755 Mbits/sec receiver Server output: --- Server listening on 5201 --- Accepted connection from 192.168.1.148, port 32073 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.148 port 63238 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 74.2 MBytes 622 Mbits/sec [ 5] 1.00-2.00 sec 92.3 MBytes 774 Mbits/sec [ 5] 2.00-3.00 sec 92.3 MBytes 774 Mbits/sec [ 5] 3.00-4.00 sec 91.4 MBytes 767 Mbits/sec [ 5] 4.00-5.00 sec 91.1 MBytes 764 Mbits/sec [ 5] 5.00-6.00 sec 91.7 MBytes 769 Mbits/sec [ 5] 6.00-7.00 sec 91.2 MBytes 765 Mbits/sec [ 5] 7.00-8.00 sec 91.2 MBytes 765 Mbits/sec [ 5] 8.00-9.00 sec 92.1 MBytes 772 Mbits/sec [ 5] 9.00-10.00 sec 91.7 MBytes 769 Mbits/sec [ 5] 10.00-10.19 sec 17.3 MBytes 772 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.19 sec 916 MBytes 755 Mbits/sec receiver Before the new kernel installation and reboot it showed: # iperf3 -c 192.168.1.120 --get-server-output Connecting to host 192.168.1.120, port 5201 [ 5] local 192.168.1.148 port 53616 connected to 192.168.1.120 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 13.8 MBytes 116 Mbits/sec 217 35.6 KBytes [ 5] 1.00-2.00 sec 13.7 MBytes 115 Mbits/sec 221 49.8 KBytes [ 5] 2.00-3.00 sec 13.7 MBytes 115 Mbits/sec 217 9.98 KBytes [ 5] 3.00-4.00 sec 13.7 MBytes 115 Mbits/sec 220 41.3 KBytes [ 5] 4.00-5.00 sec 13.7 MBytes 115 Mbits/sec 221 58.2 KBytes [ 5] 5.00-6.00 sec 13.7 MBytes 115 Mbits/sec 222 62.7 KBytes [ 5] 6.00-7.00 sec 13.8 MBytes 116 Mbits/sec 140 44.1 KBytes [ 5] 7.00-8.00 sec 13.8 MBytes 116 Mbits/sec 114 7.13 KBytes [ 5] 8.00-9.00 sec 13.7 MBytes 115 Mbits/sec 192 7.13 KBytes [ 5] 9.00-10.00 sec 13.7 MBytes 115 Mbits/sec 220 15.7 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 137 MBytes 115 Mbits/sec 1984 sender [ 5] 0.00-10.18 sec 137 MBytes 113 Mbits/sec receiver Server output: Accepted connection from 192.168.1.148, port 52047 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.148 port 53616 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 11.2 MBytes 94.0 Mbits/sec [ 5] 1.00-2.00 sec 13.7 MBytes 115 Mbits/sec [ 5] 2.00-3.00 sec 13.7 MBytes 115 Mbits/sec [ 5] 3.00-4.00 sec 13.7 MBytes 115 Mbits/sec [ 5] 4.00-5.00 sec 13.7 MBytes 115 Mbit
Re: CFT: major update to if_ure
On Mon, Jul 27, 2020 at 5:14 AM John-Mark Gurney wrote: > Ganbold Tsagaankhuu wrote this message on Sun, Jul 26, 2020 at 11:05 +0800: > > On Sun, Jul 26, 2020 at 7:13 AM John-Mark Gurney > wrote: > > > > > Hello, > > > > > > I'd like people who have ure (RealTek) based USB devices to test > > > review D25809[0]. > > > > > > 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). > > > > Does performance improve for if_ure device on USB2? > > I will try to test it in a couple of days on NanoPI R1 and R1S boards. > > Yes, it should. > > I never tested the before driver on USB2, but I'm now able to get > 211Mbps TX and 190Mbps RX TCP, and 227Mbps TX and 225Mbps RX UDP. > > I believe it is likely that the same 91Mbps speed limit applied to > USB2 as well. > Couldn't find your iperf test scripts and I tested only tcp: root@nanopi-r1s-h5:~ # iperf3 -c 192.168.111.1 Connecting to host 192.168.111.1, port 5201 [ 5] local 192.168.111.10 port 28569 connected to 192.168.111.1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 27.4 MBytes 230 Mbits/sec0 95.4 KBytes [ 5] 1.00-2.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes [ 5] 2.00-3.00 sec 27.7 MBytes 232 Mbits/sec0 95.4 KBytes [ 5] 3.00-4.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes [ 5] 4.00-5.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes [ 5] 5.00-6.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes [ 5] 6.00-7.00 sec 27.7 MBytes 232 Mbits/sec0 95.4 KBytes [ 5] 7.00-8.00 sec 27.7 MBytes 232 Mbits/sec0 95.4 KBytes [ 5] 8.00-9.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes [ 5] 9.00-10.00 sec 27.6 MBytes 232 Mbits/sec0 95.4 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 276 MBytes 232 Mbits/sec0 sender [ 5] 0.00-10.79 sec 276 MBytes 215 Mbits/sec receiver iperf Done. root@nanopi-r1s-h5:~ # iperf3 -c 192.168.111.1 -R Connecting to host 192.168.111.1, port 5201 Reverse mode, remote host 192.168.111.1 is sending [ 5] local 192.168.111.10 port 29384 connected to 192.168.111.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 12.1 MBytes 102 Mbits/sec [ 5] 1.00-2.00 sec 12.1 MBytes 102 Mbits/sec [ 5] 2.00-3.00 sec 12.1 MBytes 101 Mbits/sec [ 5] 3.00-4.00 sec 12.1 MBytes 102 Mbits/sec [ 5] 4.00-5.00 sec 12.1 MBytes 102 Mbits/sec [ 5] 5.00-6.00 sec 12.1 MBytes 102 Mbits/sec [ 5] 6.00-7.00 sec 12.1 MBytes 101 Mbits/sec [ 5] 7.00-8.00 sec 12.1 MBytes 102 Mbits/sec [ 5] 8.00-9.00 sec 12.1 MBytes 101 Mbits/sec [ 5] 9.00-10.00 sec 12.1 MBytes 102 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-11.25 sec 121 MBytes 90.3 Mbits/sec 2539 sender [ 5] 0.00-10.00 sec 121 MBytes 101 Mbits/sec receiver iperf Done. root@nanopi-r1s-h5:~ # sysctl -a | grep cpu.0.freq dev.cpu.0.freq_levels: 1248/-1 1008/-1 816/-1 624/-1 480/-1 dev.cpu.0.freq: 1248 Ganbold > > > [0] https://reviews.freebsd.org/D25809 > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510)
Mark Millard wrote this message on Sat, Jul 25, 2020 at 19:13 -0700: > For reference for what applying the patch > reported (see Hunk #14): Ok, updated it to be relative to r363583... I had made a white spcae commit to if_ure.c, but hadn't made the patch relative to it after that commit.. should work now.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFT: major update to if_ure
Ganbold Tsagaankhuu wrote this message on Sun, Jul 26, 2020 at 11:05 +0800: > On Sun, Jul 26, 2020 at 7:13 AM John-Mark Gurney wrote: > > > Hello, > > > > I'd like people who have ure (RealTek) based USB devices to test > > review D25809[0]. > > > > 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). > > Does performance improve for if_ure device on USB2? > I will try to test it in a couple of days on NanoPI R1 and R1S boards. Yes, it should. I never tested the before driver on USB2, but I'm now able to get 211Mbps TX and 190Mbps RX TCP, and 227Mbps TX and 225Mbps RX UDP. I believe it is likely that the same 91Mbps speed limit applied to USB2 as well. > > [0] https://reviews.freebsd.org/D25809 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFT: major update to if_ure (patch did not apply cleanly for head -r363510)
For reference for what applying the patch
reported (see Hunk #14):
# patch < D25809.diff
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|Index: sys/dev/usb/net/if_ure.c
|===
|--- sys/dev/usb/net/if_ure.c
|+++ sys/dev/usb/net/if_ure.c
--
Patching file sys/dev/usb/net/if_ure.c using Plan A...
Hunk #1 succeeded at 43.
Hunk #2 succeeded at 64.
Hunk #3 succeeded at 75.
Hunk #4 succeeded at 149.
Hunk #5 succeeded at 503.
Hunk #6 succeeded at 561.
Hunk #7 succeeded at 607.
Hunk #8 succeeded at 658.
Hunk #9 succeeded at 764.
Hunk #10 succeeded at 880.
Hunk #11 succeeded at 935.
Hunk #12 succeeded at 977.
Hunk #13 succeeded at 1007.
Hunk #14 failed at 1033.
Hunk #15 succeeded at 1057.
Hunk #16 succeeded at 1071.
Hunk #17 succeeded at 1153.
Hunk #18 succeeded at 1250.
Hunk #19 succeeded at 1282.
Hunk #20 succeeded at 1340 with fuzz 2.
Hunk #21 succeeded at 1492.
Hunk #22 succeeded at 1519.
Hunk #23 succeeded at 1652.
1 out of 23 hunks failed--saving rejects to sys/dev/usb/net/if_ure.c.rej
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--
|Index: sys/dev/usb/net/if_urereg.h
|===
|--- sys/dev/usb/net/if_urereg.h
|+++ sys/dev/usb/net/if_urereg.h
--
Patching file sys/dev/usb/net/if_urereg.h using Plan A...
Hunk #1 succeeded at 391.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--
|Index: sys/modules/usb/ure/Makefile
|===
|--- sys/modules/usb/ure/Makefile
|+++ sys/modules/usb/ure/Makefile
--
Patching file sys/modules/usb/ure/Makefile using Plan A...
Hunk #1 succeeded at 5.
done
As for the .rej file content:
# more sys/dev/usb/net/if_ure.c.rej
@@ -752,6 +1033,18 @@
ure_read_2(sc, URE_PLA_FMC, URE_MCU_TYPE_PLA) |
URE_FMC_FCR_MCU_EN);
+ /* Enable RX VLANs if enabled */
+ cpcr = ure_read_2(sc, URE_PLA_CPCR, URE_MCU_TYPE_PLA);
+ if (if_getcapenable(ifp) & IFCAP_VLAN_HWTAGGING) {
+ DEVPRINTFN(13, sc->sc_ue.ue_dev, "enabled hw vlan tag\n");
+ cpcr |= URE_CPCR_RX_VLAN;
+ } else {
+ DEVPRINTFN(13, sc->sc_ue.ue_dev, "disabled hw vlan tag\n");
+ cpcr &= ~URE_CPCR_RX_VLAN;
+ }
+ ure_write_2(sc, URE_PLA_CPCR, URE_MCU_TYPE_PLA,
+ cpcr);
+
/* Enable transmit and receive. */
ure_write_1(sc, URE_PLA_CR, URE_MCU_TYPE_PLA,
ure_read_1(sc, URE_PLA_CR, URE_MCU_TYPE_PLA) | URE_CR_RE |
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CFT: major update to if_ure
On Sun, Jul 26, 2020 at 7:13 AM John-Mark Gurney wrote: > Hello, > > I'd like people who have ure (RealTek) based USB devices to test > review D25809[0]. > > 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). > Does performance improve for if_ure device on USB2? I will try to test it in a couple of days on NanoPI R1 and R1S boards. thanks, Ganbold > > Thanks. > > [0] https://reviews.freebsd.org/D25809 > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
CFT: major update to if_ure
Hello, I'd like people who have ure (RealTek) based USB devices to test review D25809[0]. 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). Thanks. [0] https://reviews.freebsd.org/D25809 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
