* [PATCH 0/4] simple generic timer infrastructure and stmmac example
From: Peppe CAVALLARO @ 2011-02-22 10:17 UTC (permalink / raw)
To: linux-sh@vger.kernel.org, netdev@vger.kernel.org
Cc: Stuart MENEFY, Peppe CAVALLARO
Many devices targeted at the embedded market provide a number of
generic timers which are capable of generating interrupts at a
requested rate. These can then be used in the implementation of drivers
for other peripherals which require a timer interrupt, without having
to provide an additional timer as part of that peripheral.
A code provides a simple abstraction layer which allows a timer to be
registered, and for a driver to request a timer.
Currently this doesn't provide any of the additional information, such
as precision or position in clock framework which might be required
for a fully featured driver.
This patches also updates the stmmac Network device driver to use
the generic timer infrastructure The timer is used for mitigating
the number of the interrupts. This helps many people to save the
CPU on STM platforms with MAC10/100 and GMAC device without an
embedded timer.
Welcome comments and review.
Giuseppe Cavallaro (3):
sh_timer: add the support to use the generic timer
stmmac: switch to use the new generic timer interface
stmmac: rework and improvement the stmmac timer
Stuart Menefy (1):
clksource: Generic timer infrastructure
drivers/clocksource/Makefile | 1 +
drivers/clocksource/generictimer.c | 60 +++++++++++++++++++++
drivers/clocksource/sh_tmu.c | 72 +++++++++++++++++++++++++
drivers/net/stmmac/Kconfig | 19 ++++---
drivers/net/stmmac/Makefile | 2 +-
drivers/net/stmmac/common.h | 6 ++
drivers/net/stmmac/stmmac.h | 5 +-
drivers/net/stmmac/stmmac_main.c | 66 ++++++++++++-----------
drivers/net/stmmac/stmmac_timer.c | 103 +++++++++++++++++++++---------------
drivers/net/stmmac/stmmac_timer.h | 12 ++---
include/linux/generictimer.h | 41 ++++++++++++++
11 files changed, 295 insertions(+), 92 deletions(-)
create mode 100644 drivers/clocksource/generictimer.c
create mode 100644 include/linux/generictimer.h
--
1.7.4
^ permalink raw reply
* [PATCH 2/3] net/r8169: fix the wrong parameter of point address
From: Hayes Wang @ 2011-02-22 9:26 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1298366782-1508-1-git-send-email-hayeswang@realtek.com>
Correct the parameter of rtl8168_oob_notify. It results in the
wrong point address and influences RTL8168DP.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 3630dd7..336ba94 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -617,8 +617,9 @@ static void ocp_write(struct rtl8169_private *tp, u8 mask, u16 reg, u32 data)
}
}
-static void rtl8168_oob_notify(void __iomem *ioaddr, u8 cmd)
+static void rtl8168_oob_notify(struct rtl8169_private *tp, u8 cmd)
{
+ void __iomem *ioaddr = tp->mmio_addr;
int i;
RTL_W8(ERIDR, cmd);
@@ -630,7 +631,7 @@ static void rtl8168_oob_notify(void __iomem *ioaddr, u8 cmd)
break;
}
- ocp_write(ioaddr, 0x1, 0x30, 0x00000001);
+ ocp_write(tp, 0x1, 0x30, 0x00000001);
}
#define OOB_CMD_RESET 0x00
--
1.7.3.2
^ permalink raw reply related
* [PATCH 3/3] net/r8169: fix RTL8168DP issue
From: Hayes Wang @ 2011-02-22 9:26 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1298366782-1508-1-git-send-email-hayeswang@realtek.com>
Fix the RTL8111DP turn off the power when DASH is enabled.
Fix RTL_GIGA_MAC_VER_27 don't wait tx finish before reset.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 336ba94..ef2133b 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2869,8 +2869,11 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
- if (tp->mac_version == RTL_GIGA_MAC_VER_27)
+ if (((tp->mac_version == RTL_GIGA_MAC_VER_27) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_28)) &&
+ (ocp_read(tp, 0x0f, 0x0010) & 0x00008000)) {
return;
+ }
if (((tp->mac_version == RTL_GIGA_MAC_VER_23) ||
(tp->mac_version == RTL_GIGA_MAC_VER_24)) &&
@@ -2892,6 +2895,8 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
switch (tp->mac_version) {
case RTL_GIGA_MAC_VER_25:
case RTL_GIGA_MAC_VER_26:
+ case RTL_GIGA_MAC_VER_27:
+ case RTL_GIGA_MAC_VER_28:
RTL_W8(PMCH, RTL_R8(PMCH) & ~0x80);
break;
}
@@ -2901,12 +2906,17 @@ static void r8168_pll_power_up(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
- if (tp->mac_version == RTL_GIGA_MAC_VER_27)
+ if (((tp->mac_version == RTL_GIGA_MAC_VER_27) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_28)) &&
+ (ocp_read(tp, 0x0f, 0x0010) & 0x00008000)) {
return;
+ }
switch (tp->mac_version) {
case RTL_GIGA_MAC_VER_25:
case RTL_GIGA_MAC_VER_26:
+ case RTL_GIGA_MAC_VER_27:
+ case RTL_GIGA_MAC_VER_28:
RTL_W8(PMCH, RTL_R8(PMCH) | 0x80);
break;
}
@@ -3319,7 +3329,8 @@ static void rtl8169_hw_reset(struct rtl8169_private *tp)
/* Disable interrupts */
rtl8169_irq_mask_and_ack(ioaddr);
- if (tp->mac_version == RTL_GIGA_MAC_VER_28) {
+ if (tp->mac_version == RTL_GIGA_MAC_VER_27 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_28) {
while (RTL_R8(TxPoll) & NPQ)
udelay(20);
--
1.7.3.2
^ permalink raw reply related
* [PATCH 2/2] net/r8169: Support RTL8105E
From: Hayes Wang @ 2011-02-22 9:26 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1298366782-1508-1-git-send-email-hayeswang@realtek.com>
Support the new chips for RTL8105E
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 90 insertions(+), 2 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index de94489..2543edd 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -36,6 +36,7 @@
#define FIRMWARE_8168D_1 "rtl_nic/rtl8168d-1.fw"
#define FIRMWARE_8168D_2 "rtl_nic/rtl8168d-2.fw"
+#define FIRMWARE_8105E_1 "rtl_nic/rtl8105e-1.fw"
#ifdef RTL8169_DEBUG
#define assert(expr) \
@@ -123,6 +124,8 @@ enum mac_version {
RTL_GIGA_MAC_VER_26 = 0x1a, // 8168D
RTL_GIGA_MAC_VER_27 = 0x1b, // 8168DP
RTL_GIGA_MAC_VER_28 = 0x1c, // 8168DP
+ RTL_GIGA_MAC_VER_29 = 0x1d, // 8105E
+ RTL_GIGA_MAC_VER_30 = 0x1e, // 8105E
};
#define _R(NAME,MAC,MASK) \
@@ -160,7 +163,9 @@ static const struct {
_R("RTL8168d/8111d", RTL_GIGA_MAC_VER_25, 0xff7e1880), // PCI-E
_R("RTL8168d/8111d", RTL_GIGA_MAC_VER_26, 0xff7e1880), // PCI-E
_R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_27, 0xff7e1880), // PCI-E
- _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_28, 0xff7e1880) // PCI-E
+ _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_28, 0xff7e1880), // PCI-E
+ _R("RTL8105e", RTL_GIGA_MAC_VER_29, 0xff7e1880), // PCI-E
+ _R("RTL8105e", RTL_GIGA_MAC_VER_30, 0xff7e1880) // PCI-E
};
#undef _R
@@ -267,9 +272,15 @@ enum rtl8168_8101_registers {
#define EPHYAR_REG_MASK 0x1f
#define EPHYAR_REG_SHIFT 16
#define EPHYAR_DATA_MASK 0xffff
+ DLLPR = 0xd0,
+#define PM_SWITCH (1 << 6)
DBG_REG = 0xd1,
#define FIX_NAK_1 (1 << 4)
#define FIX_NAK_2 (1 << 3)
+ TWSI = 0xd2,
+ MCU = 0xd3,
+#define EN_NDP (1 << 3)
+#define EN_OOB_RESET (1 << 2)
EFUSEAR = 0xdc,
#define EFUSEAR_FLAG 0x80000000
#define EFUSEAR_WRITE_CMD 0x80000000
@@ -568,6 +579,7 @@ MODULE_LICENSE("GPL");
MODULE_VERSION(RTL8169_VERSION);
MODULE_FIRMWARE(FIRMWARE_8168D_1);
MODULE_FIRMWARE(FIRMWARE_8168D_2);
+MODULE_FIRMWARE(FIRMWARE_8105E_1);
static int rtl8169_open(struct net_device *dev);
static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
@@ -1145,7 +1157,9 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
(tp->mac_version != RTL_GIGA_MAC_VER_13) &&
(tp->mac_version != RTL_GIGA_MAC_VER_14) &&
(tp->mac_version != RTL_GIGA_MAC_VER_15) &&
- (tp->mac_version != RTL_GIGA_MAC_VER_16)) {
+ (tp->mac_version != RTL_GIGA_MAC_VER_16) &&
+ (tp->mac_version != RTL_GIGA_MAC_VER_29) &&
+ (tp->mac_version != RTL_GIGA_MAC_VER_30)) {
giga_ctrl |= ADVERTISE_1000FULL | ADVERTISE_1000HALF;
} else {
netif_info(tp, link, dev,
@@ -1547,6 +1561,9 @@ static void rtl8169_get_mac_version(struct rtl8169_private *tp,
{ 0x7c800000, 0x30000000, RTL_GIGA_MAC_VER_11 },
/* 8101 family. */
+ { 0x7cf00000, 0x40a00000, RTL_GIGA_MAC_VER_30 },
+ { 0x7cf00000, 0x40900000, RTL_GIGA_MAC_VER_29 },
+ { 0x7c800000, 0x40800000, RTL_GIGA_MAC_VER_30 },
{ 0x7cf00000, 0x34a00000, RTL_GIGA_MAC_VER_09 },
{ 0x7cf00000, 0x24a00000, RTL_GIGA_MAC_VER_09 },
{ 0x7cf00000, 0x34900000, RTL_GIGA_MAC_VER_08 },
@@ -2423,6 +2440,33 @@ static void rtl8102e_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
}
+static void rtl8105e_hw_phy_config(struct rtl8169_private *tp)
+{
+ static const struct phy_reg phy_reg_init[] = {
+ { 0x1f, 0x0005 },
+ { 0x1a, 0x0000 },
+ { 0x1f, 0x0000 },
+
+ { 0x1f, 0x0004 },
+ { 0x1c, 0x0000 },
+ { 0x1f, 0x0000 },
+
+ { 0x1f, 0x0001 },
+ { 0x15, 0x7701 },
+ { 0x1f, 0x0000 }
+ };
+
+ /* Disable ALDPS before ram code */
+ rtl_writephy(tp, 0x1f, 0x0000);
+ rtl_writephy(tp, 0x18, 0x0310);
+ msleep(100);
+
+ if (rtl_apply_firmware(tp, FIRMWARE_8105E_1) < 0)
+ netif_warn(tp, probe, tp->dev, "unable to apply firmware patch\n");
+
+ rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
+}
+
static void rtl_hw_phy_config(struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
@@ -2490,6 +2534,10 @@ static void rtl_hw_phy_config(struct net_device *dev)
case RTL_GIGA_MAC_VER_28:
rtl8168d_4_hw_phy_config(tp);
break;
+ case RTL_GIGA_MAC_VER_29:
+ case RTL_GIGA_MAC_VER_30:
+ rtl8105e_hw_phy_config(tp);
+ break;
default:
break;
@@ -2928,6 +2976,8 @@ static void __devinit rtl_init_pll_power_ops(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_09:
case RTL_GIGA_MAC_VER_10:
case RTL_GIGA_MAC_VER_16:
+ case RTL_GIGA_MAC_VER_29:
+ case RTL_GIGA_MAC_VER_30:
ops->down = r810x_pll_power_down;
ops->up = r810x_pll_power_up;
break;
@@ -3890,6 +3940,37 @@ static void rtl_hw_start_8102e_3(void __iomem *ioaddr, struct pci_dev *pdev)
rtl_ephy_write(ioaddr, 0x03, 0xc2f9);
}
+static void rtl_hw_start_8105e_1(void __iomem *ioaddr, struct pci_dev *pdev)
+{
+ static const struct ephy_info e_info_8105e_1[] = {
+ { 0x07, 0, 0x4000 },
+ { 0x19, 0, 0x0200 },
+ { 0x19, 0, 0x0020 },
+ { 0x1e, 0, 0x2000 },
+ { 0x03, 0, 0x0001 },
+ { 0x19, 0, 0x0100 },
+ { 0x19, 0, 0x0004 },
+ { 0x0a, 0, 0x0020 }
+ };
+
+ /* Force LAN exit from ASPM if Rx/Tx are not idel */
+ RTL_W32(FuncEvent, RTL_R32(FuncEvent) | 0x002800);
+
+ /* disable Early Tally Counter */
+ RTL_W32(FuncEvent, RTL_R32(FuncEvent) & ~0x010000);
+
+ RTL_W8(MCU, RTL_R8(MCU) | EN_NDP | EN_OOB_RESET);
+ RTL_W8(DLLPR, RTL_R8(DLLPR) | PM_SWITCH);
+
+ rtl_ephy_init(ioaddr, e_info_8105e_1, ARRAY_SIZE(e_info_8105e_1));
+}
+
+static void rtl_hw_start_8105e_2(void __iomem *ioaddr, struct pci_dev *pdev)
+{
+ rtl_hw_start_8105e_1(ioaddr, pdev);
+ rtl_ephy_write(ioaddr, 0x1e, rtl_ephy_read(ioaddr, 0x1e) | 0x8000);
+}
+
static void rtl_hw_start_8101(struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
@@ -3918,6 +3999,13 @@ static void rtl_hw_start_8101(struct net_device *dev)
case RTL_GIGA_MAC_VER_09:
rtl_hw_start_8102e_2(ioaddr, pdev);
break;
+
+ case RTL_GIGA_MAC_VER_29:
+ rtl_hw_start_8105e_1(ioaddr, pdev);
+ break;
+ case RTL_GIGA_MAC_VER_30:
+ rtl_hw_start_8105e_2(ioaddr, pdev);
+ break;
}
RTL_W8(Cfg9346, Cfg9346_Unlock);
--
1.7.3.2
^ permalink raw reply related
* [PATCH 1/3] net/r8169: Correct settings of rtl8102e
From: Hayes Wang @ 2011-02-22 9:26 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1298366782-1508-1-git-send-email-hayeswang@realtek.com>
Adjust and remove certain settings of RTL8102E which are for previous chips.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 20 ++++++--------------
1 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 469ab0b..3630dd7 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -3042,7 +3042,7 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
goto err_out_mwi_2;
}
- tp->cp_cmd = PCIMulRW | RxChkSum;
+ tp->cp_cmd = RxChkSum;
if ((sizeof(dma_addr_t) > 4) &&
!pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) && use_dac) {
@@ -3847,8 +3847,7 @@ static void rtl_hw_start_8168(struct net_device *dev)
Cxpl_dbg_sel | \
ASF | \
PktCntrDisable | \
- PCIDAC | \
- PCIMulRW)
+ Mac_dbgo_sel)
static void rtl_hw_start_8102e_1(void __iomem *ioaddr, struct pci_dev *pdev)
{
@@ -3878,8 +3877,6 @@ static void rtl_hw_start_8102e_1(void __iomem *ioaddr, struct pci_dev *pdev)
if ((cfg1 & LEDS0) && (cfg1 & LEDS1))
RTL_W8(Config1, cfg1 & ~LEDS0);
- RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) & ~R810X_CPCMD_QUIRK_MASK);
-
rtl_ephy_init(ioaddr, e_info_8102e_1, ARRAY_SIZE(e_info_8102e_1));
}
@@ -3891,8 +3888,6 @@ static void rtl_hw_start_8102e_2(void __iomem *ioaddr, struct pci_dev *pdev)
RTL_W8(Config1, MEMMAP | IOMAP | VPD | PMEnable);
RTL_W8(Config3, RTL_R8(Config3) & ~Beacon_en);
-
- RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) & ~R810X_CPCMD_QUIRK_MASK);
}
static void rtl_hw_start_8102e_3(void __iomem *ioaddr, struct pci_dev *pdev)
@@ -3918,6 +3913,8 @@ static void rtl_hw_start_8101(struct net_device *dev)
}
}
+ RTL_W8(Cfg9346, Cfg9346_Unlock);
+
switch (tp->mac_version) {
case RTL_GIGA_MAC_VER_07:
rtl_hw_start_8102e_1(ioaddr, pdev);
@@ -3932,14 +3929,13 @@ static void rtl_hw_start_8101(struct net_device *dev)
break;
}
- RTL_W8(Cfg9346, Cfg9346_Unlock);
+ RTL_W8(Cfg9346, Cfg9346_Lock);
RTL_W8(MaxTxPacketSize, TxPacketMax);
rtl_set_rx_max_size(ioaddr, rx_buf_sz);
- tp->cp_cmd |= rtl_rw_cpluscmd(ioaddr) | PCIMulRW;
-
+ tp->cp_cmd &= ~R810X_CPCMD_QUIRK_MASK;
RTL_W16(CPlusCmd, tp->cp_cmd);
RTL_W16(IntrMitigate, 0x0000);
@@ -3949,14 +3945,10 @@ static void rtl_hw_start_8101(struct net_device *dev)
RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
rtl_set_rx_tx_config_registers(tp);
- RTL_W8(Cfg9346, Cfg9346_Lock);
-
RTL_R8(IntrMask);
rtl_set_rx_mode(dev);
- RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
-
RTL_W16(MultiIntr, RTL_R16(MultiIntr) & 0xf000);
RTL_W16(IntrMask, tp->intr_event);
--
1.7.3.2
^ permalink raw reply related
* [PATCH 1/2] net/r8169: adjust rtl8169_set_speed_xmii function
From: Hayes Wang @ 2011-02-22 9:26 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
Adjust code of rtl8169_set_speed_xmii function and remove part
codes which have done in rtl_pll_power_up function.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 16 ++--------------
1 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 469ab0b..de94489 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1124,6 +1124,8 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
struct rtl8169_private *tp = netdev_priv(dev);
int giga_ctrl, bmcr;
+ rtl_writephy(tp, 0x1f, 0x0000);
+
if (autoneg == AUTONEG_ENABLE) {
int auto_nego;
@@ -1152,18 +1154,6 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
bmcr = BMCR_ANENABLE | BMCR_ANRESTART;
- if ((tp->mac_version == RTL_GIGA_MAC_VER_11) ||
- (tp->mac_version == RTL_GIGA_MAC_VER_12) ||
- (tp->mac_version >= RTL_GIGA_MAC_VER_17)) {
- /*
- * Wake up the PHY.
- * Vendor specific (0x1f) and reserved (0x0e) MII
- * registers.
- */
- rtl_writephy(tp, 0x1f, 0x0000);
- rtl_writephy(tp, 0x0e, 0x0000);
- }
-
rtl_writephy(tp, MII_ADVERTISE, auto_nego);
rtl_writephy(tp, MII_CTRL1000, giga_ctrl);
} else {
@@ -1178,8 +1168,6 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
if (duplex == DUPLEX_FULL)
bmcr |= BMCR_FULLDPLX;
-
- rtl_writephy(tp, 0x1f, 0x0000);
}
tp->phy_1000_ctrl_reg = giga_ctrl;
--
1.7.3.2
^ permalink raw reply related
* Re: [PATCH] ipvs: fix dst_lock locking on dest update
From: Hans Schillstrom @ 2011-02-22 9:11 UTC (permalink / raw)
To: Julian Anastasov; +Cc: David S. Miller, netdev, lvs-devel, Simon Horman
>---- Original Message ----
>From: Julian Anastasov <ja@ssi.bg>
>To: "David S. Miller" <davem@davemloft.net>
>Cc: netdev@vger.kernel.org, lvs-devel@vger.kernel.org, "Simon Horman" <horms@verge.net.au>
>Sent: Tue, Feb 22, 2011, 9:36 AM
>Subject: [PATCH] ipvs: fix dst_lock locking on dest update
>
>Fix dst_lock usage in __ip_vs_update_dest. We need
>_bh locking because destination is updated in user context.
>Can cause lockups on frequent destination updates.
>Problem reported by Simon Kirby. Bug was introduced
>in 2.6.37 from the "ipvs: changes for local real server"
>change.
>
>Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Hans Schillstrom <hans@schillstrom.com>
>---
>
> Dave, please apply to net-2.6.
>Patch is for 2.6.37+ and applies to 2.6.38-rc6. There is
>little fuzz when applying to net-next, let me know if
>I should provide patch for other trees.
The patch seems to be OK in 2.6.38 expcept for line number.
All my thest runs without any problems.
>
>--- linux-2.6.37/net/netfilter/ipvs/ip_vs_ctl.c 2011-01-06 00:01:23.600069161 +0200
>+++ linux/net/netfilter/ipvs/ip_vs_ctl.c 2011-02-19 23:14:44.463250743 +0200
>@@ -810,9 +810,9 @@ __ip_vs_update_dest(struct ip_vs_service
> dest->u_threshold = udest->u_threshold;
> dest->l_threshold = udest->l_threshold;
>
>- spin_lock(&dest->dst_lock);
>+ spin_lock_bh(&dest->dst_lock);
> ip_vs_dst_reset(dest);
>- spin_unlock(&dest->dst_lock);
>+ spin_unlock_bh(&dest->dst_lock);
>
> if (add)
> ip_vs_new_estimator(&dest->stats);
>--
Hans Schillstrom <hans@schillstrom.com>
^ permalink raw reply
* RE: [PATCH 3/5] r8169: fix the wrong parameter of point address
From: hayeswang @ 2011-02-22 8:46 UTC (permalink / raw)
To: 'Francois Romieu'; +Cc: netdev, linux-kernel
In-Reply-To: <20110222082153.GA12463@electric-eye.fr.zoreil.com>
> -----Original Message-----
> From: Francois Romieu [mailto:romieu@fr.zoreil.com]
> Sent: Tuesday, February 22, 2011 4:22 PM
> To: Hayeswang
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 3/5] r8169: fix the wrong parameter of
> point address
>
> Francois Romieu <romieu@fr.zoreil.com> :
> > Hayes Wang <hayeswang@realtek.com> :
> > > Correct the parameter of rtl8168_oob_notify. It results
> in the wrong
> > > point address and influences RTL8168DP.
> >
> > Please send this one separately as a patch against current
> kernel tree
> > as it is clearly a bugfix. The remaining patches are probably more
> > -next material.
>
> Correct me if I am wrong:
> - #3 and #1 are bugfixes
> - can you specify if #4 and #5 are either bugfixes,
> optimizations or cleanups ?
> - #2 adds support for a new chipset
#1, #3, #4 are bugfixes.
#2 adds support for a new chipset
#5 is cleanup.
I would separate them and send the patches again.
Best Regards,
Hayes
^ permalink raw reply
* [PATCH] ipvs: fix dst_lock locking on dest update
From: Julian Anastasov @ 2011-02-22 8:40 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, lvs-devel, Simon Horman
Fix dst_lock usage in __ip_vs_update_dest. We need
_bh locking because destination is updated in user context.
Can cause lockups on frequent destination updates.
Problem reported by Simon Kirby. Bug was introduced
in 2.6.37 from the "ipvs: changes for local real server"
change.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
Dave, please apply to net-2.6.
Patch is for 2.6.37+ and applies to 2.6.38-rc6. There is
little fuzz when applying to net-next, let me know if
I should provide patch for other trees.
--- linux-2.6.37/net/netfilter/ipvs/ip_vs_ctl.c 2011-01-06 00:01:23.600069161 +0200
+++ linux/net/netfilter/ipvs/ip_vs_ctl.c 2011-02-19 23:14:44.463250743 +0200
@@ -810,9 +810,9 @@ __ip_vs_update_dest(struct ip_vs_service
dest->u_threshold = udest->u_threshold;
dest->l_threshold = udest->l_threshold;
- spin_lock(&dest->dst_lock);
+ spin_lock_bh(&dest->dst_lock);
ip_vs_dst_reset(dest);
- spin_unlock(&dest->dst_lock);
+ spin_unlock_bh(&dest->dst_lock);
if (add)
ip_vs_new_estimator(&dest->stats);
^ permalink raw reply
* Re: [PATCH 3/5] r8169: fix the wrong parameter of point address
From: Francois Romieu @ 2011-02-22 8:21 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <20110222080017.GA12453@electric-eye.fr.zoreil.com>
Francois Romieu <romieu@fr.zoreil.com> :
> Hayes Wang <hayeswang@realtek.com> :
> > Correct the parameter of rtl8168_oob_notify. It results in the
> > wrong point address and influences RTL8168DP.
>
> Please send this one separately as a patch against current kernel
> tree as it is clearly a bugfix. The remaining patches are probably
> more -next material.
Correct me if I am wrong:
- #3 and #1 are bugfixes
- can you specify if #4 and #5 are either bugfixes, optimizations or cleanups ?
- #2 adds support for a new chipset
--
Ueimor
^ permalink raw reply
* Re: [PATCH 3/5] r8169: fix the wrong parameter of point address
From: Francois Romieu @ 2011-02-22 8:00 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <1298356917-486-3-git-send-email-hayeswang@realtek.com>
Hayes Wang <hayeswang@realtek.com> :
> Correct the parameter of rtl8168_oob_notify. It results in the
> wrong point address and influences RTL8168DP.
Please send this one separately as a patch against current kernel
tree as it is clearly a bugfix. The remaining patches are probably
more -next material.
--
Ueimor
^ permalink raw reply
* Re: [v3 RFC PATCH 0/4] Implement multiqueue virtio-net
From: Simon Horman @ 2011-02-22 7:47 UTC (permalink / raw)
To: Krishna Kumar
Cc: rusty, davem, mst, arnd, eric.dumazet, netdev, avi, anthony, kvm
In-Reply-To: <20101020085452.15579.76002.sendpatchset@krkumar2.in.ibm.com>
On Wed, Oct 20, 2010 at 02:24:52PM +0530, Krishna Kumar wrote:
> Following set of patches implement transmit MQ in virtio-net. Also
> included is the user qemu changes. MQ is disabled by default unless
> qemu specifies it.
Hi Krishna,
I have a few questions about the results below:
1. Are the (%) comparisons between non-mq and mq virtio?
2. Was UDP or TCP used?
3. What was the transmit size (-m option to netperf)?
Also, I'm interested to know what the status of these patches is.
Are you planing a fresh series?
>
> Changes from rev2:
> ------------------
> 1. Define (in virtio_net.h) the maximum send txqs; and use in
> virtio-net and vhost-net.
> 2. vi->sq[i] is allocated individually, resulting in cache line
> aligned sq[0] to sq[n]. Another option was to define
> 'send_queue' as:
> struct send_queue {
> struct virtqueue *svq;
> struct scatterlist tx_sg[MAX_SKB_FRAGS + 2];
> } ____cacheline_aligned_in_smp;
> and to statically allocate 'VIRTIO_MAX_SQ' of those. I hope
> the submitted method is preferable.
> 3. Changed vhost model such that vhost[0] handles RX and vhost[1-MAX]
> handles TX[0-n].
> 4. Further change TX handling such that vhost[0] handles both RX/TX
> for single stream case.
>
> Enabling MQ on virtio:
> -----------------------
> When following options are passed to qemu:
> - smp > 1
> - vhost=on
> - mq=on (new option, default:off)
> then #txqueues = #cpus. The #txqueues can be changed by using an
> optional 'numtxqs' option. e.g. for a smp=4 guest:
> vhost=on -> #txqueues = 1
> vhost=on,mq=on -> #txqueues = 4
> vhost=on,mq=on,numtxqs=2 -> #txqueues = 2
> vhost=on,mq=on,numtxqs=8 -> #txqueues = 8
>
>
> Performance (guest -> local host):
> -----------------------------------
> System configuration:
> Host: 8 Intel Xeon, 8 GB memory
> Guest: 4 cpus, 2 GB memory
> Test: Each test case runs for 60 secs, sum over three runs (except
> when number of netperf sessions is 1, which has 10 runs of 12 secs
> each). No tuning (default netperf) other than taskset vhost's to
> cpus 0-3. numtxqs=32 gave the best results though the guest had
> only 4 vcpus (I haven't tried beyond that).
>
> ______________ numtxqs=2, vhosts=3 ____________________
> #sessions BW% CPU% RCPU% SD% RSD%
> ________________________________________________________
> 1 4.46 -1.96 .19 -12.50 -6.06
> 2 4.93 -1.16 2.10 0 -2.38
> 4 46.17 64.77 33.72 19.51 -2.48
> 8 47.89 70.00 36.23 41.46 13.35
> 16 48.97 80.44 40.67 21.11 -5.46
> 24 49.03 78.78 41.22 20.51 -4.78
> 32 51.11 77.15 42.42 15.81 -6.87
> 40 51.60 71.65 42.43 9.75 -8.94
> 48 50.10 69.55 42.85 11.80 -5.81
> 64 46.24 68.42 42.67 14.18 -3.28
> 80 46.37 63.13 41.62 7.43 -6.73
> 96 46.40 63.31 42.20 9.36 -4.78
> 128 50.43 62.79 42.16 13.11 -1.23
> ________________________________________________________
> BW: 37.2%, CPU/RCPU: 66.3%,41.6%, SD/RSD: 11.5%,-3.7%
>
> ______________ numtxqs=8, vhosts=5 ____________________
> #sessions BW% CPU% RCPU% SD% RSD%
> ________________________________________________________
> 1 -.76 -1.56 2.33 0 3.03
> 2 17.41 11.11 11.41 0 -4.76
> 4 42.12 55.11 30.20 19.51 .62
> 8 54.69 80.00 39.22 24.39 -3.88
> 16 54.77 81.62 40.89 20.34 -6.58
> 24 54.66 79.68 41.57 15.49 -8.99
> 32 54.92 76.82 41.79 17.59 -5.70
> 40 51.79 68.56 40.53 15.31 -3.87
> 48 51.72 66.40 40.84 9.72 -7.13
> 64 51.11 63.94 41.10 5.93 -8.82
> 80 46.51 59.50 39.80 9.33 -4.18
> 96 47.72 57.75 39.84 4.20 -7.62
> 128 54.35 58.95 40.66 3.24 -8.63
> ________________________________________________________
> BW: 38.9%, CPU/RCPU: 63.0%,40.1%, SD/RSD: 6.0%,-7.4%
>
> ______________ numtxqs=16, vhosts=5 ___________________
> #sessions BW% CPU% RCPU% SD% RSD%
> ________________________________________________________
> 1 -1.43 -3.52 1.55 0 3.03
> 2 33.09 21.63 20.12 -10.00 -9.52
> 4 67.17 94.60 44.28 19.51 -11.80
> 8 75.72 108.14 49.15 25.00 -10.71
> 16 80.34 101.77 52.94 25.93 -4.49
> 24 70.84 93.12 43.62 27.63 -5.03
> 32 69.01 94.16 47.33 29.68 -1.51
> 40 58.56 63.47 25.91 -3.92 -25.85
> 48 61.16 74.70 34.88 .89 -22.08
> 64 54.37 69.09 26.80 -6.68 -30.04
> 80 36.22 22.73 -2.97 -8.25 -27.23
> 96 41.51 50.59 13.24 9.84 -16.77
> 128 48.98 38.15 6.41 -.33 -22.80
> ________________________________________________________
> BW: 46.2%, CPU/RCPU: 55.2%,18.8%, SD/RSD: 1.2%,-22.0%
>
> ______________ numtxqs=32, vhosts=5 ___________________
> # BW% CPU% RCPU% SD% RSD%
> ________________________________________________________
> 1 7.62 -38.03 -26.26 -50.00 -33.33
> 2 28.95 20.46 21.62 0 -7.14
> 4 84.05 60.79 45.74 -2.43 -12.42
> 8 86.43 79.57 50.32 15.85 -3.10
> 16 88.63 99.48 58.17 9.47 -13.10
> 24 74.65 80.87 41.99 -1.81 -22.89
> 32 63.86 59.21 23.58 -18.13 -36.37
> 40 64.79 60.53 22.23 -15.77 -35.84
> 48 49.68 26.93 .51 -36.40 -49.61
> 64 54.69 36.50 5.41 -26.59 -43.23
> 80 45.06 12.72 -13.25 -37.79 -52.08
> 96 40.21 -3.16 -24.53 -39.92 -52.97
> 128 36.33 -33.19 -43.66 -5.68 -20.49
> ________________________________________________________
> BW: 49.3%, CPU/RCPU: 15.5%,-8.2%, SD/RSD: -22.2%,-37.0%
>
>
> Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
> ---
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 5/5] r8169: adjust rtl8169_set_speed_xmii function
From: Hayes Wang @ 2011-02-22 6:41 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1298356917-486-1-git-send-email-hayeswang@realtek.com>
Adjust code of rtl8169_set_speed_xmii function and remove part
codes which have done in rtl_pll_power_up function.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 16 ++--------------
1 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 9e7e3b3..8c85545 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1137,6 +1137,8 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
struct rtl8169_private *tp = netdev_priv(dev);
int giga_ctrl, bmcr;
+ rtl_writephy(tp, 0x1f, 0x0000);
+
if (autoneg == AUTONEG_ENABLE) {
int auto_nego;
@@ -1167,18 +1169,6 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
bmcr = BMCR_ANENABLE | BMCR_ANRESTART;
- if ((tp->mac_version == RTL_GIGA_MAC_VER_11) ||
- (tp->mac_version == RTL_GIGA_MAC_VER_12) ||
- (tp->mac_version >= RTL_GIGA_MAC_VER_17)) {
- /*
- * Wake up the PHY.
- * Vendor specific (0x1f) and reserved (0x0e) MII
- * registers.
- */
- rtl_writephy(tp, 0x1f, 0x0000);
- rtl_writephy(tp, 0x0e, 0x0000);
- }
-
rtl_writephy(tp, MII_ADVERTISE, auto_nego);
rtl_writephy(tp, MII_CTRL1000, giga_ctrl);
} else {
@@ -1193,8 +1183,6 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
if (duplex == DUPLEX_FULL)
bmcr |= BMCR_FULLDPLX;
-
- rtl_writephy(tp, 0x1f, 0x0000);
}
tp->phy_1000_ctrl_reg = giga_ctrl;
--
1.7.3.2
^ permalink raw reply related
* [PATCH 4/5] r8169: adjust the code of RTL8168DP
From: Hayes Wang @ 2011-02-22 6:41 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1298356917-486-1-git-send-email-hayeswang@realtek.com>
Adjust the code of power up and down functions for RTL8168DP.
Skip these functions when DASH is enable.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index ff66aa6..9e7e3b3 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2917,8 +2917,11 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
- if (tp->mac_version == RTL_GIGA_MAC_VER_27)
+ if (((tp->mac_version == RTL_GIGA_MAC_VER_27) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_28)) &&
+ (ocp_read(tp, 0x0f, 0x0010) & 0x00008000)) {
return;
+ }
if (((tp->mac_version == RTL_GIGA_MAC_VER_23) ||
(tp->mac_version == RTL_GIGA_MAC_VER_24)) &&
@@ -2940,6 +2943,8 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
switch (tp->mac_version) {
case RTL_GIGA_MAC_VER_25:
case RTL_GIGA_MAC_VER_26:
+ case RTL_GIGA_MAC_VER_27:
+ case RTL_GIGA_MAC_VER_28:
RTL_W8(PMCH, RTL_R8(PMCH) & ~0x80);
break;
}
@@ -2949,12 +2954,17 @@ static void r8168_pll_power_up(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
- if (tp->mac_version == RTL_GIGA_MAC_VER_27)
+ if (((tp->mac_version == RTL_GIGA_MAC_VER_27) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_28)) &&
+ (ocp_read(tp, 0x0f, 0x0010) & 0x00008000)) {
return;
+ }
switch (tp->mac_version) {
case RTL_GIGA_MAC_VER_25:
case RTL_GIGA_MAC_VER_26:
+ case RTL_GIGA_MAC_VER_27:
+ case RTL_GIGA_MAC_VER_28:
RTL_W8(PMCH, RTL_R8(PMCH) | 0x80);
break;
}
@@ -3369,7 +3379,8 @@ static void rtl8169_hw_reset(struct rtl8169_private *tp)
/* Disable interrupts */
rtl8169_irq_mask_and_ack(ioaddr);
- if (tp->mac_version == RTL_GIGA_MAC_VER_28) {
+ if (tp->mac_version == RTL_GIGA_MAC_VER_27 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_28) {
while (RTL_R8(TxPoll) & NPQ)
udelay(20);
--
1.7.3.2
^ permalink raw reply related
* [PATCH 3/5] r8169: fix the wrong parameter of point address
From: Hayes Wang @ 2011-02-22 6:41 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1298356917-486-1-git-send-email-hayeswang@realtek.com>
Correct the parameter of rtl8168_oob_notify. It results in the
wrong point address and influences RTL8168DP.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 5d89f89..ff66aa6 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -629,8 +629,9 @@ static void ocp_write(struct rtl8169_private *tp, u8 mask, u16 reg, u32 data)
}
}
-static void rtl8168_oob_notify(void __iomem *ioaddr, u8 cmd)
+static void rtl8168_oob_notify(struct rtl8169_private *tp, u8 cmd)
{
+ void __iomem *ioaddr = tp->mmio_addr;
int i;
RTL_W8(ERIDR, cmd);
@@ -642,7 +643,7 @@ static void rtl8168_oob_notify(void __iomem *ioaddr, u8 cmd)
break;
}
- ocp_write(ioaddr, 0x1, 0x30, 0x00000001);
+ ocp_write(tp, 0x1, 0x30, 0x00000001);
}
#define OOB_CMD_RESET 0x00
--
1.7.3.2
^ permalink raw reply related
* [PATCH 2/5] r8169: Support RTL8105E
From: Hayes Wang @ 2011-02-22 6:41 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1298356917-486-1-git-send-email-hayeswang@realtek.com>
Support the new chips for RTL8105E
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 90 insertions(+), 2 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 3630dd7..5d89f89 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -36,6 +36,7 @@
#define FIRMWARE_8168D_1 "rtl_nic/rtl8168d-1.fw"
#define FIRMWARE_8168D_2 "rtl_nic/rtl8168d-2.fw"
+#define FIRMWARE_8105E_1 "rtl_nic/rtl8105e-1.fw"
#ifdef RTL8169_DEBUG
#define assert(expr) \
@@ -123,6 +124,8 @@ enum mac_version {
RTL_GIGA_MAC_VER_26 = 0x1a, // 8168D
RTL_GIGA_MAC_VER_27 = 0x1b, // 8168DP
RTL_GIGA_MAC_VER_28 = 0x1c, // 8168DP
+ RTL_GIGA_MAC_VER_29 = 0x1d, // 8105E
+ RTL_GIGA_MAC_VER_30 = 0x1e, // 8105E
};
#define _R(NAME,MAC,MASK) \
@@ -160,7 +163,9 @@ static const struct {
_R("RTL8168d/8111d", RTL_GIGA_MAC_VER_25, 0xff7e1880), // PCI-E
_R("RTL8168d/8111d", RTL_GIGA_MAC_VER_26, 0xff7e1880), // PCI-E
_R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_27, 0xff7e1880), // PCI-E
- _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_28, 0xff7e1880) // PCI-E
+ _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_28, 0xff7e1880), // PCI-E
+ _R("RTL8105e", RTL_GIGA_MAC_VER_29, 0xff7e1880), // PCI-E
+ _R("RTL8105e", RTL_GIGA_MAC_VER_30, 0xff7e1880) // PCI-E
};
#undef _R
@@ -267,9 +272,15 @@ enum rtl8168_8101_registers {
#define EPHYAR_REG_MASK 0x1f
#define EPHYAR_REG_SHIFT 16
#define EPHYAR_DATA_MASK 0xffff
+ DLLPR = 0xd0,
+#define PM_SWITCH (1 << 6)
DBG_REG = 0xd1,
#define FIX_NAK_1 (1 << 4)
#define FIX_NAK_2 (1 << 3)
+ TWSI = 0xd2,
+ MCU = 0xd3,
+#define EN_NDP (1 << 3)
+#define EN_OOB_RESET (1 << 2)
EFUSEAR = 0xdc,
#define EFUSEAR_FLAG 0x80000000
#define EFUSEAR_WRITE_CMD 0x80000000
@@ -568,6 +579,7 @@ MODULE_LICENSE("GPL");
MODULE_VERSION(RTL8169_VERSION);
MODULE_FIRMWARE(FIRMWARE_8168D_1);
MODULE_FIRMWARE(FIRMWARE_8168D_2);
+MODULE_FIRMWARE(FIRMWARE_8105E_1);
static int rtl8169_open(struct net_device *dev);
static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
@@ -1143,7 +1155,9 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
(tp->mac_version != RTL_GIGA_MAC_VER_13) &&
(tp->mac_version != RTL_GIGA_MAC_VER_14) &&
(tp->mac_version != RTL_GIGA_MAC_VER_15) &&
- (tp->mac_version != RTL_GIGA_MAC_VER_16)) {
+ (tp->mac_version != RTL_GIGA_MAC_VER_16) &&
+ (tp->mac_version != RTL_GIGA_MAC_VER_29) &&
+ (tp->mac_version != RTL_GIGA_MAC_VER_30)) {
giga_ctrl |= ADVERTISE_1000FULL | ADVERTISE_1000HALF;
} else {
netif_info(tp, link, dev,
@@ -1559,6 +1573,9 @@ static void rtl8169_get_mac_version(struct rtl8169_private *tp,
{ 0x7c800000, 0x30000000, RTL_GIGA_MAC_VER_11 },
/* 8101 family. */
+ { 0x7cf00000, 0x40a00000, RTL_GIGA_MAC_VER_30 },
+ { 0x7cf00000, 0x40900000, RTL_GIGA_MAC_VER_29 },
+ { 0x7c800000, 0x40800000, RTL_GIGA_MAC_VER_30 },
{ 0x7cf00000, 0x34a00000, RTL_GIGA_MAC_VER_09 },
{ 0x7cf00000, 0x24a00000, RTL_GIGA_MAC_VER_09 },
{ 0x7cf00000, 0x34900000, RTL_GIGA_MAC_VER_08 },
@@ -2435,6 +2452,33 @@ static void rtl8102e_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
}
+static void rtl8105e_hw_phy_config(struct rtl8169_private *tp)
+{
+ static const struct phy_reg phy_reg_init[] = {
+ { 0x1f, 0x0005 },
+ { 0x1a, 0x0000 },
+ { 0x1f, 0x0000 },
+
+ { 0x1f, 0x0004 },
+ { 0x1c, 0x0000 },
+ { 0x1f, 0x0000 },
+
+ { 0x1f, 0x0001 },
+ { 0x15, 0x7701 },
+ { 0x1f, 0x0000 }
+ };
+
+ /* Disable ALDPS before ram code */
+ rtl_writephy(tp, 0x1f, 0x0000);
+ rtl_writephy(tp, 0x18, 0x0310);
+ msleep(100);
+
+ if (rtl_apply_firmware(tp, FIRMWARE_8105E_1) < 0)
+ netif_warn(tp, probe, tp->dev, "unable to apply firmware patch\n");
+
+ rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
+}
+
static void rtl_hw_phy_config(struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
@@ -2502,6 +2546,10 @@ static void rtl_hw_phy_config(struct net_device *dev)
case RTL_GIGA_MAC_VER_28:
rtl8168d_4_hw_phy_config(tp);
break;
+ case RTL_GIGA_MAC_VER_29:
+ case RTL_GIGA_MAC_VER_30:
+ rtl8105e_hw_phy_config(tp);
+ break;
default:
break;
@@ -2940,6 +2988,8 @@ static void __devinit rtl_init_pll_power_ops(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_09:
case RTL_GIGA_MAC_VER_10:
case RTL_GIGA_MAC_VER_16:
+ case RTL_GIGA_MAC_VER_29:
+ case RTL_GIGA_MAC_VER_30:
ops->down = r810x_pll_power_down;
ops->up = r810x_pll_power_up;
break;
@@ -3897,6 +3947,37 @@ static void rtl_hw_start_8102e_3(void __iomem *ioaddr, struct pci_dev *pdev)
rtl_ephy_write(ioaddr, 0x03, 0xc2f9);
}
+static void rtl_hw_start_8105e_1(void __iomem *ioaddr, struct pci_dev *pdev)
+{
+ static const struct ephy_info e_info_8105e_1[] = {
+ { 0x07, 0, 0x4000 },
+ { 0x19, 0, 0x0200 },
+ { 0x19, 0, 0x0020 },
+ { 0x1e, 0, 0x2000 },
+ { 0x03, 0, 0x0001 },
+ { 0x19, 0, 0x0100 },
+ { 0x19, 0, 0x0004 },
+ { 0x0a, 0, 0x0020 }
+ };
+
+ /* Force LAN exit from ASPM if Rx/Tx are not idel */
+ RTL_W32(FuncEvent, RTL_R32(FuncEvent) | 0x002800);
+
+ /* disable Early Tally Counter */
+ RTL_W32(FuncEvent, RTL_R32(FuncEvent) & ~0x010000);
+
+ RTL_W8(MCU, RTL_R8(MCU) | EN_NDP | EN_OOB_RESET);
+ RTL_W8(DLLPR, RTL_R8(DLLPR) | PM_SWITCH);
+
+ rtl_ephy_init(ioaddr, e_info_8105e_1, ARRAY_SIZE(e_info_8105e_1));
+}
+
+static void rtl_hw_start_8105e_2(void __iomem *ioaddr, struct pci_dev *pdev)
+{
+ rtl_hw_start_8105e_1(ioaddr, pdev);
+ rtl_ephy_write(ioaddr, 0x1e, rtl_ephy_read(ioaddr, 0x1e) | 0x8000);
+}
+
static void rtl_hw_start_8101(struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
@@ -3927,6 +4008,13 @@ static void rtl_hw_start_8101(struct net_device *dev)
case RTL_GIGA_MAC_VER_09:
rtl_hw_start_8102e_2(ioaddr, pdev);
break;
+
+ case RTL_GIGA_MAC_VER_29:
+ rtl_hw_start_8105e_1(ioaddr, pdev);
+ break;
+ case RTL_GIGA_MAC_VER_30:
+ rtl_hw_start_8105e_2(ioaddr, pdev);
+ break;
}
RTL_W8(Cfg9346, Cfg9346_Lock);
--
1.7.3.2
^ permalink raw reply related
* [PATCH 1/5] r8169: Correct settings of rtl8102e
From: Hayes Wang @ 2011-02-22 6:41 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
Adjust and remove certain settings of RTL8102E which are for previous chips.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 20 ++++++--------------
1 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 469ab0b..3630dd7 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -3042,7 +3042,7 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
goto err_out_mwi_2;
}
- tp->cp_cmd = PCIMulRW | RxChkSum;
+ tp->cp_cmd = RxChkSum;
if ((sizeof(dma_addr_t) > 4) &&
!pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) && use_dac) {
@@ -3847,8 +3847,7 @@ static void rtl_hw_start_8168(struct net_device *dev)
Cxpl_dbg_sel | \
ASF | \
PktCntrDisable | \
- PCIDAC | \
- PCIMulRW)
+ Mac_dbgo_sel)
static void rtl_hw_start_8102e_1(void __iomem *ioaddr, struct pci_dev *pdev)
{
@@ -3878,8 +3877,6 @@ static void rtl_hw_start_8102e_1(void __iomem *ioaddr, struct pci_dev *pdev)
if ((cfg1 & LEDS0) && (cfg1 & LEDS1))
RTL_W8(Config1, cfg1 & ~LEDS0);
- RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) & ~R810X_CPCMD_QUIRK_MASK);
-
rtl_ephy_init(ioaddr, e_info_8102e_1, ARRAY_SIZE(e_info_8102e_1));
}
@@ -3891,8 +3888,6 @@ static void rtl_hw_start_8102e_2(void __iomem *ioaddr, struct pci_dev *pdev)
RTL_W8(Config1, MEMMAP | IOMAP | VPD | PMEnable);
RTL_W8(Config3, RTL_R8(Config3) & ~Beacon_en);
-
- RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) & ~R810X_CPCMD_QUIRK_MASK);
}
static void rtl_hw_start_8102e_3(void __iomem *ioaddr, struct pci_dev *pdev)
@@ -3918,6 +3913,8 @@ static void rtl_hw_start_8101(struct net_device *dev)
}
}
+ RTL_W8(Cfg9346, Cfg9346_Unlock);
+
switch (tp->mac_version) {
case RTL_GIGA_MAC_VER_07:
rtl_hw_start_8102e_1(ioaddr, pdev);
@@ -3932,14 +3929,13 @@ static void rtl_hw_start_8101(struct net_device *dev)
break;
}
- RTL_W8(Cfg9346, Cfg9346_Unlock);
+ RTL_W8(Cfg9346, Cfg9346_Lock);
RTL_W8(MaxTxPacketSize, TxPacketMax);
rtl_set_rx_max_size(ioaddr, rx_buf_sz);
- tp->cp_cmd |= rtl_rw_cpluscmd(ioaddr) | PCIMulRW;
-
+ tp->cp_cmd &= ~R810X_CPCMD_QUIRK_MASK;
RTL_W16(CPlusCmd, tp->cp_cmd);
RTL_W16(IntrMitigate, 0x0000);
@@ -3949,14 +3945,10 @@ static void rtl_hw_start_8101(struct net_device *dev)
RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
rtl_set_rx_tx_config_registers(tp);
- RTL_W8(Cfg9346, Cfg9346_Lock);
-
RTL_R8(IntrMask);
rtl_set_rx_mode(dev);
- RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
-
RTL_W16(MultiIntr, RTL_R16(MultiIntr) & 0xf000);
RTL_W16(IntrMask, tp->intr_event);
--
1.7.3.2
^ permalink raw reply related
* Re: [PATCH ethtool 5/5] ethtool: Add --version option
From: Stephen Hemminger @ 2011-02-22 6:16 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1298315959.2608.73.camel@bwh-desktop>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> --- ethtool.8.in | 5 +++++
> ethtool.c | 6 ++++++
> 2 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/ethtool.8.in b/ethtool.8.in
> index 133825b..8b04335 100644
> --- a/ethtool.8.in
> +++ b/ethtool.8.in
> @@ -100,6 +100,8 @@ ethtool \- query or control network driver and
> hardware settings
>
> .B ethtool \-h|\-\-help
>
> +.B ethtool \-\-version
> + .B ethtool \-a|\-\-show\-pause
> .I ethX
>
> @@ -310,6 +312,9 @@ settings of the specified device.
> .B \-h \-\-help
> Shows a short help message.
> .TP +.B \-\-version
> +Shows the ethtool version number.
> +.TP .B \-a \-\-show\-pause
> Queries the specified Ethernet device for pause parameter information.
> .TP diff --git a/ethtool.c b/ethtool.c
> index 32a97f6..e9cb2c9 100644
> --- a/ethtool.c
> +++ b/ethtool.c
> @@ -115,6 +115,7 @@ static int do_permaddr(int fd, struct ifreq *ifr);
> static int send_ioctl(int fd, struct ifreq *ifr);
>
> static enum {
> + MODE_VERSION = -2,
> MODE_HELP = -1,
> MODE_GSET=0, MODE_SSET,
> @@ -264,6 +265,7 @@ static struct option {
> { "-P", "--show-permaddr", MODE_PERMADDR,
> "Show permanent hardware address" },
> { "-h", "--help", MODE_HELP, "Show this help" },
> + { NULL, "--version", MODE_VERSION, "Show version number" },
The standard convention is to use -V for short form of version option.
^ permalink raw reply
* RE: why all packets have same queue no when rps enabled?
From: Eric Dumazet @ 2011-02-22 6:13 UTC (permalink / raw)
To: Jon Zhou; +Cc: netdev@vger.kernel.org
In-Reply-To: <4A6A2125329CFD4D8CC40C9E8ABCAB9F24D3DE6D51@MILEXCH2.ds.jdsu.net>
Le lundi 21 février 2011 à 21:56 -0800, Jon Zhou a écrit :
>
> > -----Original Message-----
> > From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> > Sent: Tuesday, February 22, 2011 1:41 PM
> > To: Jon Zhou
> > Cc: netdev@vger.kernel.org
> > Subject: Re: why all packets have same queue no when rps enabled?
> >
> > Le lundi 21 février 2011 à 20:07 -0800, Jon Zhou a écrit :
> > > Hi
> > >
> > > I expect each incoming packet will have a different queue no. when I
> > enabled RPS on kernel 2.6.36.4
> > >
> > > cat /sys/class/net/eth4/queues/rx-0/rps_cpus
> > > 00000000,000000ff
> > >
> > > CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
> > CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12
> > CPU13 CPU14 CPU15 CPU16
> > > CPU17 CPU18 CPU19 CPU20 CPU21 CPU22
> > CPU23 CPU24 CPU25 CPU26 CPU27 CPU28 CPU29
> > CPU30 CPU31
> > > HI: 0 0 0 0 0
> > 0 0 0 0 0 0 0
> > 0 0 0 0 0
> > > 0 0 0 0 0 0
> > 0 0 0 0 0 0 0
> > 0 0
> > > TIMER: 6027512 710165 2623243 542768 427807
> > 217424 192940 217043 0 0 0
> > 0 0 0 0 0 0
> > > 0 0 0 0 0 0
> > 0 0 0 0 0 0 0
> > 0 0
> > > NET_TX: 1365741 59 750957 0 171
> > 0 3 0 0 0 0 0
> > 0 0 0 0 0
> > > 0 0 0 0 0 0
> > 0 0 0 0 0 0 0
> > 0 0
> > > NET_RX: 40465750 11140803 8545859 14417762 8913471
> > 12298691 14216845 3348431 < ---- indeed spread across cpus
> > >
> > >
> > > I manually disable RSS on the intel X520 multiqueue supported NIC.
> > > Cat /proc/interrupts
> > >
> > > 87: 21348294 0 0 0 0
> > 0 0 0 PCI-MSI-edge eth4-rx-0
> > > 88: 38394 0 0 0 0
> > 0 0 0 PCI-MSI-edge eth4-tx-0
> > >
> > >
> > >
> > > When I tried the below program to filter packet by queue no.I got
> > these results:
> > >
> > > struct sock_filter BPF_code[]= {
> > > { 0x28,0,0,SKF_AD_OFF+SKF_AD_QUEUE},
> > > { 0x15, 0, 1, 0x00000001 },
> > > { 0x6, 0, 0, 0x0000ffff },
> > > { 0x6, 0, 0, 0x00000000 }
> > > };
> > >
> > > struct sock_fprog Filter;
> > >
> > > Filter.len = 4;//15;
> > > Filter.filter = BPF_code;
> > >
> > > if ( (sock=socket(PF_PACKET, SOCK_RAW, htons(ETH_P_IP)))<0) {
> > > perror("socket");
> > > exit(1);
> > > }
> > >
> > > /* Set the network card in promiscuos mode */
> > > strncpy(ethreq.ifr_name,"eth4",IFNAMSIZ);
> > > if (ioctl(sock,SIOCGIFFLAGS,ðreq)==-1) {
> > > perror("ioctl");
> > > close(sock);
> > > exit(1);
> > > }
> > > ethreq.ifr_flags|=IFF_PROMISC;
> > > if (ioctl(sock,SIOCSIFFLAGS,ðreq)==-1) {
> > > perror("ioctl");
> > > close(sock);
> > > exit(1);
> > > }
> > >
> > > /* Attach the filter to the socket */
> > > if(setsockopt(sock, SOL_SOCKET, SO_ATTACH_FILTER,&Filter,
> > sizeof(Filter))<0){
> > > perror("setsockopt");
> > > close(sock);
> > > exit(1);
> > > }
> > > static int count = 0;
> > > while (1) {
> > > printf("#%d----------\n",count++);
> > > n = recvfrom(sock,buffer,2048,0,NULL,NULL);
> > > printf("%d bytes read\n",n);
> > > ...
> > > }
> > >
> > >
> > > Looks almost all packets fall at same queue?
> > > Will RPS allocate queue no for each packet? and what hash algorithm
> > rps used? (is it Toeplitz hash algorithm?)
> > >
> >
> > I believe you are mistaken.
> >
> > RPS is not there to spread load on _all_ cpus, but to use a hash
> > function so that all packets of a given flow are directed to a given
> > cpu.
> >
> > If you receive 1.000.000 packets of the same flow, they all are
> > delivered to one CPU.
> >
> >
> With RSS supported NIC, I saw packet#0,1,2,3,~packet#7 will be delivered to different queue, but after RSS disabled and RPS turn on, all these packet will be allocated same queue no(I used the above filter program to find that)
> Is there any fault in the filter program?
>
I dont know...
The easy way to find out is to actually do "cat /proc/net/softnet_stat"
Since the last column is the number of time a cpu was given a packet by
another cpu (RPS or RFS action)
^ permalink raw reply
* RE: why all packets have same queue no when rps enabled?
From: Jon Zhou @ 2011-02-22 5:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <1298353270.3360.1.camel@edumazet-laptop>
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Tuesday, February 22, 2011 1:41 PM
> To: Jon Zhou
> Cc: netdev@vger.kernel.org
> Subject: Re: why all packets have same queue no when rps enabled?
>
> Le lundi 21 février 2011 à 20:07 -0800, Jon Zhou a écrit :
> > Hi
> >
> > I expect each incoming packet will have a different queue no. when I
> enabled RPS on kernel 2.6.36.4
> >
> > cat /sys/class/net/eth4/queues/rx-0/rps_cpus
> > 00000000,000000ff
> >
> > CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
> CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12
> CPU13 CPU14 CPU15 CPU16
> > CPU17 CPU18 CPU19 CPU20 CPU21 CPU22
> CPU23 CPU24 CPU25 CPU26 CPU27 CPU28 CPU29
> CPU30 CPU31
> > HI: 0 0 0 0 0
> 0 0 0 0 0 0 0
> 0 0 0 0 0
> > 0 0 0 0 0 0
> 0 0 0 0 0 0 0
> 0 0
> > TIMER: 6027512 710165 2623243 542768 427807
> 217424 192940 217043 0 0 0
> 0 0 0 0 0 0
> > 0 0 0 0 0 0
> 0 0 0 0 0 0 0
> 0 0
> > NET_TX: 1365741 59 750957 0 171
> 0 3 0 0 0 0 0
> 0 0 0 0 0
> > 0 0 0 0 0 0
> 0 0 0 0 0 0 0
> 0 0
> > NET_RX: 40465750 11140803 8545859 14417762 8913471
> 12298691 14216845 3348431 < ---- indeed spread across cpus
> >
> >
> > I manually disable RSS on the intel X520 multiqueue supported NIC.
> > Cat /proc/interrupts
> >
> > 87: 21348294 0 0 0 0
> 0 0 0 PCI-MSI-edge eth4-rx-0
> > 88: 38394 0 0 0 0
> 0 0 0 PCI-MSI-edge eth4-tx-0
> >
> >
> >
> > When I tried the below program to filter packet by queue no.I got
> these results:
> >
> > struct sock_filter BPF_code[]= {
> > { 0x28,0,0,SKF_AD_OFF+SKF_AD_QUEUE},
> > { 0x15, 0, 1, 0x00000001 },
> > { 0x6, 0, 0, 0x0000ffff },
> > { 0x6, 0, 0, 0x00000000 }
> > };
> >
> > struct sock_fprog Filter;
> >
> > Filter.len = 4;//15;
> > Filter.filter = BPF_code;
> >
> > if ( (sock=socket(PF_PACKET, SOCK_RAW, htons(ETH_P_IP)))<0) {
> > perror("socket");
> > exit(1);
> > }
> >
> > /* Set the network card in promiscuos mode */
> > strncpy(ethreq.ifr_name,"eth4",IFNAMSIZ);
> > if (ioctl(sock,SIOCGIFFLAGS,ðreq)==-1) {
> > perror("ioctl");
> > close(sock);
> > exit(1);
> > }
> > ethreq.ifr_flags|=IFF_PROMISC;
> > if (ioctl(sock,SIOCSIFFLAGS,ðreq)==-1) {
> > perror("ioctl");
> > close(sock);
> > exit(1);
> > }
> >
> > /* Attach the filter to the socket */
> > if(setsockopt(sock, SOL_SOCKET, SO_ATTACH_FILTER,&Filter,
> sizeof(Filter))<0){
> > perror("setsockopt");
> > close(sock);
> > exit(1);
> > }
> > static int count = 0;
> > while (1) {
> > printf("#%d----------\n",count++);
> > n = recvfrom(sock,buffer,2048,0,NULL,NULL);
> > printf("%d bytes read\n",n);
> > ...
> > }
> >
> >
> > Looks almost all packets fall at same queue?
> > Will RPS allocate queue no for each packet? and what hash algorithm
> rps used? (is it Toeplitz hash algorithm?)
> >
>
> I believe you are mistaken.
>
> RPS is not there to spread load on _all_ cpus, but to use a hash
> function so that all packets of a given flow are directed to a given
> cpu.
>
> If you receive 1.000.000 packets of the same flow, they all are
> delivered to one CPU.
>
>
With RSS supported NIC, I saw packet#0,1,2,3,~packet#7 will be delivered to different queue, but after RSS disabled and RPS turn on, all these packet will be allocated same queue no(I used the above filter program to find that)
Is there any fault in the filter program?
^ permalink raw reply
* Re: RPS runs with multiqueue NIC
From: Eric Dumazet @ 2011-02-22 5:46 UTC (permalink / raw)
To: Jon Zhou; +Cc: netdev@vger.kernel.org
In-Reply-To: <4A6A2125329CFD4D8CC40C9E8ABCAB9F24D3DE6CC5@MILEXCH2.ds.jdsu.net>
Le lundi 21 février 2011 à 19:07 -0800, Jon Zhou a écrit :
> Hi
>
> What will happen if RPS runs on kernel 2.6.36.4 machine where a multiqueue NIC intel x520 installed
> Will it decrease or improve performance?
It depends on the workload.
For typical TCP flows, hardware multiqueue is generally better,
especially if the NIC supports the ethtool -X command (so that you can
tune effective number of cpus dedicated to the softirq processing).
Packet are delivered directly to the CPU target, without taking an extra
IPI.
For UDP workloads, adding RPS might be a win, because many NIC dont take
into account ports numbers in their hash computation, while
net/core/dev.c hash function does. If you receive trafic coming from a
single remote machine, RPS helps to spread flows between several cpus.
^ permalink raw reply
* Re: why all packets have same queue no when rps enabled?
From: Eric Dumazet @ 2011-02-22 5:41 UTC (permalink / raw)
To: Jon Zhou; +Cc: netdev@vger.kernel.org
In-Reply-To: <4A6A2125329CFD4D8CC40C9E8ABCAB9F24D3DE6D0C@MILEXCH2.ds.jdsu.net>
Le lundi 21 février 2011 à 20:07 -0800, Jon Zhou a écrit :
> Hi
>
> I expect each incoming packet will have a different queue no. when I enabled RPS on kernel 2.6.36.4
>
> cat /sys/class/net/eth4/queues/rx-0/rps_cpus
> 00000000,000000ff
>
> CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12 CPU13 CPU14 CPU15 CPU16
> CPU17 CPU18 CPU19 CPU20 CPU21 CPU22 CPU23 CPU24 CPU25 CPU26 CPU27 CPU28 CPU29 CPU30 CPU31
> HI: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> TIMER: 6027512 710165 2623243 542768 427807 217424 192940 217043 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> NET_TX: 1365741 59 750957 0 171 0 3 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> NET_RX: 40465750 11140803 8545859 14417762 8913471 12298691 14216845 3348431 < ---- indeed spread across cpus
>
>
> I manually disable RSS on the intel X520 multiqueue supported NIC.
> Cat /proc/interrupts
>
> 87: 21348294 0 0 0 0 0 0 0 PCI-MSI-edge eth4-rx-0
> 88: 38394 0 0 0 0 0 0 0 PCI-MSI-edge eth4-tx-0
>
>
>
> When I tried the below program to filter packet by queue no.I got these results:
>
> struct sock_filter BPF_code[]= {
> { 0x28,0,0,SKF_AD_OFF+SKF_AD_QUEUE},
> { 0x15, 0, 1, 0x00000001 },
> { 0x6, 0, 0, 0x0000ffff },
> { 0x6, 0, 0, 0x00000000 }
> };
>
> struct sock_fprog Filter;
>
> Filter.len = 4;//15;
> Filter.filter = BPF_code;
>
> if ( (sock=socket(PF_PACKET, SOCK_RAW, htons(ETH_P_IP)))<0) {
> perror("socket");
> exit(1);
> }
>
> /* Set the network card in promiscuos mode */
> strncpy(ethreq.ifr_name,"eth4",IFNAMSIZ);
> if (ioctl(sock,SIOCGIFFLAGS,ðreq)==-1) {
> perror("ioctl");
> close(sock);
> exit(1);
> }
> ethreq.ifr_flags|=IFF_PROMISC;
> if (ioctl(sock,SIOCSIFFLAGS,ðreq)==-1) {
> perror("ioctl");
> close(sock);
> exit(1);
> }
>
> /* Attach the filter to the socket */
> if(setsockopt(sock, SOL_SOCKET, SO_ATTACH_FILTER,&Filter, sizeof(Filter))<0){
> perror("setsockopt");
> close(sock);
> exit(1);
> }
> static int count = 0;
> while (1) {
> printf("#%d----------\n",count++);
> n = recvfrom(sock,buffer,2048,0,NULL,NULL);
> printf("%d bytes read\n",n);
> ...
> }
>
>
> Looks almost all packets fall at same queue?
> Will RPS allocate queue no for each packet? and what hash algorithm rps used? (is it Toeplitz hash algorithm?)
>
I believe you are mistaken.
RPS is not there to spread load on _all_ cpus, but to use a hash
function so that all packets of a given flow are directed to a given
cpu.
If you receive 1.000.000 packets of the same flow, they all are
delivered to one CPU.
^ permalink raw reply
* why all packets have same queue no when rps enabled?
From: Jon Zhou @ 2011-02-22 4:07 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi
I expect each incoming packet will have a different queue no. when I enabled RPS on kernel 2.6.36.4
cat /sys/class/net/eth4/queues/rx-0/rps_cpus
00000000,000000ff
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12 CPU13 CPU14 CPU15 CPU16
CPU17 CPU18 CPU19 CPU20 CPU21 CPU22 CPU23 CPU24 CPU25 CPU26 CPU27 CPU28 CPU29 CPU30 CPU31
HI: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
TIMER: 6027512 710165 2623243 542768 427807 217424 192940 217043 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
NET_TX: 1365741 59 750957 0 171 0 3 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
NET_RX: 40465750 11140803 8545859 14417762 8913471 12298691 14216845 3348431 < ---- indeed spread across cpus
I manually disable RSS on the intel X520 multiqueue supported NIC.
Cat /proc/interrupts
87: 21348294 0 0 0 0 0 0 0 PCI-MSI-edge eth4-rx-0
88: 38394 0 0 0 0 0 0 0 PCI-MSI-edge eth4-tx-0
When I tried the below program to filter packet by queue no.I got these results:
struct sock_filter BPF_code[]= {
{ 0x28,0,0,SKF_AD_OFF+SKF_AD_QUEUE},
{ 0x15, 0, 1, 0x00000001 },
{ 0x6, 0, 0, 0x0000ffff },
{ 0x6, 0, 0, 0x00000000 }
};
struct sock_fprog Filter;
Filter.len = 4;//15;
Filter.filter = BPF_code;
if ( (sock=socket(PF_PACKET, SOCK_RAW, htons(ETH_P_IP)))<0) {
perror("socket");
exit(1);
}
/* Set the network card in promiscuos mode */
strncpy(ethreq.ifr_name,"eth4",IFNAMSIZ);
if (ioctl(sock,SIOCGIFFLAGS,ðreq)==-1) {
perror("ioctl");
close(sock);
exit(1);
}
ethreq.ifr_flags|=IFF_PROMISC;
if (ioctl(sock,SIOCSIFFLAGS,ðreq)==-1) {
perror("ioctl");
close(sock);
exit(1);
}
/* Attach the filter to the socket */
if(setsockopt(sock, SOL_SOCKET, SO_ATTACH_FILTER,&Filter, sizeof(Filter))<0){
perror("setsockopt");
close(sock);
exit(1);
}
static int count = 0;
while (1) {
printf("#%d----------\n",count++);
n = recvfrom(sock,buffer,2048,0,NULL,NULL);
printf("%d bytes read\n",n);
...
}
Looks almost all packets fall at same queue?
Will RPS allocate queue no for each packet? and what hash algorithm rps used? (is it Toeplitz hash algorithm?)
jon
^ permalink raw reply
* RPS runs with multiqueue NIC
From: Jon Zhou @ 2011-02-22 3:07 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi
What will happen if RPS runs on kernel 2.6.36.4 machine where a multiqueue NIC intel x520 installed
Will it decrease or improve performance?
rui
^ permalink raw reply
* TX VLAN acceleration on bridges broken in 2.6.37?
From: Jan Niehusmann @ 2011-02-21 23:29 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
With the following configuration, sending vlan tagged traffic from a
bridged interface doesn't work in 2.6.37.
The same configuration does work with 2.6.36:
- bridge br0 with physical interface eth0
- eth0 being an e1000e device (don't know if that's important)
- vlan interface br0.10
- (on 2.6.37) tx vlan acceleration active on br0 (default)
Networking on br0.10 doesn't work, and tcpdump on eth0 shows packets
sent on br0.10 as untagged, instead of vlan 10 tagged.
After turning vlan tx offloading off with 'ethtool -K br0 txvlan off',
everything works as expected, again.
The workaround is made permanent by reverting "bridge: Add support for
TX vlan offload.", 361ff8a6cf90d62c0071b7e532e37369bfd3ae77, turning
of the feature on bridges completely.
Jan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox