lkml.org 
[lkml]   [2022]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v2 08/11] net: phylink: Adjust advertisement based on rate adaptation
Date
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

\
 
 \ /
  Last update: 2022-07-21 21:25    [W:0.174 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site