Messages in this thread | | | From | Sean Anderson <> | Subject | Re: [PATCH v2 08/11] net: phylink: Adjust advertisement based on rate adaptation | Date | Thu, 21 Jul 2022 15:24:50 -0400 |
| |
On 7/21/22 2:36 PM, Andrew Lunn wrote: >> I guess it would depend on the structure of the PHY - whether the PHY >> is structured similar to a two port switch internally, having a MAC >> facing the host and another MAC facing the media side. (I believe this >> is exactly how the MACSEC versions of the 88x3310 are structured.) >> >> If you don't have that kind of structure, then I would guess that doing >> duplex adaption could be problematical. > > If you don't have that sort of structure, i think rate adaptation > would have problems in general. Pause is not very fine grained. You > need to somehow buffer packets because what comes from the MAC is > likely to be bursty. And when that buffer overflows, you want to be > selective about what you throw away. You want ARP, OSPF and other > signalling packets to have priority, and user data gets > tossed. Otherwise your network collapses.
I performed some experiments using iperf to attempt to determine how things worked. On one end, I had a LS1046ARDB with an AQR113C connected via 10GBASE-R at address 10.0.0.1. On the other end, I had a custom board supporting 100BASE-TX at address 10.0.0.2. I ran tests in both directions at once. In a regular link (both sides using MII), I would expect around 90Mbit/sec in both directions for full duplex, and around 40Mbit/s in both directions for half duplex (or less?). I would also expect no retries (since collisions should be handled by the MAC and not TCP).
Direction Duplex Interval Transfer Bandwidth Write/Err Retries ========= ======== =================== ============= =============== ========== ======= 1->2 Full 0.0000-10.0185 sec 111 MBytes 92.8 Mbits/sec 888/0 0 2->1 Full 0.0000-10.0865 sec 99.1 MBytes 82.4 Mbits/sec 794/0 0 1->2 Half 0.0000-10.0098 sec 36.6 MBytes 30.7 Mbits/sec 294/0 1241 2->1 Half 0.0000-10.1764 sec 1.13 MBytes 927 Kbits/sec 10/0 155
From the second line, it appears like the 100BASE-TX device wasn't able to saturate the link. I'm not sure why that is (it doesn't match earlier test results I had), but it is reproducable with other iperf servers (so I don't think it's due to the rate adaptation).
For the second two lines, we can see that the rate adapting sender is much faster, and has many more retries. This suggests to me that the rate adapting phy is not performing collision avoidance, causing high packet loss and starving the 100BASE-TX device.
Clearly half duplex data transfer works, but I don't know if it is functioning properly.
--Sean
| |