diff mbox

[net-next] r8169: use unlimited DMA burst for TX

Message ID 1347234926-5263-1-git-send-email-mschmidt@redhat.com
State Accepted, archived
Delegated to: David Miller
Headers show

Commit Message

Michal Schmidt Sept. 9, 2012, 11:55 p.m. UTC
The r8169 driver currently limits the DMA burst for TX to 1024 bytes. I have
a box where this prevents the interface from using the gigabit line to its full
potential. This patch solves the problem by setting TX_DMA_BURST to unlimited.

The box has an ASRock B75M motherboard with on-board RTL8168evl/8111evl
(XID 0c900880). TSO is enabled.

I used netperf (TCP_STREAM test) to measure the dependency of TX throughput
on MTU. I did it for three different values of TX_DMA_BURST ('5'=512, '6'=1024,
'7'=unlimited). This chart shows the results:
http://michich.fedorapeople.org/r8169/r8169-effects-of-TX_DMA_BURST.png

Interesting points:
 - With the current DMA burst limit (1024):
   - at the default MTU=1500 I get only 842 Mbit/s.
   - when going from small MTU, the performance rises monotonically with
     increasing MTU only up to a peak at MTU=1076 (908 MBit/s). Then there's
     a sudden drop to 762 MBit/s from which the throughput rises monotonically
     again with further MTU increases.
 - With a smaller DMA burst limit (512):
   - there's a similar peak at MTU=1076 and another one at MTU=564.
 - With unlimited DMA burst:
   - at the default MTU=1500 I get nice 940 Mbit/s.
   - the throughput rises monotonically with increasing MTU with no strange
     peaks.

Notice that the peaks occur at MTU sizes that are multiples of the DMA burst
limit plus 52. Why 52? Because:
  20 (IP header) + 20 (TCP header) + 12 (TCP options) = 52

The Realtek-provided r8168 driver (v8.032.00) uses unlimited TX DMA burst too,
except for CFG_METHOD_1 where the TX DMA burst is set to 512 bytes.
CFG_METHOD_1 appears to be the oldest MAC version of "RTL8168B/8111B",
i.e. RTL_GIGA_MAC_VER_11 in r8169. Not sure if this MAC version really needs
the smaller burst limit, or if any other versions have similar requirements.

Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
---
 drivers/net/ethernet/realtek/r8169.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Comments

David Miller Sept. 10, 2012, 7:50 p.m. UTC | #1
From: Michal Schmidt <mschmidt@redhat.com>
Date: Mon, 10 Sep 2012 01:55:26 +0200

> The r8169 driver currently limits the DMA burst for TX to 1024 bytes. I have
> a box where this prevents the interface from using the gigabit line to its full
> potential. This patch solves the problem by setting TX_DMA_BURST to unlimited.
> 
> The box has an ASRock B75M motherboard with on-board RTL8168evl/8111evl
> (XID 0c900880). TSO is enabled.
> 
> I used netperf (TCP_STREAM test) to measure the dependency of TX throughput
> on MTU. I did it for three different values of TX_DMA_BURST ('5'=512, '6'=1024,
> '7'=unlimited). This chart shows the results:
> http://michich.fedorapeople.org/r8169/r8169-effects-of-TX_DMA_BURST.png
> 
> Interesting points:
>  - With the current DMA burst limit (1024):
>    - at the default MTU=1500 I get only 842 Mbit/s.
>    - when going from small MTU, the performance rises monotonically with
>      increasing MTU only up to a peak at MTU=1076 (908 MBit/s). Then there's
>      a sudden drop to 762 MBit/s from which the throughput rises monotonically
>      again with further MTU increases.
>  - With a smaller DMA burst limit (512):
>    - there's a similar peak at MTU=1076 and another one at MTU=564.
>  - With unlimited DMA burst:
>    - at the default MTU=1500 I get nice 940 Mbit/s.
>    - the throughput rises monotonically with increasing MTU with no strange
>      peaks.
> 
> Notice that the peaks occur at MTU sizes that are multiples of the DMA burst
> limit plus 52. Why 52? Because:
>   20 (IP header) + 20 (TCP header) + 12 (TCP options) = 52
> 
> The Realtek-provided r8168 driver (v8.032.00) uses unlimited TX DMA burst too,
> except for CFG_METHOD_1 where the TX DMA burst is set to 512 bytes.
> CFG_METHOD_1 appears to be the oldest MAC version of "RTL8168B/8111B",
> i.e. RTL_GIGA_MAC_VER_11 in r8169. Not sure if this MAC version really needs
> the smaller burst limit, or if any other versions have similar requirements.
> 
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>

I really need Francois et al. to take a look at this before even thinking
about applying it.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Francois Romieu Sept. 10, 2012, 9:55 p.m. UTC | #2
David Miller <davem@davemloft.net> :
[...]
> I really need Francois et al. to take a look at this before even thinking
> about applying it.

Hayes tweaked RX_DMA_BURST to an unlimited value one year ago (see
4f6b00e5f139d7be3ca8371b769778f94fa549dd). Other than that, both
RX_DMA_BURST and TX_DMA_BURST have been set at the same (6 i.e. 1024 bytes)
value since the driver was added to the kernel tree.

Realtek's own 8169 driver uses unlimited bursts as well. However their 810x
driver doesn't (whence differing from the kernel driver after 4f6b00).

The current situation is a bit messy to say the least but it does not seem
to match any problem report. I don't have any special "don't".

Hayes, should we:
- mimic Realtek's 8168, 8169 and 810x drivers ?
- always set TX_DMA_BURST at the max value ?
- do something different (per chipset) ?

Thanks.
Hayes Wang Sept. 11, 2012, 8:09 a.m. UTC | #3
Hi, 

 Francois Romieu [mailto:romieu@fr.zoreil.com] 
> Sent: Tuesday, September 11, 2012 5:55 AM
> To: David Miller
> Cc: mschmidt@redhat.com; netdev@vger.kernel.org; Hayeswang; 
> nic_swsd; ivecera@redhat.com
> Subject: Re: [PATCH net-next] r8169: use unlimited DMA burst for TX
> 
> Hayes, should we:
> - mimic Realtek's 8168, 8169 and 810x drivers ?
> - always set TX_DMA_BURST at the max value ?
> - do something different (per chipset) ?

Our hw engineer suggets to set unlimited for both TX_DMA_BURST and RX_DMA_BURST
for all chipsets.
 
Best Regards,
Hayes


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Michal Schmidt Sept. 13, 2012, 11:27 p.m. UTC | #4
On 09/11/2012 10:09 AM, hayeswang wrote:
> [Francois Romieu wrote:]
>> Hayes, should we:
>> - mimic Realtek's 8168, 8169 and 810x drivers ?
>> - always set TX_DMA_BURST at the max value ?
>> - do something different (per chipset) ?
>
> Our hw engineer suggets to set unlimited for both TX_DMA_BURST and RX_DMA_BURST
> for all chipsets.

Francois,
as this is exactly what the patch does, would you give an ACK?

Michal

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Francois Romieu Sept. 14, 2012, 5:19 a.m. UTC | #5
Michal Schmidt <mschmidt@redhat.com> :
[...]
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>

Acked-by: Francois Romieu <romieu@fr.zoreil.com>
David Miller Sept. 19, 2012, 11:19 p.m. UTC | #6
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Fri, 14 Sep 2012 07:19:32 +0200

> Michal Schmidt <mschmidt@redhat.com> :
> [...]
>> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
> 
> Acked-by: Francois Romieu <romieu@fr.zoreil.com>

Applied, thanks everyone.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index b47d5b3..549314f 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -77,7 +77,7 @@ 
 static const int multicast_filter_limit = 32;
 
 #define MAX_READ_REQUEST_SHIFT	12
-#define TX_DMA_BURST	6	/* Maximum PCI burst, '6' is 1024 */
+#define TX_DMA_BURST	7	/* Maximum PCI burst, '7' is unlimited */
 #define SafeMtu		0x1c20	/* ... actually life sucks beyond ~7k */
 #define InterFrameGap	0x03	/* 3 means InterFrameGap = the shortest one */