* [PATCH net-next] r8169: Remove rtl_ocpdr_cond
@ 2012-07-11 12:31 Hayes Wang
2012-07-11 22:00 ` Francois Romieu
0 siblings, 1 reply; 5+ messages in thread
From: Hayes Wang @ 2012-07-11 12:31 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
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(-)
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
--
1.7.10.4
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH net-next] r8169: Remove rtl_ocpdr_cond
2012-07-11 12:31 [PATCH net-next] r8169: Remove rtl_ocpdr_cond Hayes Wang
@ 2012-07-11 22:00 ` Francois Romieu
2012-07-12 22:14 ` Francois Romieu
0 siblings, 1 reply; 5+ messages in thread
From: Francois Romieu @ 2012-07-11 22:00 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
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.
--
Ueimor
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH net-next] r8169: Remove rtl_ocpdr_cond
2012-07-11 22:00 ` Francois Romieu
@ 2012-07-12 22:14 ` Francois Romieu
2012-07-13 3:17 ` hayeswang
0 siblings, 1 reply; 5+ messages in thread
From: Francois Romieu @ 2012-07-12 22:14 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
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 ?
--
Ueimor
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [PATCH net-next] r8169: Remove rtl_ocpdr_cond
2012-07-12 22:14 ` Francois Romieu
@ 2012-07-13 3:17 ` hayeswang
2012-07-17 10:10 ` Francois Romieu
0 siblings, 1 reply; 5+ messages in thread
From: hayeswang @ 2012-07-13 3:17 UTC (permalink / raw)
To: 'Francois Romieu'; +Cc: netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]
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.
[-- Attachment #2: a.log --]
[-- Type: application/octet-stream, Size: 2638 bytes --]
# ifconfig p33p1
p33p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.94.33 netmask 255.255.255.0 broadcast 192.168.94.255
inet6 fe80::2e0:4cff:fe68:ee1c prefixlen 64 scopeid 0x20<link>
ether 00:e0:4c:68:ee:1c txqueuelen 1000 (Ethernet)
RX packets 190 bytes 23670 (23.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 226 bytes 28381 (27.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
# ethtool -i p33p1
driver: r8169
version: 2.3LK-NAPI
firmware-version:
bus-info: 0000:04:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
# dmesg | tail -n 20
[ 15.091451] NET: Registered protocol family 31
[ 15.091454] Bluetooth: HCI device and connection manager initialized
[ 15.091457] Bluetooth: HCI socket layer initialized
[ 15.091460] Bluetooth: L2CAP socket layer initialized
[ 15.091466] Bluetooth: SCO socket layer initialized
[ 15.132905] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 15.132910] Bluetooth: BNEP filters: protocol multicast
[ 25.106009] em1: no IPv6 routers present
[ 45.489144] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 45.491423] r8169 0000:04:00.0: irq 47 for MSI/MSI-X
[ 45.491854] r8169 0000:04:00.0: eth0: RTL8168g/8111g at 0xf7e86000, 00:e0:4c:68:ee:1c, XID 0c000800 IRQ 47
[ 45.491859] r8169 0000:04:00.0: eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[ 45.767173] udevd[400]: renamed network interface eth0 to p33p1
[ 45.849390] r8169 0000:04:00.0: p33p1: unable to load firmware patch rtl_nic/rtl8168g-1.fw (-2)
[ 45.852564] r8169 0000:04:00.0: p33p1: link down
[ 45.852602] r8169 0000:04:00.0: p33p1: link down
[ 45.852743] ADDRCONF(NETDEV_UP): p33p1: link is not ready
[ 48.719667] r8169 0000:04:00.0: p33p1: link up
[ 48.719803] ADDRCONF(NETDEV_CHANGE): p33p1: link becomes ready
[ 59.330009] p33p1: no IPv6 routers present
# 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 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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH net-next] r8169: Remove rtl_ocpdr_cond
2012-07-13 3:17 ` hayeswang
@ 2012-07-17 10:10 ` Francois Romieu
0 siblings, 0 replies; 5+ messages in thread
From: Francois Romieu @ 2012-07-17 10:10 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, linux-kernel
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.
--
Ueimor
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-07-17 10:10 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-11 12:31 [PATCH net-next] r8169: Remove rtl_ocpdr_cond Hayes Wang
2012-07-11 22:00 ` Francois Romieu
2012-07-12 22:14 ` Francois Romieu
2012-07-13 3:17 ` hayeswang
2012-07-17 10:10 ` Francois Romieu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox