* Re: [PATCH net-next] bnx2x: Add Nic partitioning mode (57712 devices)
From: Dimitris Michailidis @ 2010-12-06 18:21 UTC (permalink / raw)
To: Matt Domsch
Cc: Eilon Greenstein, Dmitry Kravkov, davem@davemloft.net,
netdev@vger.kernel.org, narendra_k@dell.com,
jordan_hargrave@dell.com
In-Reply-To: <20101206173534.GC13628@auslistsprd01.us.dell.com>
Matt Domsch wrote:
> For SR-IOV, biosdevname follows the physfn and virtfn* pointers to map
> VFs to the PF.
This gives the PF a VF maps to but in general doesn't say anything about the
port the VF maps to, unless you make additional assumptions as below.
> But it assumes 1 PF -> 1 port. For the Intel 1GbE and
> 10GbE cards I have, this is true, but nothing says it has to be true.
Yes, there are devices for which this isn't true. You can have several PFs
mapping to 1 port, 1 PF mapping to several ports, a PF mapping to some
port(s) but its VFs mapping to different port(s), ...
> Maybe something like:
>
> /sys/class/net_port/<port_name>/<ifname> -> /sys/class/net/<ifname>
>
> /sys/class/net/<ifname>/port -> /sys/class/net_port/<port_name>
>
> This introduces the idea of ports, though adds the complication of
> needing to name them somehow. But it would expose the relationship of
> each net interface to a specific port, as well as allow multiple
> interfaces per port, conceptually independent of the PCI device
> mapping. That way, each driver, which must know the mapping somehow,
> could fill these links out?
/sys/class/net/<ifname>/dev_id indicates the physical port <ifname> is
associated with. At least a few drivers set up dev_id this way.
^ permalink raw reply
* [PATCH net-next 0/6] tg3: Bugfix and EEE updates
From: Matt Carlson @ 2010-12-06 18:28 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
This patch integrates a jumbo frame bd flag bugfix and a few EEE refinements.
^ permalink raw reply
* [PATCH net-next 3/6] tg3: Fix 57765 EEE support
From: Matt Carlson @ 2010-12-06 18:28 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
EEE support in the 57765 internal phy will not enable after a phy reset
unless it sees that EEE is supported in the MAC. This patch moves the
code that programs the CPMU EEE registers to a place before the phy
reset.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 32 ++++++++++++++++----------------
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 1e7a135..e4efb52 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -7809,6 +7809,22 @@ static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
if (tp->tg3_flags & TG3_FLAG_INIT_COMPLETE)
tg3_abort_hw(tp, 1);
+ /* Enable MAC control of LPI */
+ if (tp->phy_flags & TG3_PHYFLG_EEE_CAP) {
+ tw32_f(TG3_CPMU_EEE_LNKIDL_CTRL,
+ TG3_CPMU_EEE_LNKIDL_PCIE_NL0 |
+ TG3_CPMU_EEE_LNKIDL_UART_IDL);
+
+ tw32_f(TG3_CPMU_EEE_CTRL,
+ TG3_CPMU_EEE_CTRL_EXIT_20_1_US);
+
+ tw32_f(TG3_CPMU_EEE_MODE,
+ TG3_CPMU_EEEMD_ERLY_L1_XIT_DET |
+ TG3_CPMU_EEEMD_LPI_IN_TX |
+ TG3_CPMU_EEEMD_LPI_IN_RX |
+ TG3_CPMU_EEEMD_EEE_ENABLE);
+ }
+
if (reset_phy)
tg3_phy_reset(tp);
@@ -7890,22 +7906,6 @@ static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
tw32(TG3_CPMU_LSPD_10MB_CLK, val);
}
- /* Enable MAC control of LPI */
- if (tp->phy_flags & TG3_PHYFLG_EEE_CAP) {
- tw32_f(TG3_CPMU_EEE_LNKIDL_CTRL,
- TG3_CPMU_EEE_LNKIDL_PCIE_NL0 |
- TG3_CPMU_EEE_LNKIDL_UART_IDL);
-
- tw32_f(TG3_CPMU_EEE_CTRL,
- TG3_CPMU_EEE_CTRL_EXIT_20_1_US);
-
- tw32_f(TG3_CPMU_EEE_MODE,
- TG3_CPMU_EEEMD_ERLY_L1_XIT_DET |
- TG3_CPMU_EEEMD_LPI_IN_TX |
- TG3_CPMU_EEEMD_LPI_IN_RX |
- TG3_CPMU_EEEMD_EEE_ENABLE);
- }
-
/* This works around an issue with Athlon chipsets on
* B3 tigon3 silicon. This bit has no effect on any
* other revision. But do not set this on PCI Express
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 5/6] tg3: Relax EEE thresholds
From: Matt Carlson @ 2010-12-06 18:28 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
The hardware defaults to fairly aggressive EEE thresholds. While there
appear to be no ill effects, this patch relaxes them, just as a
precaution.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 25 ++++++++++++++++++++-----
drivers/net/tg3.h | 20 +++++++++++++-------
2 files changed, 33 insertions(+), 12 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 81dafc2..bb95c6e 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -7819,11 +7819,26 @@ static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
tw32_f(TG3_CPMU_EEE_CTRL,
TG3_CPMU_EEE_CTRL_EXIT_20_1_US);
- tw32_f(TG3_CPMU_EEE_MODE,
- TG3_CPMU_EEEMD_ERLY_L1_XIT_DET |
- TG3_CPMU_EEEMD_LPI_IN_TX |
- TG3_CPMU_EEEMD_LPI_IN_RX |
- TG3_CPMU_EEEMD_EEE_ENABLE);
+ val = TG3_CPMU_EEEMD_ERLY_L1_XIT_DET |
+ TG3_CPMU_EEEMD_LPI_IN_TX |
+ TG3_CPMU_EEEMD_LPI_IN_RX |
+ TG3_CPMU_EEEMD_EEE_ENABLE;
+
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5717)
+ val |= TG3_CPMU_EEEMD_SND_IDX_DET_EN;
+
+ if (tp->tg3_flags3 & TG3_FLG3_ENABLE_APE)
+ val |= TG3_CPMU_EEEMD_APE_TX_DET_EN;
+
+ tw32_f(TG3_CPMU_EEE_MODE, val);
+
+ tw32_f(TG3_CPMU_EEE_DBTMR1,
+ TG3_CPMU_DBTMR1_PCIEXIT_2047US |
+ TG3_CPMU_DBTMR1_LNKIDLE_2047US);
+
+ tw32_f(TG3_CPMU_EEE_DBTMR2,
+ TG3_CPMU_DBTMR1_APE_TX_2047US |
+ TG3_CPMU_DBTMR2_TXIDXEQ_2047US);
}
if (reset_phy)
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 6e72c6b..d62c8d9 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -1094,13 +1094,19 @@
/* 0x3664 --> 0x36b0 unused */
#define TG3_CPMU_EEE_MODE 0x000036b0
-#define TG3_CPMU_EEEMD_ERLY_L1_XIT_DET 0x00000008
-#define TG3_CPMU_EEEMD_LPI_ENABLE 0x00000080
-#define TG3_CPMU_EEEMD_LPI_IN_TX 0x00000100
-#define TG3_CPMU_EEEMD_LPI_IN_RX 0x00000200
-#define TG3_CPMU_EEEMD_EEE_ENABLE 0x00100000
-/* 0x36b4 --> 0x36b8 unused */
-
+#define TG3_CPMU_EEEMD_APE_TX_DET_EN 0x00000004
+#define TG3_CPMU_EEEMD_ERLY_L1_XIT_DET 0x00000008
+#define TG3_CPMU_EEEMD_SND_IDX_DET_EN 0x00000040
+#define TG3_CPMU_EEEMD_LPI_ENABLE 0x00000080
+#define TG3_CPMU_EEEMD_LPI_IN_TX 0x00000100
+#define TG3_CPMU_EEEMD_LPI_IN_RX 0x00000200
+#define TG3_CPMU_EEEMD_EEE_ENABLE 0x00100000
+#define TG3_CPMU_EEE_DBTMR1 0x000036b4
+#define TG3_CPMU_DBTMR1_PCIEXIT_2047US 0x07ff0000
+#define TG3_CPMU_DBTMR1_LNKIDLE_2047US 0x000070ff
+#define TG3_CPMU_EEE_DBTMR2 0x000036b8
+#define TG3_CPMU_DBTMR1_APE_TX_2047US 0x07ff0000
+#define TG3_CPMU_DBTMR2_TXIDXEQ_2047US 0x000070ff
#define TG3_CPMU_EEE_LNKIDL_CTRL 0x000036bc
#define TG3_CPMU_EEE_LNKIDL_PCIE_NL0 0x01000000
#define TG3_CPMU_EEE_LNKIDL_UART_IDL 0x00000004
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 2/6] tg3: Move EEE definitions into mdio.h
From: Matt Carlson @ 2010-12-06 18:28 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
In commit 52b02d04c801fff51ca49ad033210846d1713253 entitled "tg3: Add
EEE support", Ben Hutchings had commented that the EEE advertisement
register will be in a standard location. This patch moves that
definition into mdio.h and changes the code to use it.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 16 ++++++++--------
drivers/net/tg3.h | 3 ---
include/linux/mdio.h | 5 +++++
3 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index b8ae5e1..1e7a135 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -32,6 +32,7 @@
#include <linux/etherdevice.h>
#include <linux/skbuff.h>
#include <linux/ethtool.h>
+#include <linux/mdio.h>
#include <linux/mii.h>
#include <linux/phy.h>
#include <linux/brcmphy.h>
@@ -1781,7 +1782,8 @@ static void tg3_phy_eee_adjust(struct tg3 *tp, u32 current_link_up)
tw32(TG3_CPMU_EEE_CTRL, eeectl);
- tg3_phy_cl45_read(tp, 0x7, TG3_CL45_D7_EEERES_STAT, &val);
+ tg3_phy_cl45_read(tp, MDIO_MMD_AN,
+ TG3_CL45_D7_EEERES_STAT, &val);
if (val == TG3_CL45_D7_EEERES_STAT_LP_1000T ||
val == TG3_CL45_D7_EEERES_STAT_LP_100TX)
@@ -2987,16 +2989,14 @@ static void tg3_phy_copper_begin(struct tg3 *tp)
if (tp->link_config.autoneg == AUTONEG_ENABLE) {
/* Advertise 100-BaseTX EEE ability */
if (tp->link_config.advertising &
- (ADVERTISED_100baseT_Half |
- ADVERTISED_100baseT_Full))
- val |= TG3_CL45_D7_EEEADV_CAP_100TX;
+ ADVERTISED_100baseT_Full)
+ val |= MDIO_AN_EEE_ADV_100TX;
/* Advertise 1000-BaseT EEE ability */
if (tp->link_config.advertising &
- (ADVERTISED_1000baseT_Half |
- ADVERTISED_1000baseT_Full))
- val |= TG3_CL45_D7_EEEADV_CAP_1000T;
+ ADVERTISED_1000baseT_Full)
+ val |= MDIO_AN_EEE_ADV_1000T;
}
- tg3_phy_cl45_write(tp, 0x7, TG3_CL45_D7_EEEADV_CAP, val);
+ tg3_phy_cl45_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
/* Turn off SM_DSP clock. */
val = MII_TG3_AUXCTL_SHDWSEL_AUXCTL |
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 59b0e09..6e72c6b 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -2172,9 +2172,6 @@
#define MII_TG3_TEST1_CRC_EN 0x8000
/* Clause 45 expansion registers */
-#define TG3_CL45_D7_EEEADV_CAP 0x003c
-#define TG3_CL45_D7_EEEADV_CAP_100TX 0x0002
-#define TG3_CL45_D7_EEEADV_CAP_1000T 0x0004
#define TG3_CL45_D7_EEERES_STAT 0x803e
#define TG3_CL45_D7_EEERES_STAT_LP_100TX 0x0002
#define TG3_CL45_D7_EEERES_STAT_LP_1000T 0x0004
diff --git a/include/linux/mdio.h b/include/linux/mdio.h
index c779b49..b1494ac 100644
--- a/include/linux/mdio.h
+++ b/include/linux/mdio.h
@@ -55,6 +55,7 @@
#define MDIO_PCS_10GBRT_STAT2 33 /* 10GBASE-R/-T PCS status 2 */
#define MDIO_AN_10GBT_CTRL 32 /* 10GBASE-T auto-negotiation control */
#define MDIO_AN_10GBT_STAT 33 /* 10GBASE-T auto-negotiation status */
+#define MDIO_AN_EEE_ADV 60 /* EEE advertisement */
/* LASI (Link Alarm Status Interrupt) registers, defined by XENPAK MSA. */
#define MDIO_PMA_LASI_RXCTRL 0x9000 /* RX_ALARM control */
@@ -235,6 +236,10 @@
#define MDIO_AN_10GBT_STAT_MS 0x4000 /* Master/slave config */
#define MDIO_AN_10GBT_STAT_MSFLT 0x8000 /* Master/slave config fault */
+/* AN EEE Advertisement register. */
+#define MDIO_AN_EEE_ADV_100TX 0x0002 /* Advertise 100TX EEE cap */
+#define MDIO_AN_EEE_ADV_1000T 0x0004 /* Advertise 1000T EEE cap */
+
/* LASI RX_ALARM control/status registers. */
#define MDIO_PMA_LASI_RX_PHYXSLFLT 0x0001 /* PHY XS RX local fault */
#define MDIO_PMA_LASI_RX_PCSLFLT 0x0008 /* PCS RX local fault */
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 6/6] tg3: Update version to 3.116
From: Matt Carlson @ 2010-12-06 18:28 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
This patch updates the tg3 version to 3.116.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index bb95c6e..5faa87d 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -70,10 +70,10 @@
#define DRV_MODULE_NAME "tg3"
#define TG3_MAJ_NUM 3
-#define TG3_MIN_NUM 115
+#define TG3_MIN_NUM 116
#define DRV_MODULE_VERSION \
__stringify(TG3_MAJ_NUM) "." __stringify(TG3_MIN_NUM)
-#define DRV_MODULE_RELDATE "October 14, 2010"
+#define DRV_MODULE_RELDATE "December 3, 2010"
#define TG3_DEF_MAC_MODE 0
#define TG3_DEF_RX_MODE 0
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 4/6] tg3: Minor EEE code tweaks
From: Matt Carlson @ 2010-12-06 18:28 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
The first hunk of this patch makes sure that the driver checks for the
appropriate preconditions before checking if EEE negotiation succeeded.
More specifically the link needs to be full duplex for EEE to be
enabled.
The second and third hunks of this patch fix a bug where the eee
advertisement register would be programmed with extra bits set.
The fourth hunk of this patch makes sure the EEE capability flag is not
set for 5718 A0 devices and that the device is not a serdes device.
None of these modifications are strictly necessary. The driver /
hardware still does the right thing. They are submitted primarily for
correctness.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index e4efb52..81dafc2 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1770,9 +1770,9 @@ static void tg3_phy_eee_adjust(struct tg3 *tp, u32 current_link_up)
if (tp->link_config.autoneg == AUTONEG_ENABLE &&
current_link_up == 1 &&
- (tp->link_config.active_speed == SPEED_1000 ||
- (tp->link_config.active_speed == SPEED_100 &&
- tp->link_config.active_duplex == DUPLEX_FULL))) {
+ tp->link_config.active_duplex == DUPLEX_FULL &&
+ (tp->link_config.active_speed == SPEED_100 ||
+ tp->link_config.active_speed == SPEED_1000)) {
u32 eeectl;
if (tp->link_config.active_speed == SPEED_1000)
@@ -2969,7 +2969,7 @@ static void tg3_phy_copper_begin(struct tg3 *tp)
}
if (tp->phy_flags & TG3_PHYFLG_EEE_CAP) {
- u32 val = 0;
+ u32 val;
tw32(TG3_CPMU_EEE_MODE,
tr32(TG3_CPMU_EEE_MODE) & ~TG3_CPMU_EEEMD_LPI_ENABLE);
@@ -2986,6 +2986,7 @@ static void tg3_phy_copper_begin(struct tg3 *tp)
tg3_phydsp_write(tp, MII_TG3_DSP_CH34TP2,
val | MII_TG3_DSP_CH34TP2_HIBW01);
+ val = 0;
if (tp->link_config.autoneg == AUTONEG_ENABLE) {
/* Advertise 100-BaseTX EEE ability */
if (tp->link_config.advertising &
@@ -12569,9 +12570,11 @@ static int __devinit tg3_phy_probe(struct tg3 *tp)
}
}
- if (tp->pdev->device == TG3PCI_DEVICE_TIGON3_5718 ||
- (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_57765 &&
- tp->pci_chip_rev_id != CHIPREV_ID_57765_A0))
+ if (!(tp->phy_flags & TG3_PHYFLG_ANY_SERDES) &&
+ ((tp->pdev->device == TG3PCI_DEVICE_TIGON3_5718 &&
+ tp->pci_chip_rev_id != CHIPREV_ID_5717_A0) ||
+ (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_57765 &&
+ tp->pci_chip_rev_id != CHIPREV_ID_57765_A0)))
tp->phy_flags |= TG3_PHYFLG_EEE_CAP;
if (!(tp->phy_flags & TG3_PHYFLG_ANY_SERDES) &&
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 1/6] tg3: Raise the jumbo frame BD flag threshold
From: Matt Carlson @ 2010-12-06 18:28 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
The current transmit routines set the jumbo frame BD flag too
aggressively. This can reduce performance for common cases. This patch
raises the jumbo flag threshold to 1518, up from 1500.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index afb79db..b8ae5e1 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -5761,7 +5761,7 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb,
dma_unmap_addr_set(&tnapi->tx_buffers[entry], mapping, mapping);
if ((tp->tg3_flags3 & TG3_FLG3_USE_JUMBO_BDFLAG) &&
- !mss && skb->len > ETH_DATA_LEN)
+ !mss && skb->len > VLAN_ETH_FRAME_LEN)
base_flags |= TXD_FLAG_JMB_PKT;
tg3_set_txd(tnapi, entry, mapping, len, base_flags,
@@ -5995,7 +5995,7 @@ static netdev_tx_t tg3_start_xmit_dma_bug(struct sk_buff *skb,
#endif
if ((tp->tg3_flags3 & TG3_FLG3_USE_JUMBO_BDFLAG) &&
- !mss && skb->len > ETH_DATA_LEN)
+ !mss && skb->len > VLAN_ETH_FRAME_LEN)
base_flags |= TXD_FLAG_JMB_PKT;
len = skb_headlen(skb);
--
1.7.2.2
^ permalink raw reply related
* Re: [PATCH 2/2] bluetooth: Use printf extension %pMbt
From: Joe Perches @ 2010-12-06 18:50 UTC (permalink / raw)
To: Gustavo F. Padovan, Michał Mirosław
Cc: Marcel Holtmann, netdev, David S. Miller, linux-bluetooth,
linux-kernel
In-Reply-To: <20101206181507.GC883@vigoh>
On Mon, 2010-12-06 at 16:15 -0200, Gustavo F. Padovan wrote:
> This patch doesn't apply to the bluetooth-next-2.6 tree.
> Can you please rebase it against the bluetooth-next-2.6 tree?
No worries, it was done against next-20101202.
Do you care about using %pMR vs %pMbt as Michał suggested in
https://lkml.org/lkml/2010/12/4/21 ?
I think %pMbt more specific, Michał %pMR more generic.
Doesn't matter much to me. Do tell, I'll resubmit either way.
^ permalink raw reply
* Re: [PATCH net-next 0/6] tg3: Bugfix and EEE updates
From: David Miller @ 2010-12-06 19:04 UTC (permalink / raw)
To: mcarlson; +Cc: netdev, andy
In-Reply-To: <1291660134-3801-1-git-send-email-mcarlson@broadcom.com>
From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Mon, 6 Dec 2010 10:28:48 -0800
> This patch integrates a jumbo frame bd flag bugfix and a few EEE refinements.
All applied, thanks Matt.
^ permalink raw reply
* [PATCH] Convert netpoll blocking api in bonding driver to be a counter
From: nhorman @ 2010-12-06 19:05 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Jay Vosburgh, Andy Gospodarek, David S. Miller
From: Neil Horman <nhorman@tuxdriver.com>
A while back I made some changes to enable netpoll in the bonding driver. Among
them was a per-cpu flag that indicated we were in a path that held locks which
could cause the netpoll path to block in during tx, and as such the tx path
should queue the frame for later use. This appears to have given rise to a
regression. If one of those paths on which we hold the per-cpu flag yields the
cpu, its possible for us to come back on a different cpu, leading to us clearing
a different flag than we set. This results in odd netpoll drops, and BUG
backtraces appearing in the log, as we check to make sure that we only clear set
bits, and only set clear bits. I had though briefly about changing the
offending paths so that they wouldn't sleep, but looking at my origional work
more closely, it doesn't appear that a per-cpu flag is warranted. We alrady
gate the checking of this flag on IFF_IN_NETPOLL, so we don't hit this in the
normal tx case anyway. And practically speaking, the normal use case for
netpoll is to only have one client anyway, so we're not going to erroneously
queue netpoll frames when its actually safe to do so. As such, lets just
convert that per-cpu flag to an atomic counter. It fixes the rescheduling bugs,
is equivalent from a performance perspective and actually eliminates some code
in the process.
Tested by the reporter and myself, successfully
Reported-by: Liang Zheng <lzheng@redhat.com>
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: David S. Miller <davem@davemloft.net>
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
---
drivers/net/bonding/bond_main.c | 17 +++++------------
drivers/net/bonding/bonding.h | 12 ++++--------
2 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 0273ad0..0bae9a5 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -171,7 +171,7 @@ MODULE_PARM_DESC(resend_igmp, "Number of IGMP membership reports to send on link
/*----------------------------- Global variables ----------------------------*/
#ifdef CONFIG_NET_POLL_CONTROLLER
-cpumask_var_t netpoll_block_tx;
+atomic_t netpoll_block_tx = ATOMIC_INIT(0);
#endif
static const char * const version =
@@ -5293,13 +5293,6 @@ static int __init bonding_init(void)
if (res)
goto out;
-#ifdef CONFIG_NET_POLL_CONTROLLER
- if (!alloc_cpumask_var(&netpoll_block_tx, GFP_KERNEL)) {
- res = -ENOMEM;
- goto out;
- }
-#endif
-
res = register_pernet_subsys(&bond_net_ops);
if (res)
goto out;
@@ -5328,9 +5321,6 @@ err:
rtnl_link_unregister(&bond_link_ops);
err_link:
unregister_pernet_subsys(&bond_net_ops);
-#ifdef CONFIG_NET_POLL_CONTROLLER
- free_cpumask_var(netpoll_block_tx);
-#endif
goto out;
}
@@ -5347,7 +5337,10 @@ static void __exit bonding_exit(void)
unregister_pernet_subsys(&bond_net_ops);
#ifdef CONFIG_NET_POLL_CONTROLLER
- free_cpumask_var(netpoll_block_tx);
+ /*
+ * Make sure we don't have an imbalance on our netpoll blocking
+ */
+ WARN_ON(atomic_read(&netpoll_block_tx));
#endif
}
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index ad3ae46..bd1a9ab 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -119,26 +119,22 @@
#ifdef CONFIG_NET_POLL_CONTROLLER
-extern cpumask_var_t netpoll_block_tx;
+extern atomic_t netpoll_block_tx;
static inline void block_netpoll_tx(void)
{
- preempt_disable();
- BUG_ON(cpumask_test_and_set_cpu(smp_processor_id(),
- netpoll_block_tx));
+ atomic_inc(&netpoll_block_tx);
}
static inline void unblock_netpoll_tx(void)
{
- BUG_ON(!cpumask_test_and_clear_cpu(smp_processor_id(),
- netpoll_block_tx));
- preempt_enable();
+ atomic_dec(&netpoll_block_tx);
}
static inline int is_netpoll_tx_blocked(struct net_device *dev)
{
if (unlikely(dev->priv_flags & IFF_IN_NETPOLL))
- return cpumask_test_cpu(smp_processor_id(), netpoll_block_tx);
+ return atomic_read(&netpoll_block_tx);
return 0;
}
#else
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH net-next 2/6] tg3: Move EEE definitions into mdio.h
From: Ben Hutchings @ 2010-12-06 19:30 UTC (permalink / raw)
To: Matt Carlson; +Cc: davem, netdev, andy
In-Reply-To: <1291660134-3801-3-git-send-email-mcarlson@broadcom.com>
On Mon, 2010-12-06 at 10:28 -0800, Matt Carlson wrote:
> In commit 52b02d04c801fff51ca49ad033210846d1713253 entitled "tg3: Add
> EEE support", Ben Hutchings had commented that the EEE advertisement
> register will be in a standard location. This patch moves that
> definition into mdio.h and changes the code to use it.
>
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> Reviewed-by: Benjamin Li <benli@broadcom.com>
[...]
Thanks, Matt.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 2.6.36] vlan: Avoid hwaccel vlan packets when vid not used
From: Michael Leun @ 2010-12-06 19:34 UTC (permalink / raw)
To: Jesse Gross; +Cc: Eric Dumazet, David Miller, Ben Greear, linux-kernel, netdev
In-Reply-To: <AANLkTikrDTCDxsyOG4m0XcrOY=3pTRwWqnPGsio9cBFj@mail.gmail.com>
On Mon, 6 Dec 2010 10:14:55 -0800
Jesse Gross <jesse@nicira.com> wrote:
> On Sun, Dec 5, 2010 at 2:44 AM, Michael Leun
> <lkml20101129@newton.leun.net> wrote:
> > Hi Jesse,
> >
> > On Sun, 5 Dec 2010 10:55:28 +0100
> > Michael Leun <lkml20101129@newton.leun.net> wrote:
> >
> >> On Sun, 05 Dec 2010 09:03:53 +0100
> >> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >>
> >> > > But on
> >> > >
> >> > > hpdl320g5:/home/ml # lspci | grep Eth
> >> > > 03:04.0 Ethernet controller: Broadcom Corporation NetXtreme
> >> > > BCM5714 Gigabit Ethernet (rev a3) 03:04.1 Ethernet controller:
> >> > > Broadcom Corporation NetXtreme BCM5714 Gigabit Ethernet (rev
> >> > > a3)
> >> > >
> >> > > the good message is that it also does not crash, but with
> >> > > tcpdump I see vlan tags when no vlan devices configured on the
> >> > > respective eth, if so I do not see tags anymore vlan tags on
> >> > > the trunk interface.
> >> > >
> >> >
> >> > For all these very specific needs, you'll have to try 2.6.37 I am
> >> > afraid. Jesse did huge changes to exactly make this working, we
> >> > wont backport this to 2.6.36, but only avoid crashes.
> >>
> >> OK, I'm perfectly fine with that, of course, actually nice to hear
> >> that the issue already is addressed.
> >>
> >> Likely I'll give some rc an shot on this machine (maybe over
> >> christmas), but it is an production machine (acutally testing other
> >> devices is the "product" produced on this machine), so
> >> unfortunately I'm not that free in when and what I can do (but the
> >> possibility to, for example, bridge the trunk interface would make
> >> testing easier, that justifies something...).
> >>
> >> Thank you all very much for your work.
> >
> > Are these changes already in 2.6.37-rc4? Or, if not are they
> > somewhere publically available already?
> >
> > I looked into various changelogs but have some difficulties to
> > identify them...
> >
> > Maybe I have some time next days to give them an try...
>
> Yes, all of the existing vlan changes are in 2.6.37-rc4. There were a
> number of patches but the main one was
> 3701e51382a026cba10c60b03efabe534fba4ca4
Then, I'm afraid, this (seeing vlan tags even if vlan interfaces are
configured) does not work on HP DL320G5 (for exact description and
examples please see my mail a few days ago).
--
MfG,
Michael Leun
^ permalink raw reply
* Re: [PATCH 2.6.36] vlan: Avoid hwaccel vlan packets when vid not used
From: Jesse Gross @ 2010-12-06 20:04 UTC (permalink / raw)
To: Michael Leun; +Cc: Eric Dumazet, David Miller, Ben Greear, linux-kernel, netdev
In-Reply-To: <20101206203437.54b550e0@xenia.leun.net>
On Mon, Dec 6, 2010 at 11:34 AM, Michael Leun
<lkml20101129@newton.leun.net> wrote:
> On Mon, 6 Dec 2010 10:14:55 -0800
> Jesse Gross <jesse@nicira.com> wrote:
>
>> On Sun, Dec 5, 2010 at 2:44 AM, Michael Leun
>> <lkml20101129@newton.leun.net> wrote:
>> > Hi Jesse,
>> >
>> > On Sun, 5 Dec 2010 10:55:28 +0100
>> > Michael Leun <lkml20101129@newton.leun.net> wrote:
>> >
>> >> On Sun, 05 Dec 2010 09:03:53 +0100
>> >> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> >>
>> >> > > But on
>> >> > >
>> >> > > hpdl320g5:/home/ml # lspci | grep Eth
>> >> > > 03:04.0 Ethernet controller: Broadcom Corporation NetXtreme
>> >> > > BCM5714 Gigabit Ethernet (rev a3) 03:04.1 Ethernet controller:
>> >> > > Broadcom Corporation NetXtreme BCM5714 Gigabit Ethernet (rev
>> >> > > a3)
>> >> > >
>> >> > > the good message is that it also does not crash, but with
>> >> > > tcpdump I see vlan tags when no vlan devices configured on the
>> >> > > respective eth, if so I do not see tags anymore vlan tags on
>> >> > > the trunk interface.
>> >> > >
>> >> >
>> >> > For all these very specific needs, you'll have to try 2.6.37 I am
>> >> > afraid. Jesse did huge changes to exactly make this working, we
>> >> > wont backport this to 2.6.36, but only avoid crashes.
>> >>
>> >> OK, I'm perfectly fine with that, of course, actually nice to hear
>> >> that the issue already is addressed.
>> >>
>> >> Likely I'll give some rc an shot on this machine (maybe over
>> >> christmas), but it is an production machine (acutally testing other
>> >> devices is the "product" produced on this machine), so
>> >> unfortunately I'm not that free in when and what I can do (but the
>> >> possibility to, for example, bridge the trunk interface would make
>> >> testing easier, that justifies something...).
>> >>
>> >> Thank you all very much for your work.
>> >
>> > Are these changes already in 2.6.37-rc4? Or, if not are they
>> > somewhere publically available already?
>> >
>> > I looked into various changelogs but have some difficulties to
>> > identify them...
>> >
>> > Maybe I have some time next days to give them an try...
>>
>> Yes, all of the existing vlan changes are in 2.6.37-rc4. There were a
>> number of patches but the main one was
>> 3701e51382a026cba10c60b03efabe534fba4ca4
>
> Then, I'm afraid, this (seeing vlan tags even if vlan interfaces are
> configured) does not work on HP DL320G5 (for exact description and
> examples please see my mail a few days ago).
What driver are you using? Is it tg3?
The vlan changes that I made unfortunately require updating drivers to
get the full benefit. I've been busy lately so tg3 hasn't yet been
updated.
I know that tg3 does some things differently depending on whether a
vlan group is configured, so that would likely be the cause of what
you are seeing. I'd have to look at it in more detail to be sure
though.
You said that everything works on the other Broadcom NIC that you
tested? Maybe it uses bnx2 instead?
^ permalink raw reply
* Re: [PATCH 2/2] bluetooth: Use printf extension %pMbt
From: Gustavo F. Padovan @ 2010-12-06 20:07 UTC (permalink / raw)
To: Joe Perches
Cc: Michał Mirosław, Marcel Holtmann, netdev,
David S. Miller, linux-bluetooth, linux-kernel
In-Reply-To: <1291661413.17494.219.camel@Joe-Laptop>
Hi Joe,
* Joe Perches <joe@perches.com> [2010-12-06 10:50:13 -0800]:
> On Mon, 2010-12-06 at 16:15 -0200, Gustavo F. Padovan wrote:
> > This patch doesn't apply to the bluetooth-next-2.6 tree.
> > Can you please rebase it against the bluetooth-next-2.6 tree?
>
> No worries, it was done against next-20101202.
>
> Do you care about using %pMR vs %pMbt as Michał suggested in
> https://lkml.org/lkml/2010/12/4/21 ?
I'm fine either way. It depends more if another subsystem will want to use
%pMR or not as you said.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Misuse of LRO, how widespread
From: Stephen Hemminger @ 2010-12-06 20:18 UTC (permalink / raw)
To: David Miller, Olof Johansson, Ben Hutchings, Divy Le Ray; +Cc: netdev
I inspected all drivers in net-next to see which drivers are using
LRO and which ones are broken. Most concerning is that Chelsio
and Solarflare drivers ignore ETH_FLAG_LRO.
The ones that are using LRO but allow disabling it:
qlcnic, netxen, mv643, s2io, myi10ge, bnx2x, ixgbe, vmxnet3
One driver seems confused about LRO vs GRO:
mlx4 - comments about LRO and depends on LRO but driver is using GRO
Drivers with not using ethtool interface to disable LRO:
pasemi_mac, sfc, ehea, cxgb3, cxgb4
^ permalink raw reply
* Re: Misuse of LRO, how widespread
From: Ben Hutchings @ 2010-12-06 20:30 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Olof Johansson, Divy Le Ray, netdev
In-Reply-To: <20101206121829.5b8c852e@nehalam>
On Mon, 2010-12-06 at 12:18 -0800, Stephen Hemminger wrote:
> I inspected all drivers in net-next to see which drivers are using
> LRO and which ones are broken. Most concerning is that Chelsio
> and Solarflare drivers ignore ETH_FLAG_LRO.
>
> The ones that are using LRO but allow disabling it:
> qlcnic, netxen, mv643, s2io, myi10ge, bnx2x, ixgbe, vmxnet3
>
> One driver seems confused about LRO vs GRO:
> mlx4 - comments about LRO and depends on LRO but driver is using GRO
sfc is also in this category. (And it's not confused, it was using
inet_lro before being converted to GRO.)
> Drivers with not using ethtool interface to disable LRO:
> pasemi_mac, sfc, ehea, cxgb3, cxgb4
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: dummy: add auto_up module parameter
From: David Miller @ 2010-12-06 20:36 UTC (permalink / raw)
To: opurdila; +Cc: netdev, ddvlad, lucian.grijincu
In-Reply-To: <1291132647-15018-1-git-send-email-opurdila@ixiacom.com>
From: Octavian Purdila <opurdila@ixiacom.com>
Date: Tue, 30 Nov 2010 17:57:27 +0200
> Add auto_up module parameter to automatically bring up the created
> devices. This is useful when using the dummy driver for testing net
> device register / unregister performance.
>
> Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
Registering a new netdevice with IFF_UP set is an error. You can't
set IFF_UP without also doing all of the other work, callbacks, and
state changes which are made by dev_open()'s code paths.
If, as you say, your interests are in testing register/unregister
performance, you can do that by making the appropriate calls in a loop
from userspace.
I honestly don't see what you hope to gain with this change, and
anyways since the registration state is basically illegal you'll need
to find another way to do this.
^ permalink raw reply
* Re: [PATCHv3 1/2] usbnet: changes for upcoming cdc_ncm driver
From: David Miller @ 2010-12-06 20:59 UTC (permalink / raw)
To: alexey.orishko
Cc: gregkh, linux-usb, netdev, oliver, yauheni.kaliuta, balbi,
sjur.brandeland, alexey.orishko
In-Reply-To: <1291109008-3613-1-git-send-email-alexey.orishko@stericsson.com>
From: Alexey Orishko <alexey.orishko@gmail.com>
Date: Tue, 30 Nov 2010 12:23:27 +0300
> Changes:
> include/linux/usb/usbnet.h:
> - a new flag to indicate driver's capability to accumulate IP packets in Tx
> direction and extract several packets from single skb in Rx direction.
> drivers/net/usb/usbnet.c:
> - the procedure of counting packets in usbnet was updated due to the
> accumulating of IP packets in the driver
> - no short packets are sent if indicated by the flag in driver_info
> structure
>
> Signed-off-by: Alexey Orishko <alexey.orishko@stericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/3] be2net: Fix be_dev_family_check() return value check
From: David Miller @ 2010-12-06 20:59 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <20101201110228.GA1560@emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Wed, 1 Dec 2010 16:32:28 +0530
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Applied.
^ permalink raw reply
* Re: [PATCHv3 2/2] USB CDC NCM host driver
From: David Miller @ 2010-12-06 20:59 UTC (permalink / raw)
To: alexey.orishko-Re5JQEeQqe8AvxtiuMwx3w
Cc: gregkh-l3A5Bk7waGM, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, oliver-GvhC2dPhHPQdnm+yROfE0A,
yauheni.kaliuta-xNZwKgViW5gAvxtiuMwx3w, balbi-l0cyMroinI0,
sjur.brandeland-0IS4wlFg1OjSUeElwK9/Pw,
alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw
In-Reply-To: <1291109008-3613-2-git-send-email-alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
From: Alexey Orishko <alexey.orishko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Tue, 30 Nov 2010 12:23:28 +0300
> The patch provides USB CDC NCM host driver support in the Linux Kernel.
>
> Changes:
> drivers/net/usb/cdc_ncm.c:
> - initial submission of the CDC NCM host driver;
> - verified on Intel 32/64 bit, Intel Atom, ST-Ericsson U8500 (ARM)
> - throughput measured over 100 Mbits duplex;
> - driver supports 16-bit NTB format only, but it is more than enough for
> transfers up to 64K;
> - driver can handle up to 32 datagrams in received NTB;
> - timer is used to collect several packets in Tx direction
>
> drivers/net/usb/Kconfig:
> - a new entry to compile CDC NCM host driver
> drivers/net/usb/Makefile:
> - a new entry to compile CDC NCM host driver
>
> Signed-off-by: Alexey Orishko <alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/3] be2net: FW init cmd fix for lancer
From: David Miller @ 2010-12-06 20:59 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <20101201110336.GA1623@emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Wed, 1 Dec 2010 16:33:36 +0530
> Lancer can use the same pattern as BE to indicate a driver load
> to the FW.
>
> Signed-off-by: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 3/3] be2net: Handle out of buffer completions for lancer
From: David Miller @ 2010-12-06 21:00 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <20101201110417.GA1653@emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Wed, 1 Dec 2010 16:34:17 +0530
> If Lancer chip does not have posted RX buffers, it posts an RX completion entry
> with the same frag_index as the last valid completion. The Error bit is also
> set. In BE, a flush completion is indicated with a zero value for num_rcvd in
> the completion.
> Such completions don't carry any data and are not processed.
> This patch refactors code to handle both cases with the same code.
>
> Signed-off-by: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] : __in_dev_get_rtnl() can use rtnl_dereference()
From: David Miller @ 2010-12-06 21:00 UTC (permalink / raw)
To: eric.dumazet
Cc: amwang, linux-kernel, kuznet, pekkas, jmorris, yoshfuji, kaber,
netdev
In-Reply-To: <1291203462.2856.607.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 01 Dec 2010 12:37:42 +0100
> Le mercredi 01 décembre 2010 à 12:21 +0100, Eric Dumazet a écrit :
>
>> Same here. RTNL is held. Please use __in_dev_get_rtnl()
>
> By the way we can use rtnl_dereference() in __in_dev_get_rtnl()
>
> [PATCH net-next-2.6] : __in_dev_get_rtnl() can use rtnl_dereference()
>
> If caller holds RTNL, we dont need a memory barrier
> (smp_read_barrier_depends) included in rcu_dereference().
>
> Just use rtnl_dereference() to properly document the assertions.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 1/2] af_packet: use vmalloc_to_page() instead for the addresss returned by vmalloc()
From: David Miller @ 2010-12-06 21:01 UTC (permalink / raw)
To: xiaosuo; +Cc: eric.dumazet, jpirko, nhorman, netdev
In-Reply-To: <1291207940-17140-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Wed, 1 Dec 2010 20:52:20 +0800
> The following commit causes the pgv->buffer may point to the memory
> returned by vmalloc(). And we can't use virt_to_page() for the vmalloc
> address.
>
> This patch introduces a new inline function pgv_to_page(), which calls
> vmalloc_to_page() for the vmalloc address, and virt_to_page() for the
> __get_free_pages address.
>
> We used to increase page pointer to get the next page at the next page
> address, after Neil's patch, it is wrong, as the physical address may
> be not continuous. This patch also fixes this issue.
>
> commit 0e3125c755445664f00ad036e4fc2cd32fd52877
> Author: Neil Horman <nhorman@tuxdriver.com>
> Date: Tue Nov 16 10:26:47 2010 -0800
>
> packet: Enhance AF_PACKET implementation to not require high order contiguous memory allocation (v4)
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied.
^ 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