Message ID | 1342009916-1519-1-git-send-email-hayeswang@realtek.com |
---|---|
State | Deferred, archived |
Delegated to: | David Miller |
Headers | show |
Hayes Wang <hayeswang@realtek.com> : > No waiting is needed for mac_ocp_{write / read}. And the bit 31 of > OCPDR would not change, so rtl_udelay_loop_wait_high always return > false. That is, the r8168_mac_ocp_read always retuen ~0. (testing with davem's 48ee3569f31d91084dc694fef5517eb782428083) It seemed right at first sight but testing without firmware produces unexpected results. While it is not exactly fast if I ask it to emit packets with ping -qf, it turns really slow when I use the -l preload option: at most a few hundreds pps. An old pcie 8168b in the same computer behaves correctly with the same kernel. I'll try again tomorrow evening.
Francois Romieu <romieu@fr.zoreil.com> :
[...]
> I'll try again tomorrow evening.
W/o firmware does not seem to make a difference.
# ping -qf -l 4 -s 81 -c 60 10.0.3.1
PING 10.0.3.1 (10.0.3.1) 81(109) bytes of data.
--- 10.0.3.1 ping statistics ---
60 packets transmitted, 60 received, 0% packet loss, time 153ms
rtt min/avg/max/mdev = 0.047/0.064/0.117/0.016 ms, pipe 4, ipg/ewma 2.607/0.058 ms
# ping -qf -l 4 -s 82 -c 60 10.0.3.1
PING 10.0.3.1 (10.0.3.1) 82(110) bytes of data.
--- 10.0.3.1 ping statistics ---
60 packets transmitted, 60 received, 0% packet loss, time 3ms
rtt min/avg/max/mdev = 0.195/0.210/0.281/0.018 ms, pipe 4, ipg/ewma 0.057/0.205 ms
It would translate into a 127/128 cutoff after inclusion of the FCS.
Any idea ?
Francois Romieu [mailto:romieu@fr.zoreil.com] [...] > > W/o firmware does not seem to make a difference. > > # ping -qf -l 4 -s 81 -c 60 10.0.3.1 > PING 10.0.3.1 (10.0.3.1) 81(109) bytes of data. > > --- 10.0.3.1 ping statistics --- > 60 packets transmitted, 60 received, 0% packet loss, time 153ms > rtt min/avg/max/mdev = 0.047/0.064/0.117/0.016 ms, pipe 4, > ipg/ewma 2.607/0.058 ms # ping -qf -l 4 -s 81 -c 60 192.168.94.20 PING 192.168.94.20 (192.168.94.20) 81(109) bytes of data. --- 192.168.94.20 ping statistics --- 60 packets transmitted, 57 received, 5% packet loss, time 1ms rtt min/avg/max/mdev = 0.028/0.040/0.101/0.011 ms, pipe 4, ipg/ewma 0.021/0.035 ms > # ping -qf -l 4 -s 82 -c 60 10.0.3.1 > > PING 10.0.3.1 (10.0.3.1) 82(110) bytes of data. > > --- 10.0.3.1 ping statistics --- > 60 packets transmitted, 60 received, 0% packet loss, time 3ms > rtt min/avg/max/mdev = 0.195/0.210/0.281/0.018 ms, pipe 4, > ipg/ewma 0.057/0.205 ms # ping -qf -l 4 -s 82 -c 60 192.168.94.20 PING 192.168.94.20 (192.168.94.20) 82(110) bytes of data. --- 192.168.94.20 ping statistics --- 60 packets transmitted, 60 received, 0% packet loss, time 2ms rtt min/avg/max/mdev = 0.151/0.173/0.247/0.020 ms, pipe 4, ipg/ewma 0.048/0.168 ms > It would translate into a 127/128 cutoff after inclusion of the FCS. > > Any idea ? > The attatched file is my log. It seems fine.
hayeswang <hayeswang@realtek.com> : [...] > rtt min/avg/max/mdev = 0.028/0.040/0.101/0.011 ms, pipe 4, ipg/ewma 0.021/0.035 > rtt min/avg/max/mdev = 0.151/0.173/0.247/0.020 ms, pipe 4, ipg/ewma 0.048/0.168 [...] > The attached file is my log. It seems fine. A few percents packet loss at this rate does not exactly qualify as fine. I have reproduced something similar with a 8168evl in a different slot so it does not seem to be a 8168g only behavior. I'll ask davem to pull your changes. Thanks.
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index c29c5fb..1f27318 100644 --- a/drivers/net/ethernet/realtek/r8169.c +++ b/drivers/net/ethernet/realtek/r8169.c @@ -1043,13 +1043,6 @@ static void rtl_w1w0_phy_ocp(struct rtl8169_private *tp, int reg, int p, int m) r8168_phy_ocp_write(tp, reg, (val | p) & ~m); } -DECLARE_RTL_COND(rtl_ocpdr_cond) -{ - void __iomem *ioaddr = tp->mmio_addr; - - return RTL_R32(OCPDR) & OCPAR_FLAG; -} - static void r8168_mac_ocp_write(struct rtl8169_private *tp, u32 reg, u32 data) { void __iomem *ioaddr = tp->mmio_addr; @@ -1058,8 +1051,6 @@ static void r8168_mac_ocp_write(struct rtl8169_private *tp, u32 reg, u32 data) return; RTL_W32(OCPDR, OCPAR_FLAG | (reg << 15) | data); - - rtl_udelay_loop_wait_low(tp, &rtl_ocpdr_cond, 25, 10); } static u16 r8168_mac_ocp_read(struct rtl8169_private *tp, u32 reg) @@ -1071,8 +1062,7 @@ static u16 r8168_mac_ocp_read(struct rtl8169_private *tp, u32 reg) RTL_W32(OCPDR, reg << 15); - return rtl_udelay_loop_wait_high(tp, &rtl_ocpdr_cond, 25, 10) ? - RTL_R32(OCPDR) : ~0; + return RTL_R32(OCPDR); } #define OCP_STD_PHY_BASE 0xa400
No waiting is needed for mac_ocp_{write / read}. And the bit 31 of OCPDR would not change, so rtl_udelay_loop_wait_high always return false. That is, the r8168_mac_ocp_read always retuen ~0. Signed-off-by: Hayes Wang <hayeswang@realtek.com> --- drivers/net/ethernet/realtek/r8169.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-)