* [net-next 0/9][pull request] Intel Wired LAN Driver Updates 2014-10-02
From: Jeff Kirsher @ 2014-10-02 10:16 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
This series contains updates to fm10k, igb, ixgbe and i40e.
Alex provides two updates to the fm10k driver. First reduces the buffer
size to 2k for all page sizes, since most frames only have a 1500 MTU
so supporting a buffer size larger than this is somewhat wasteful.
Second fixes an issue where the number of transmit queues was not being
updated, so added the lines necessary to update the number of transmit
queues.
Rick Jones provides two patches to convert ixgbe, igb and i40e to use
dev_consume_skb_any().
Emil provides two patches for ixgbe, first cleans up a couple of wait
loops on auto-negotiation that were not needed. Second fixes an issue
reported by Fujitsu/Red Hat, which consolidates the logic behind the
dynamically setting of TXDCTL.WTHRESH depending on interrupt throttle
rate (ITR) setting regardless of BQL.
Ethan Zhao provides a cleanup patch for ixgbe where he noticed a
duplicate define.
Bernhard Kaindl provides a patch for igb to remove a source of latency
spikes by not calling code that uses mdelay() for feeding a PHY stat
while being called with a spinlock held.
Todd bumps the igb version based on the recent changes.
The following are changes since commit d068b02cfdfc27f5962ec82ec5568b706f599edc:
net: phy: add BCM7425 and BCM7429 PHYs
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Alexander Duyck (2):
fm10k: Reduce buffer size when pages are larger than 4K
fm10k: Correctly set the number of Tx queues
Bernhard Kaindl (1):
igb: remove blocking phy read from inside spinlock
Emil Tantilov (2):
ixgbe: remove wait loop on autoneg for copper devices
ixgbe: fix setting of TXDCTL.WTRHESH when ITR is set to 0 and no BQL
Ethan Zhao (1):
ixgbe: delete one duplicate marcro definition of IXGBE_MAX_L2A_QUEUES
Rick Jones (2):
ixgbe: Convert the normal transmit complete path to
dev_consume_skb_any()
i40e/igb: Convert to dev_consume_skb_any()
Todd Fujinaka (1):
igb: bump version to 5.2.15
drivers/net/ethernet/intel/fm10k/fm10k.h | 8 ++---
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 6 +++-
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 +-
drivers/net/ethernet/intel/igb/e1000_hw.h | 5 ---
drivers/net/ethernet/intel/igb/igb.h | 1 -
drivers/net/ethernet/intel/igb/igb_main.c | 16 ++-------
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 -
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 3 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 +---
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 41 ------------------------
10 files changed, 12 insertions(+), 77 deletions(-)
--
1.9.3
^ permalink raw reply
* [net-next 1/9] fm10k: Reduce buffer size when pages are larger than 4K
From: Jeff Kirsher @ 2014-10-02 10:16 UTC (permalink / raw)
To: davem; +Cc: Alexander Duyck, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <1412244994-23636-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
This change reduces the buffer size to 2K for all page sizes. The basic
idea is that since most frames only have a 1500 MTU supporting a buffer
size larger than this is somewhat wasteful. As such I have reduced the
size to 2K for all page sizes which will allow for more uses per page.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/fm10k/fm10k.h | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k.h b/drivers/net/ethernet/intel/fm10k/fm10k.h
index 0565827..42eb434 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k.h
+++ b/drivers/net/ethernet/intel/fm10k/fm10k.h
@@ -47,13 +47,9 @@
#define FM10K_DEFAULT_TX_WORK 256
#define FM10K_RXBUFFER_256 256
-#define FM10K_RXBUFFER_16384 16384
#define FM10K_RX_HDR_LEN FM10K_RXBUFFER_256
-#if PAGE_SIZE <= FM10K_RXBUFFER_16384
-#define FM10K_RX_BUFSZ (PAGE_SIZE / 2)
-#else
-#define FM10K_RX_BUFSZ FM10K_RXBUFFER_16384
-#endif
+#define FM10K_RXBUFFER_2048 2048
+#define FM10K_RX_BUFSZ FM10K_RXBUFFER_2048
/* How many Rx Buffers do we bundle into one write to the hardware ? */
#define FM10K_RX_BUFFER_WRITE 16 /* Must be power of 2 */
--
1.9.3
^ permalink raw reply related
* [net-next 2/9] fm10k: Correctly set the number of Tx queues
From: Jeff Kirsher @ 2014-10-02 10:16 UTC (permalink / raw)
To: davem; +Cc: Alexander Duyck, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <1412244994-23636-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
The number of Tx queues was not being updated due to some issues when
generating the patches. This change makes sure to add the lines necessary
to update the number of Tx queues correctly.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
index dcec000..bf44a8f 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
@@ -546,6 +546,10 @@ int fm10k_open(struct net_device *netdev)
fm10k_request_glort_range(interface);
/* Notify the stack of the actual queue counts */
+ err = netif_set_real_num_tx_queues(netdev,
+ interface->num_tx_queues);
+ if (err)
+ goto err_set_queues;
err = netif_set_real_num_rx_queues(netdev,
interface->num_rx_queues);
@@ -601,7 +605,7 @@ int fm10k_close(struct net_device *netdev)
static netdev_tx_t fm10k_xmit_frame(struct sk_buff *skb, struct net_device *dev)
{
struct fm10k_intfc *interface = netdev_priv(dev);
- unsigned int r_idx = 0;
+ unsigned int r_idx = skb->queue_mapping;
int err;
if ((skb->protocol == htons(ETH_P_8021Q)) &&
--
1.9.3
^ permalink raw reply related
* [net-next 3/9] ixgbe: Convert the normal transmit complete path to dev_consume_skb_any()
From: Jeff Kirsher @ 2014-10-02 10:16 UTC (permalink / raw)
To: davem; +Cc: Rick Jones, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1412244994-23636-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Rick Jones <rick.jones2@hp.com>
Convert the normal packet completion path to dev_consume_skb_any() so
packet drop profiling via dropwatch or perf top -G -e skb_kfree_skb
is not cluttered with false hits.
Compile tested only. There is a dev_kfree_skb_any() in the routine
ixgbe_ptp_tx_hwtstamp() in ixgbe_ptp.c that looks like a conversion
candidate but I wasn't familiar enough with the code to pull the
trigger.
Signed-off-by: Rick Jones <rick.jones2@hp.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 06ef5a3..2daf257 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1094,7 +1094,7 @@ static bool ixgbe_clean_tx_irq(struct ixgbe_q_vector *q_vector,
total_packets += tx_buffer->gso_segs;
/* free the skb */
- dev_kfree_skb_any(tx_buffer->skb);
+ dev_consume_skb_any(tx_buffer->skb);
/* unmap skb header data */
dma_unmap_single(tx_ring->dev,
--
1.9.3
^ permalink raw reply related
* [net-next 4/9] ixgbe: remove wait loop on autoneg for copper devices
From: Jeff Kirsher @ 2014-10-02 10:16 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1412244994-23636-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
This patch removes couple of wait loops on autoneg that are not needed.
During validation we noticed that the loops always time out, so there
should be no user impact.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 41 ----------------------------
1 file changed, 41 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
index 11f02ea..d47b19f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
@@ -445,8 +445,6 @@ s32 ixgbe_write_phy_reg_generic(struct ixgbe_hw *hw, u32 reg_addr,
s32 ixgbe_setup_phy_link_generic(struct ixgbe_hw *hw)
{
s32 status = 0;
- u32 time_out;
- u32 max_time_out = 10;
u16 autoneg_reg = IXGBE_MII_AUTONEG_REG;
bool autoneg = false;
ixgbe_link_speed speed;
@@ -514,25 +512,6 @@ s32 ixgbe_setup_phy_link_generic(struct ixgbe_hw *hw)
hw->phy.ops.write_reg(hw, MDIO_CTRL1,
MDIO_MMD_AN, autoneg_reg);
- /* Wait for autonegotiation to finish */
- for (time_out = 0; time_out < max_time_out; time_out++) {
- udelay(10);
- /* Restart PHY autonegotiation and wait for completion */
- status = hw->phy.ops.read_reg(hw, MDIO_STAT1,
- MDIO_MMD_AN,
- &autoneg_reg);
-
- autoneg_reg &= MDIO_AN_STAT1_COMPLETE;
- if (autoneg_reg == MDIO_AN_STAT1_COMPLETE) {
- break;
- }
- }
-
- if (time_out == max_time_out) {
- hw_dbg(hw, "ixgbe_setup_phy_link_generic: time out\n");
- return IXGBE_ERR_LINK_SETUP;
- }
-
return status;
}
@@ -657,8 +636,6 @@ s32 ixgbe_check_phy_link_tnx(struct ixgbe_hw *hw, ixgbe_link_speed *speed,
s32 ixgbe_setup_phy_link_tnx(struct ixgbe_hw *hw)
{
s32 status;
- u32 time_out;
- u32 max_time_out = 10;
u16 autoneg_reg = IXGBE_MII_AUTONEG_REG;
bool autoneg = false;
ixgbe_link_speed speed;
@@ -724,24 +701,6 @@ s32 ixgbe_setup_phy_link_tnx(struct ixgbe_hw *hw)
hw->phy.ops.write_reg(hw, MDIO_CTRL1,
MDIO_MMD_AN, autoneg_reg);
- /* Wait for autonegotiation to finish */
- for (time_out = 0; time_out < max_time_out; time_out++) {
- udelay(10);
- /* Restart PHY autonegotiation and wait for completion */
- status = hw->phy.ops.read_reg(hw, MDIO_STAT1,
- MDIO_MMD_AN,
- &autoneg_reg);
-
- autoneg_reg &= MDIO_AN_STAT1_COMPLETE;
- if (autoneg_reg == MDIO_AN_STAT1_COMPLETE)
- break;
- }
-
- if (time_out == max_time_out) {
- hw_dbg(hw, "ixgbe_setup_phy_link_tnx: time out\n");
- return IXGBE_ERR_LINK_SETUP;
- }
-
return status;
}
--
1.9.3
^ permalink raw reply related
* [net-next 6/9] ixgbe: delete one duplicate marcro definition of IXGBE_MAX_L2A_QUEUES
From: Jeff Kirsher @ 2014-10-02 10:16 UTC (permalink / raw)
To: davem; +Cc: Ethan Zhao, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1412244994-23636-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Ethan Zhao <ethan.zhao@oracle.com>
There is typo in ixgbe.h, two marcro definition of IXGBE_MAX_L2A_QUEUES to 4,
delete one, clear the compiler warning.
Signed-off-by: Ethan Zhao <ethan.zhao@oracle.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 673d820..5032a60 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -307,7 +307,6 @@ enum ixgbe_ring_f_enum {
#define MAX_RX_QUEUES (IXGBE_MAX_FDIR_INDICES + 1)
#define MAX_TX_QUEUES (IXGBE_MAX_FDIR_INDICES + 1)
#define IXGBE_MAX_L2A_QUEUES 4
-#define IXGBE_MAX_L2A_QUEUES 4
#define IXGBE_BAD_L2A_QUEUE 3
#define IXGBE_MAX_MACVLANS 31
#define IXGBE_MAX_DCBMACVLANS 8
--
1.9.3
^ permalink raw reply related
* [net-next 5/9] ixgbe: fix setting of TXDCTL.WTRHESH when ITR is set to 0 and no BQL
From: Jeff Kirsher @ 2014-10-02 10:16 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1412244994-23636-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
This patch consolidates the logic behind dynamically setting TXDCTL.WTHRESH
depending on interrupt throttle rate (ITR) setting regardless of BQL.
Previously TXDCTL.WTHRESH was dynamically being set only with BQL being
enabled, but we have to set it regardless of BQL when ITR is low to avoid
Tx stalls/hangs.
CC: John Greene <jogreene@redhat.com>
Reported by: Masayuki Gouji <gouji.masayuki@jp.fujitsu.com>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 3 +--
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ----
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index cff383b..3ce4a25 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -2267,7 +2267,6 @@ static int ixgbe_set_coalesce(struct net_device *netdev,
if (adapter->q_vector[0]->tx.count && adapter->q_vector[0]->rx.count)
adapter->tx_itr_setting = adapter->rx_itr_setting;
-#if IS_ENABLED(CONFIG_BQL)
/* detect ITR changes that require update of TXDCTL.WTHRESH */
if ((adapter->tx_itr_setting != 1) &&
(adapter->tx_itr_setting < IXGBE_100K_ITR)) {
@@ -2279,7 +2278,7 @@ static int ixgbe_set_coalesce(struct net_device *netdev,
(tx_itr_prev < IXGBE_100K_ITR))
need_reset = true;
}
-#endif
+
/* check the old value and enable RSC if necessary */
need_reset |= ixgbe_update_rsc(adapter);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 2daf257..d677b5a 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -2982,11 +2982,7 @@ void ixgbe_configure_tx_ring(struct ixgbe_adapter *adapter,
* to or less than the number of on chip descriptors, which is
* currently 40.
*/
-#if IS_ENABLED(CONFIG_BQL)
if (!ring->q_vector || (ring->q_vector->itr < IXGBE_100K_ITR))
-#else
- if (!ring->q_vector || (ring->q_vector->itr < 8))
-#endif
txdctl |= (1 << 16); /* WTHRESH = 1 */
else
txdctl |= (8 << 16); /* WTHRESH = 8 */
--
1.9.3
^ permalink raw reply related
* [net-next 7/9] igb: remove blocking phy read from inside spinlock
From: Jeff Kirsher @ 2014-10-02 10:16 UTC (permalink / raw)
To: davem
Cc: Bernhard Kaindl, netdev, nhorman, sassmann, jogreene,
Carolyn Wyborny, Todd Fujinaka, Jeff Kirsher
In-Reply-To: <1412244994-23636-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Bernhard Kaindl <bk-linux@use.startmail.com>
Remove a source of latency spikes (in my case up to 10ms) by not calling
code that uses mdelay() for feeding a phy statistic (rx errors for idle
symbols - not data -> idle_errors) while being called with a spinlock held.
As idle_errors isn't read, this patch only removes unused code and data.
Later, more complicated changes may be applied to address the spinlock and
allow for some PHY diagnostics by harvesting this PHY stats register fully.
This patch is designed to fix the issue and be safe for longterm/stable.
For the Intel e1000e driver, the same change was applied in 2008 with
commit 23033fad5be0 ("e1000e: remove phy read from inside spinlock").
The mdelay is triggered by HW/SW semaphores, thus it depends on the HW.
I've HW that triggers it even when idle. Others may trigger it only e.g.
when Ethernet ports aquire or loose the link or on ifconfig up / down.
We've noticed this first from delays in frame rx/tx due to the mdelay().
Example command for checking if the issue is triggered: cyclictest -Smp1
(Look for occasional "Max:" values > 4000 or use -b 4000 to stop if greater)
It was observed with I350 ports connected to other I350 ports, but not
if driver and EEPROM was modified to run the I350 in EEPROM-less mode.
phy_stats.idle_errors and .receive_errors (isn't touched) occupy 64 not
used bits in the adapter struct: Their allocation may be removed as well.
Cc: Carolyn Wyborny <carolyn.wyborny@intel.com>
Cc: Todd Fujinaka <todd.fujinaka@intel.com>
Fixes: 12dcd86b75d5 ("igb: fix stats handling") (this added the spin_lock)
Signed-off-by: Bernhard Kaindl <bk-linux@use.startmail.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/e1000_hw.h | 5 -----
drivers/net/ethernet/intel/igb/igb.h | 1 -
drivers/net/ethernet/intel/igb/igb_main.c | 12 ------------
3 files changed, 18 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/e1000_hw.h b/drivers/net/ethernet/intel/igb/e1000_hw.h
index ce55ea5..2003b37 100644
--- a/drivers/net/ethernet/intel/igb/e1000_hw.h
+++ b/drivers/net/ethernet/intel/igb/e1000_hw.h
@@ -265,11 +265,6 @@ struct e1000_hw_stats {
u64 b2ogprc;
};
-struct e1000_phy_stats {
- u32 idle_errors;
- u32 receive_errors;
-};
-
struct e1000_host_mng_dhcp_cookie {
u32 signature;
u8 status;
diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
index 06102d1..82d891e 100644
--- a/drivers/net/ethernet/intel/igb/igb.h
+++ b/drivers/net/ethernet/intel/igb/igb.h
@@ -403,7 +403,6 @@ struct igb_adapter {
struct e1000_hw hw;
struct e1000_hw_stats stats;
struct e1000_phy_info phy_info;
- struct e1000_phy_stats phy_stats;
u32 test_icr;
struct igb_ring test_tx_ring;
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 6cf0c17..2a4e6f1 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -5206,14 +5206,11 @@ void igb_update_stats(struct igb_adapter *adapter,
struct e1000_hw *hw = &adapter->hw;
struct pci_dev *pdev = adapter->pdev;
u32 reg, mpc;
- u16 phy_tmp;
int i;
u64 bytes, packets;
unsigned int start;
u64 _bytes, _packets;
-#define PHY_IDLE_ERROR_COUNT_MASK 0x00FF
-
/* Prevent stats update while adapter is being reset, or if the pci
* connection is down.
*/
@@ -5374,15 +5371,6 @@ void igb_update_stats(struct igb_adapter *adapter,
/* Tx Dropped needs to be maintained elsewhere */
- /* Phy Stats */
- if (hw->phy.media_type == e1000_media_type_copper) {
- if ((adapter->link_speed == SPEED_1000) &&
- (!igb_read_phy_reg(hw, PHY_1000T_STATUS, &phy_tmp))) {
- phy_tmp &= PHY_IDLE_ERROR_COUNT_MASK;
- adapter->phy_stats.idle_errors += phy_tmp;
- }
- }
-
/* Management Stats */
adapter->stats.mgptc += rd32(E1000_MGTPTC);
adapter->stats.mgprc += rd32(E1000_MGTPRC);
--
1.9.3
^ permalink raw reply related
* [net-next 8/9] i40e/igb: Convert to dev_consume_skb_any()
From: Jeff Kirsher @ 2014-10-02 10:16 UTC (permalink / raw)
To: davem; +Cc: Rick Jones, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1412244994-23636-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Rick Jones <rick.jones2@hp.com>
Convert two more Intel NIC drivers to dev_consume_skb_any() to help
make dropped packet profiling sane.
Signed-off-by: Rick Jones <rick.jones2@hp.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Jim Young <jamesx.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 +-
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index be039dd..267992b 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -702,7 +702,7 @@ static bool i40e_clean_tx_irq(struct i40e_ring *tx_ring, int budget)
total_packets += tx_buf->gso_segs;
/* free the skb */
- dev_kfree_skb_any(tx_buf->skb);
+ dev_consume_skb_any(tx_buf->skb);
/* unmap skb header data */
dma_unmap_single(tx_ring->dev,
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 2a4e6f1..3566fea 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -6374,7 +6374,7 @@ static bool igb_clean_tx_irq(struct igb_q_vector *q_vector)
total_packets += tx_buffer->gso_segs;
/* free the skb */
- dev_kfree_skb_any(tx_buffer->skb);
+ dev_consume_skb_any(tx_buffer->skb);
/* unmap skb header data */
dma_unmap_single(tx_ring->dev,
--
1.9.3
^ permalink raw reply related
* [net-next 9/9] igb: bump version to 5.2.15
From: Jeff Kirsher @ 2014-10-02 10:16 UTC (permalink / raw)
To: davem; +Cc: Todd Fujinaka, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1412244994-23636-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Todd Fujinaka <todd.fujinaka@intel.com>
Bump version
Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 3566fea..ae59c0b 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -58,7 +58,7 @@
#define MAJ 5
#define MIN 2
-#define BUILD 13
+#define BUILD 15
#define DRV_VERSION __stringify(MAJ) "." __stringify(MIN) "." \
__stringify(BUILD) "-k"
char igb_driver_name[] = "igb";
--
1.9.3
^ permalink raw reply related
* [patch 1/2 -next] cxgb4: potential shift wrapping bug
From: Dan Carpenter @ 2014-10-02 10:20 UTC (permalink / raw)
To: Hariprasad S; +Cc: netdev, kernel-janitors
"cntxt_id" is an unsigned int but "udb" is a u64 so there is a potential
shift wrapping bug here.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index bb7851e..e8e90ce 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -2258,7 +2258,7 @@ static u64 udb_address(struct adapter *adap, unsigned int cntxt_id,
(QUEUESPERPAGEPF1 - QUEUESPERPAGEPF0) * adap->fn);
udb_density = 1 << ((qpp >> s_qpp) & QUEUESPERPAGEPF0_MASK);
qpshift = PAGE_SHIFT - ilog2(udb_density);
- udb = cntxt_id << qpshift;
+ udb = (u64)cntxt_id << qpshift;
udb &= PAGE_MASK;
page = udb / PAGE_SIZE;
udb += (cntxt_id - (page * udb_density)) * SGE_UDB_SIZE;
^ permalink raw reply related
* Re: [PATCH v2 net-next] net: pktgen: packet bursting via skb->xmit_more
From: Jesper Dangaard Brouer @ 2014-10-02 10:44 UTC (permalink / raw)
To: David Miller; +Cc: ast, edumazet, netdev, brouer
In-Reply-To: <20141001.220839.1118640596408366269.davem@davemloft.net>
On Wed, 01 Oct 2014 22:08:39 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:
> From: Alexei Starovoitov <ast@plumgrid.com>
> Date: Tue, 30 Sep 2014 17:53:21 -0700
>
> > This patch demonstrates the effect of delaying update of HW tailptr.
> > (based on earlier patch by Jesper)
> >
> > burst=1 is the default. It sends one packet with xmit_more=false
> > burst=2 sends one packet with xmit_more=true and
> > 2nd copy of the same packet with xmit_more=false
> > burst=3 sends two copies of the same packet with xmit_more=true and
> > 3rd copy with xmit_more=false
> >
> > Performance with ixgbe (usec 30):
> > burst=1 tx:9.2 Mpps
> > burst=2 tx:13.5 Mpps
> > burst=3 tx:14.5 Mpps full 10G line rate
> >
> > Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
>
> Applied, great work.
Updated my pktgen script "pktgen02_burst.sh" for supporting this new
"burst" option:
https://github.com/netoptimizer/network-testing/commit/cb625712f8efb
https://github.com/netoptimizer/network-testing/blob/master/pktgen/pktgen02_burst.sh
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCHv9 net-next 2/4] sunvnet: make transmit path zero-copy in the kernel
From: David L Stevens @ 2014-10-02 11:11 UTC (permalink / raw)
To: Raghuram Kothakota; +Cc: David Miller, netdev, Sowmini Varadhan
In-Reply-To: <77E6695E-58F8-4D10-8ED7-EEC4A487339E@oracle.com>
On 10/02/2014 01:50 AM, Raghuram Kothakota wrote:
>> + err = ldc_map_single(port->vio.lp, start, nlen,
>> + port->tx_bufs[txi].cookies, 2,
>> + (LDC_MAP_SHADOW | LDC_MAP_DIRECT | LDC_MAP_RW));
>
>
> The LDC sharing protection mechanism is at a page level. If I understand
> well, the vnet_skb_shape() function only addresses the alignment requirement
> but it still leaves the possibility of exporting a lot more data than required to the
> peer. This can be treated as a security issue, wondering if you thought of this issue.
Since the specific offsets and lengths are provided in the API, I didn't realize that it was
sharing more than the provided buffer until you pointed that out, before I submitted the
patches. At that point, I considered it.
The original buffers were ~1500 byte kzalloc'ed (for each buffer), meaning that they were
potentially shared with arbitrary kernel memory on the same page.
This patch-set doesn't increase or decrease any security concerns related to oversharing
with other LDOMs. The extents outside the provided buffers are (now) skbs, and so packet
data, where before they could be any dynamically allocated kernel memory.
+-DLS
^ permalink raw reply
* [patch 1/2 -next] cxgb4: clean up a type issue
From: Dan Carpenter @ 2014-10-02 11:22 UTC (permalink / raw)
To: Hariprasad S; +Cc: netdev, kernel-janitors
The tx_desc struct hold 8 __be64 values. The original code took a
tx_desc pointer then casted it to an int pointer and then casted it to a
u64 pointer. It was confusing and triggered some static checker
warnings.
I have changed the cxgb_pio_copy() to only take tx_desc pointers. This
isn't really a loss of flexibility because anything else was buggy to
begin with.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index bb7851e..599cdfd 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -854,9 +854,10 @@ static void write_sgl(const struct sk_buff *skb, struct sge_txq *q,
* memory mapped BAR2 space(user space writes).
* For coalesced WR SGE, fetches data from the FIFO instead of from Host.
*/
-static void cxgb_pio_copy(u64 __iomem *dst, u64 *src)
+static void cxgb_pio_copy(u64 __iomem *dst, struct tx_desc *desc)
{
- int count = 8;
+ int count = sizeof(*desc) / sizeof(u64);
+ u64 *src = (u64 *)desc;
while (count) {
writeq(*src, dst);
@@ -914,12 +915,11 @@ static inline void ring_tx_db(struct adapter *adap, struct sge_txq *q, int n)
int index = (q->pidx
? (q->pidx - 1)
: (q->size - 1));
- unsigned int *wr = (unsigned int *)&q->desc[index];
+ struct tx_desc *desc = &q->desc[index];
cxgb_pio_copy((u64 __iomem *)
(adap->bar2 + q->udb +
- SGE_UDB_WCDOORBELL),
- (u64 *)wr);
+ SGE_UDB_WCDOORBELL), desc);
} else {
writel(val, adap->bar2 + q->udb + SGE_UDB_KDOORBELL);
}
^ permalink raw reply related
* Re: [PATCH] wil6210: remove obsolete msm platform code
From: Vladimir Kondratiev @ 2014-10-02 11:29 UTC (permalink / raw)
To: Arnd Bergmann
Cc: John W. Linville, wil6210, netdev, linux-wireless,
linux-arm-kernel
In-Reply-To: <3995357.SmO1fZQuHn@wuerfel>
On Tuesday, September 30, 2014 05:48:20 PM Arnd Bergmann wrote:
> The wil6210 driver has a glue layer for the Qualcomm MSM platform
> code, which apparently could never build and is unlikely to
> ever be able to in the future, as the MSM platform is being phased
> out in favor of the new QCOM platform, and the driver relies
> on out-of-tree infrastructure. Trying to build it currently
> results in this error:
>
> drivers/net/wireless/ath/wil6210/wil_platform_msm.c:19:27: fatal error: linux/msm-bus.h: No such file or directory
>
> Removing the driver fixes the build and makes it possible to
> build an allmodconfig kernel for MSM.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
We are investigating this, looking for the appropriate solution.
Thanks for pointing to this.
Thanks, Vladimir
^ permalink raw reply
* Re: [PATCHv9 net-next 2/4] sunvnet: make transmit path zero-copy in the kernel
From: David L Stevens @ 2014-10-02 11:33 UTC (permalink / raw)
To: David Laight, 'Raghuram Kothakota'
Cc: David Miller, netdev@vger.kernel.org, Sowmini Varadhan
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D174A2CD2@AcuExch.aculab.com>
On 10/02/2014 05:06 AM, David Laight wrote:
>>> len = skb->len;
>>> - if (len < ETH_ZLEN) {
>>> + if (len < ETH_ZLEN)
>>> len = ETH_ZLEN;
>>> - memset(tx_buf+VNET_PACKET_SKIP+skb->len, 0, len - skb->len);
>>> +
>
> Aren't you transmitting 'random' bytes from the end of the data?
> Plausibly they might not even be mapped.
No. The checks to decide whether to copy or not make sure the
extra 6-14 bytes in the beginning and 0-8 bytes (for large frames, more
for small) at the end are part of the particular skb's headroom and
tailroom respectively. So, they aren't random bytes-- they are what
was allocated as part of the frame. For TCP streams, the trailing bytes
are likely part of the next packet. They definitely exist and are mapped,
but I don't zero them because they are usually COW and that forces a copy
every time.
>
> Also, for short frames the copy could well be faster - especially on systems
> with non-trivial iommu.
> It is also worth checking whether the original copy was aligned.
For the short frames, sure. I'm not sure what you mean by that last sentence--
the point of the checks that determine whether to copy or not are to enforce
alignment and length restrictions; if they aren't met in the original buffer,
we copy.
+-DLS
^ permalink raw reply
* RE: [patch 1/2 -next] cxgb4: clean up a type issue
From: David Laight @ 2014-10-02 11:31 UTC (permalink / raw)
To: 'Dan Carpenter', Hariprasad S
Cc: netdev@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <20141002112219.GA25606@mwanda>
From: Dan Carpenter
> The tx_desc struct hold 8 __be64 values. The original code took a
> tx_desc pointer then casted it to an int pointer and then casted it to a
> u64 pointer. It was confusing and triggered some static checker
> warnings.
>
> I have changed the cxgb_pio_copy() to only take tx_desc pointers. This
> isn't really a loss of flexibility because anything else was buggy to
> begin with.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c
> index bb7851e..599cdfd 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
> @@ -854,9 +854,10 @@ static void write_sgl(const struct sk_buff *skb, struct sge_txq *q,
> * memory mapped BAR2 space(user space writes).
> * For coalesced WR SGE, fetches data from the FIFO instead of from Host.
> */
> -static void cxgb_pio_copy(u64 __iomem *dst, u64 *src)
> +static void cxgb_pio_copy(u64 __iomem *dst, struct tx_desc *desc)
> {
> - int count = 8;
> + int count = sizeof(*desc) / sizeof(u64);
> + u64 *src = (u64 *)desc;
>
> while (count) {
> writeq(*src, dst);
> @@ -914,12 +915,11 @@ static inline void ring_tx_db(struct adapter *adap, struct sge_txq *q, int n)
> int index = (q->pidx
> ? (q->pidx - 1)
> : (q->size - 1));
> - unsigned int *wr = (unsigned int *)&q->desc[index];
> + struct tx_desc *desc = &q->desc[index];
>
> cxgb_pio_copy((u64 __iomem *)
> (adap->bar2 + q->udb +
> - SGE_UDB_WCDOORBELL),
> - (u64 *)wr);
> + SGE_UDB_WCDOORBELL), desc);
Why not put &q->desc[index] in the call itself.
And I can't help think there are better places to break the long line.
Getting it to the code below would be nice:
cxgp_pio_copy(adap->bar2 + q->udb + SGE_UDB_WCDOORBELL,
q->desc + index);
David
> } else {
> writel(val, adap->bar2 + q->udb + SGE_UDB_KDOORBELL);
> }
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] net: Cleanup skb cloning by adding SKB_FCLONE_FREE
From: Eric Dumazet @ 2014-10-02 11:35 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: netdev, davem, edumazet
In-Reply-To: <1412231620-3767-1-git-send-email-subramanian.vijay@gmail.com>
On Wed, 2014-10-01 at 23:33 -0700, Vijay Subramanian wrote:
> SKB_FCLONE_UNAVAILABLE has overloaded meaning depending on type of skb.
> 1: If skb is allocated from head_cache, it indicates fclone is not available.
> 2: If skb is a companion fclone skb (allocated from fclone_cache), it indicates
> it is available to be used.
>
> To avoid confusion for case 2 above, this patch replaces
> SKB_FCLONE_UNAVAILABLE with SKB_FCLONE_FREE where appropriate. For fclone
> companion skbs, this indicates it is free for use.
>
> SKB_FCLONE_UNAVAILABLE will now simply indicate skb is from head_cache and
> cannot / will not have a companion fclone.
>
> Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
> ---
> include/linux/skbuff.h | 3 ++-
> net/core/skbuff.c | 8 ++++----
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 7c5036d..6c3fb9a 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -339,9 +339,10 @@ struct skb_shared_info {
>
>
> enum {
> - SKB_FCLONE_UNAVAILABLE,
> + SKB_FCLONE_UNAVAILABLE, /* skb has no fclone */
> SKB_FCLONE_ORIG,
> SKB_FCLONE_CLONE,
> + SKB_FCLONE_FREE, /* this fclone skb is available */
> };
>
Please comment all the states, now there is no ambiguity ?
^ permalink raw reply
* Re: [PATCH v2 net-next] mlx4: optimize xmit path
From: Eric Dumazet @ 2014-10-02 11:45 UTC (permalink / raw)
To: Amir Vadai
Cc: Or Gerlitz, Alexei Starovoitov, David S. Miller,
Jesper Dangaard Brouer, Eric Dumazet, John Fastabend,
Linux Netdev List, Or Gerlitz, amira, idos, Yevgeny Petrilin,
eyalpe
In-Reply-To: <542D06C1.6090802@mellanox.com>
On Thu, 2014-10-02 at 11:03 +0300, Amir Vadai wrote:
> Hi,
>
> Will take it into the split patchset - we just hit this bug when tried
> to run benchmarks with blueflame disabled (easy to test by using ethtool
> priv flag blueflame).
Hmm, I do not know this ethtool command, please share ;)
>
> I'm still working on it, but I can't reproduce the numbers that you
> show. On my development machine, I get ~5.5Mpps with burst=8 and ~2Mpps
> with burst=1.
You have to be careful with the 'clone X' : If you choose a too big
value, TX completion competes with the sender thread.
>
> In addition, I see no improvements when adding the optimization to the
> xmit path.
> I use the net-next kernel + pktgen burst support patch, with and without
> this xmit path optimization patch.
>
> Do you use other patches not upstream in your environment?
Nope, this is with David net-next tree.
> Can you share the .config/pktgen configuration?
Sure.
>
> One other note: we're checking now that blueflame could be used with
> xmit_more. It might result with packets reordering/drops. Still under
> investigation.
I noticed no reorders. I tweaked the stack to force a gso segmentation
(in software) instead of using NIC TSO for small packets (2 or 3 MSS)
200 concurrent netperf -t TCP_RR -- -r 2000,2000 performance was
increased by ~100%.
#!/bin/bash
#
# on the destination, drop packets with
# iptables -A PREROUTING -t raw -p udp --dport 9 -j DROP
# Or run a recent enough kernel with global ICMP rate limiting to 1000 packets/sec
# ( http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=4cdf507d54525842dfd9f6313fdafba039084046 )
#
#### Configure
# Yeah, if you use PKTSIZE <= 104, performance is lower because of inline (copy whole frame content into tx desc)
PKTSIZE=105
echo "pktrate: $PKTRATE"
COUNT=20000000000
RUN_SECS=60
SRC_DEV=eth0
SRC_IP_MIN=7.0.0.1
SRC_IP_MAX=7.255.255.255
SRC_MAC=00:1a:11:c3:0d:7f
DST_IP=10.246.7.152
DST_MAC=00:1a:11:c3:0d:45
DST_UDP=9
## END OF CONFIGURATION OPTIONS
#### Helper
## Configuration procfs inodes
DEV_INODE=/proc/net/pktgen/$SRC_DEV
MAIN_INODE=/proc/net/pktgen/pgctrl
THREAD_INODE=/proc/net/pktgen/kpktgend_2
# write to a procfs file
function pgset_ex()
{
local result
echo $2
echo $2 > $1
result=`cat $1 | fgrep "Result: OK:"`
if [ "$result" = "" ]; then
cat $1 | fgrep Result:
fi
}
#### Pre: configure
# attach device exclusively
pgset_ex $THREAD_INODE "rem_device_all"
pgset_ex $THREAD_INODE "add_device $SRC_DEV"
# configure basics
pgset_ex $DEV_INODE "clone_skb 8"
pgset_ex $DEV_INODE "src_min $SRC_IP_MIN"
pgset_ex $DEV_INODE "src_max $SRC_IP_MAX"
pgset_ex $DEV_INODE "dst $DST_IP"
pgset_ex $DEV_INODE "dst_mac $DST_MAC"
pgset_ex $DEV_INODE "udp_dst_min $DST_UDP"
pgset_ex $DEV_INODE "udp_dst_max $DST_UDP"
pgset_ex $DEV_INODE "queue_map_min 0"
pgset_ex $DEV_INODE "queue_map_max 0"
pgset_ex $DEV_INODE "burst 8"
pgset_ex $DEV_INODE "pkt_size $PKTSIZE"
pgset_ex $DEV_INODE "delay 0"
# reset to continuous transmission
pgset_ex $DEV_INODE "count $COUNT"
#### Run: transmit
echo -e "UDP packet generator (based on linux pktgen)\n"
echo -e " src: mac=$SRC_MAC ip=$SRC_IP dev=$SRC_DEV"
echo -e " dest: mac=$DST_MAC ip=$DST_IP port=$DST_UDP\n"
modprobe pktgen
#ethtool -C eth0 tx-usecs 16 tx-frames 16
#ethtool -C eth1 tx-usecs 16 tx-frames 16
# start thread(s)
# the write will block until Ctrl^C is pressed or a timeout kills the write
echo "Running for $RUN_SECS seconds"
#pgset_ex $MAIN_INODE "start"
echo "start" > $MAIN_INODE 2>/dev/null &
sleep $RUN_SECS
echo $DEV_INODE
cat $DEV_INODE
# stop
kill $!
pgset_ex $MAIN_INODE "stop"
echo "OK. All done"
^ permalink raw reply
* Re: [PATCH v2 net-next] mlx4: optimize xmit path
From: Amir Vadai @ 2014-10-02 11:56 UTC (permalink / raw)
To: Eric Dumazet
Cc: Or Gerlitz, Alexei Starovoitov, David S. Miller,
Jesper Dangaard Brouer, Eric Dumazet, John Fastabend,
Linux Netdev List, Or Gerlitz, amira, idos, Yevgeny Petrilin,
eyalpe
In-Reply-To: <1412250327.16704.84.camel@edumazet-glaptop2.roam.corp.google.com>
On 10/2/2014 2:45 PM, Eric Dumazet wrote:
> On Thu, 2014-10-02 at 11:03 +0300, Amir Vadai wrote:
>
>> Hi,
>>
>> Will take it into the split patchset - we just hit this bug when tried
>> to run benchmarks with blueflame disabled (easy to test by using ethtool
>> priv flag blueflame).
>
> Hmm, I do not know this ethtool command, please share ;)
$ ethtool --set-priv-flags eth0 blueflame off
>
>>
>> I'm still working on it, but I can't reproduce the numbers that you
>> show. On my development machine, I get ~5.5Mpps with burst=8 and ~2Mpps
>> with burst=1.
>
> You have to be careful with the 'clone X' : If you choose a too big
> value, TX completion competes with the sender thread.
>
>>
>> In addition, I see no improvements when adding the optimization to the
>> xmit path.
After making sure the sender thread and the TX completions are not on
the same CPU, I see the expected improvement. +0.5Mpps with tx
optimizations.
>> I use the net-next kernel + pktgen burst support patch, with and without
>> this xmit path optimization patch.
>>
>> Do you use other patches not upstream in your environment?
>
> Nope, this is with David net-next tree.
>
>> Can you share the .config/pktgen configuration?
>
> Sure.
>
>>
>> One other note: we're checking now that blueflame could be used with
>> xmit_more. It might result with packets reordering/drops. Still under
>> investigation.
>
> I noticed no reorders. I tweaked the stack to force a gso segmentation
> (in software) instead of using NIC TSO for small packets (2 or 3 MSS)
>
> 200 concurrent netperf -t TCP_RR -- -r 2000,2000 performance was
> increased by ~100%.
>
>
> #!/bin/bash
> #
> # on the destination, drop packets with
> # iptables -A PREROUTING -t raw -p udp --dport 9 -j DROP
> # Or run a recent enough kernel with global ICMP rate limiting to 1000 packets/sec
> # ( http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=4cdf507d54525842dfd9f6313fdafba039084046 )
> #
> #### Configure
>
> # Yeah, if you use PKTSIZE <= 104, performance is lower because of inline (copy whole frame content into tx desc)
> PKTSIZE=105
You can also set the module parameter to turn it off:
$ modprobe mlx4_en inline_thold=17
>
[...]
Thanks,
Amir
^ permalink raw reply
* Re: [PATCH v2 net-next] mlx4: optimize xmit path
From: Eric Dumazet @ 2014-10-02 12:07 UTC (permalink / raw)
To: Amir Vadai
Cc: Or Gerlitz, Alexei Starovoitov, David S. Miller,
Jesper Dangaard Brouer, Eric Dumazet, John Fastabend,
Linux Netdev List, Or Gerlitz, amira, idos, Yevgeny Petrilin,
eyalpe
In-Reply-To: <542D3D5F.5090900@mellanox.com>
On Thu, 2014-10-02 at 14:56 +0300, Amir Vadai wrote:
> After making sure the sender thread and the TX completions are not on
> the same CPU, I see the expected improvement. +0.5Mpps with tx
> optimizations.
I got 40% here.
Hmm... both cpus are on the same socket, right ?
TX coalescing is properly setup ?
What interrupt rate do you get ?
You can take a look at where cycles are spent
perf record -a -g sleep 5
perf report
^ permalink raw reply
* Re: [PATCH] wil6210: remove obsolete msm platform code
From: Arnd Bergmann @ 2014-10-02 12:11 UTC (permalink / raw)
To: Vladimir Kondratiev
Cc: John W. Linville, wil6210, netdev, linux-wireless,
linux-arm-kernel
In-Reply-To: <1572828.LhiMXjHRdV@lx-wigig-72>
On Thursday 02 October 2014 14:29:06 Vladimir Kondratiev wrote:
> On Tuesday, September 30, 2014 05:48:20 PM Arnd Bergmann wrote:
> > The wil6210 driver has a glue layer for the Qualcomm MSM platform
> > code, which apparently could never build and is unlikely to
> > ever be able to in the future, as the MSM platform is being phased
> > out in favor of the new QCOM platform, and the driver relies
> > on out-of-tree infrastructure. Trying to build it currently
> > results in this error:
> >
> > drivers/net/wireless/ath/wil6210/wil_platform_msm.c:19:27: fatal error: linux/msm-bus.h: No such file or directory
> >
> > Removing the driver fixes the build and makes it possible to
> > build an allmodconfig kernel for MSM.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >
>
> We are investigating this, looking for the appropriate solution.
> Thanks for pointing to this.
FWIW, I took a closer look at the actual driver code now. It's
actually worse than I thought and I don't see any possible way
out other than removing this driver completely and starting a
new one, if you want to use it for mach-qcom. I hadn't realized
before that this is actually new code rather than ancient bitrot
that suddenly started causing problems.
Some of the worst problems are:
- the driver scans for DT properties that are completely
undocumented and have not been reviewed
- if they had been reviewed, the first comment you would have
received is that the binding makes no sense: you scan for
another node rather than taking the node you already have for
the PCI device, then pass data into a random soc-specific
driver API that is not part of the upstream kernel.
- as mentioned in the my patch above, the code has never been
compiled on a mainline kernel and now breaks builds.
I think the only way forward is to have the platform support for
whatever chip this is meant for reviewed and merged first and
then you can write a new glue driver for the interfaces we end
up putting into the kernel.
My guess is that with proper interfaces between the platform
bus driver and the wil driver glue, there would be very little
left in terms of interface and you can just call a generic
interface from the PCI driver, passing the 'struct device'
for the PCI dev in to an exported interface when provided.
Arnd
^ permalink raw reply
* Re: netlink NETLINK_ROUTE failure & Can the kernel really handle IPv6 properly
From: Ulf samuelsson @ 2014-10-02 12:38 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Linux Netdev List
In-Reply-To: <1412199032.2532289.174101717.2D6510D0@webmail.messagingengine.com>
This is the significant code, and it is wrong.
static struct notifier_block my_ipv6_address_notifier =
{
my_ipv6_address_notifier_cb,
NULL,
0
};
register_inet6addr_notifier (&my_ipv6_address_notifier );
int
my_ipv6_address_notifier_cb (struct notifier_block *self,
unsigned long event, void *val)
{
struct inet6_ifaddr *ifaddr = (struct inet6_ifaddr *)val;
/* We are only interested in address add/delete events */
/* IPv6 address add comes as NETDEV_UP and delete comes as
* NETDEV_DOWN
*/
if ((event != NETDEV_UP) && (event != NETDEV_DOWN))
return ret;
if (ifaddr == NULL)
return ret;
/* Now that we are sure that it is a IPv6 address being added deleted,
* verify that it is a link local address.
*/
if (!IPV6_IS_ADDR_LINKLOCAL (&ifaddr->addr))
{
return ret;
}
...
send_message_to_app(LINK_LOCAL_UP, ip);
...
return ret;
}
Application tries to send message to "ip" and fails, because the link-local adress is still
in "tentative state"
Best Regards
Ulf Samuelsson
ulf@emagii.com
+46 (722) 427 437
> 1 okt 2014 kl. 23:30 skrev Hannes Frederic Sowa <hannes@stressinduktion.org>:
>
> Hello,
>
>> On Wed, Oct 1, 2014, at 22:28, Ulf Samuelsson wrote:
>> BTW, the problem I am trying to solve is how to connect to an I/F with
>> an IPv6 link-local address.
>>
>> An existing kernel module waits for a NETDEV_UP event, and then tries to
>> communicate
>> with the link-local address.
>>
>> This will fail, because (according to a colleague) the I/F enters a
>> "tentative" state,
>> where it is trying to decide if it is unique or not.
>> It will remain in that state for 1-2 seconds, and only afterwards is the
>> link-local address
>> available for normal use.
>>
>> The guys writing the module, claim that the kernel is using NETDEV_UP.
>> There is very little code in the kernel using NETLINK_ROUTE, even in
>> latest stable.
>> It is using NETDEV_UP.
>>
>> If my colleague is right, the kernel really cannot handle IPv6
>> link-local addresses properly.
>
> Sorry, I cannot really follow you, can you send example code or be a bit
> more precise?
>
> Thanks,
> Hannes
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 net-next] mlx4: optimize xmit path
From: Amir Vadai @ 2014-10-02 12:45 UTC (permalink / raw)
To: Eric Dumazet
Cc: Or Gerlitz, Alexei Starovoitov, David S. Miller,
Jesper Dangaard Brouer, Eric Dumazet, John Fastabend,
Linux Netdev List, Or Gerlitz, amira, idos, Yevgeny Petrilin,
eyalpe
In-Reply-To: <1412251620.16704.88.camel@edumazet-glaptop2.roam.corp.google.com>
On 10/2/2014 3:07 PM, Eric Dumazet wrote:
> On Thu, 2014-10-02 at 14:56 +0300, Amir Vadai wrote:
>> After making sure the sender thread and the TX completions are not on
>> the same CPU, I see the expected improvement. +0.5Mpps with tx
>> optimizations.
>
> I got 40% here.
>
> Hmm... both cpus are on the same socket, right ?
Yes. And on a NUMA node close to the NIC
>
> TX coalescing is properly setup ?
I will try to play with it, if it is too aggressive, the queue is stopped.
I will play again with it and the ring size to find a better spot.
>
> What interrupt rate do you get ?
~50K per second.
>
> You can take a look at where cycles are spent
>
> perf record -a -g sleep 5
> perf report
>
>
I will.
In case your curious, I have this on the CPU doing completions:
+ 44.86% swapper [kernel.kallsyms] [k] consume_skb
+ 21.38% swapper [kernel.kallsyms] [k] mlx4_en_poll_tx_cq
+ 6.81% swapper [kernel.kallsyms] [k] mlx4_en_free_tx_desc.isra.24
+ 6.07% swapper [kernel.kallsyms] [k] intel_idle
+ 2.98% swapper [kernel.kallsyms] [k] __dev_kfree_skb_any
+ 2.66% rngd rngd [.] 0x0000000000002749
+ 1.79% rngd [kernel.kallsyms] [k] consume_skb
+ 1.28% swapper [kernel.kallsyms] [k] irq_entries_start
+ 1.16% rngd [kernel.kallsyms] [k] mlx4_en_poll_tx_cq
+ 0.86% swapper [kernel.kallsyms] [k] swiotlb_unmap_page
+ 0.79% swapper [kernel.kallsyms] [k] unmap_single
+ 0.63% swapper [kernel.kallsyms] [k] irqtime_account_irq
+ 0.55% swapper [kernel.kallsyms] [k] mlx4_eq_int
+ 0.51% swapper [kernel.kallsyms] [k] eq_set_ci.isra.14
and this on the xmit thread:
+ 72.00% kpktgend_6 [kernel.kallsyms] [k] mlx4_en_xmit
+ 13.11% kpktgend_6 [kernel.kallsyms] [k] pktgen_thread_worker
+ 5.34% kpktgend_6 [kernel.kallsyms] [k] _raw_spin_lock
+ 3.80% kpktgend_6 [kernel.kallsyms] [k] swiotlb_map_page
+ 2.08% kpktgend_6 [kernel.kallsyms] [k] __iowrite64_copy
+ 1.21% kpktgend_6 [kernel.kallsyms] [k] skb_clone_tx_timestamp
+ 0.87% kpktgend_6 [kernel.kallsyms] [k] kthread_should_stop
+ 0.64% kpktgend_6 [kernel.kallsyms] [k] swiotlb_dma_mapping_error
+ 0.51% kpktgend_6 [kernel.kallsyms] [k] __local_bh_enable_ip
Thanks,
Amir
^ permalink raw reply
* Re: [net-next PATCH V5] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
From: Jamal Hadi Salim @ 2014-10-02 12:53 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Tom Herbert, David Miller, Linux Netdev List, Eric Dumazet,
Hannes Frederic Sowa, Florian Westphal, Daniel Borkmann,
Alexander Duyck, John Fastabend, Dave Taht,
Toke Høiland-Jørgensen
In-Reply-To: <20141001223229.6cbaac07@redhat.com>
On 10/01/14 16:32, Jesper Dangaard Brouer wrote:
> On Wed, 01 Oct 2014 16:05:31 -0400
> I'll try to make it more explicit.
> Will resubmit patchset shortly...
>
Thanks for providing the clarity.
> Notice it is not difficult cause a queue to form, but it is tricky (not
> difficult) to correctly test this patchset. Perhaps you misread my
> statement earlier as "it was difficult to test and cause a queue to form"?
>
The conflict maybe what "difficult" or "common" means.
I know from experience that it is difficult under *normal*
circumstances to create the overload. Example you had to turn
off GSO/TSO to see it for 10G ;-> iow you had to go out of your way to
turn off a useful feature. So you are no longer dealing with "common".
Which is fine by me - I just wanted you to specify that was the
case. I also wanted you to run the testcase which said "this is
how things were before my patch" for 10G (with GSO/TSO). But i
dont think you are in the mood for that and if your patch goes
in, then the reaction to any regression to that wouldnt take long.
If something breaks people would start whining in a short period.
So I am ok with it.
> I think you could read this blog in 30 sec:
> http://netoptimizer.blogspot.dk/2014/04/basic-tuning-for-network-overload.html
>
Ok, yes that message was clear in 30 seconds or less ;-> Immediate
gratification.
It is what i would do (havent tried tweaking c states) - but off the
bat, I would do what you did when i want to run serious networking.
> My cover letter and testing section... will take you longer that 30
> sec, it have grown quite large (and Eric will not even read it :-P ;-))
>
But it is referenced forever - so i can go back and read it. A url
may return a 404 in 5 years.
> Believe or not, I've actually restricted and reduced the testing
> section.
I agree there is an upper bound to how much testing you can do.
Looking forward to seeing a paper with all the nice details.
cheers,
jamal
^ 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