* [net-next-2.6 06/27] Documentation/networking/ixgbevf.txt: Update documentation
From: Jeff Kirsher @ 2010-12-10 9:50 UTC (permalink / raw)
To: davem, davem; +Cc: Jeff Kirsher, netdev, gospo, bphilips
In-Reply-To: <1291974667-30254-1-git-send-email-jeffrey.t.kirsher@intel.com>
Update Intel Wired LAN ixgbevf documentation.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
Documentation/networking/ixgbevf.txt | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/Documentation/networking/ixgbevf.txt b/Documentation/networking/ixgbevf.txt
index 21dd5d1..5a91a41 100644
--- a/Documentation/networking/ixgbevf.txt
+++ b/Documentation/networking/ixgbevf.txt
@@ -35,10 +35,6 @@ Driver ID Guide at:
Known Issues/Troubleshooting
============================
- Unloading Physical Function (PF) Driver Causes System Reboots When VM is
- Running and VF is Loaded on the VM
- ------------------------------------------------------------------------
- Do not unload the PF driver (ixgbe) while VFs are assigned to guests.
Support
=======
--
1.7.3.2
^ permalink raw reply related
* [net-next-2.6 04/27] Documentation/networking/igbvf.txt: Update documentation
From: Jeff Kirsher @ 2010-12-10 9:50 UTC (permalink / raw)
To: davem, davem; +Cc: Jeff Kirsher, netdev, gospo, bphilips
In-Reply-To: <1291974667-30254-1-git-send-email-jeffrey.t.kirsher@intel.com>
Update Intel Wired LAN igbvf documentation.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
Documentation/networking/igbvf.txt | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/networking/igbvf.txt b/Documentation/networking/igbvf.txt
index 0560281..694817b 100644
--- a/Documentation/networking/igbvf.txt
+++ b/Documentation/networking/igbvf.txt
@@ -58,7 +58,9 @@ Additional Configurations
Ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
- diagnostics, as well as displaying statistical information.
+ diagnostics, as well as displaying statistical information. Ethtool
+ version 3.0 or later is required for this functionality, although we
+ strongly recommend downloading the latest version at:
http://sourceforge.net/projects/gkernel.
--
1.7.3.2
^ permalink raw reply related
* [RFC PATCH V2 1/5] Add a new sock flag for zero-copy
From: Shirley Ma @ 2010-12-10 9:55 UTC (permalink / raw)
To: Avi Kivity, Arnd Bergmann, mst; +Cc: xiaohui.xin, netdev, kvm, linux-kernel
Signed-off-by: Shirley Ma <xma@us.ibm.com>
include/net/sock.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index a6338d0..ff34ea7 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -543,6 +543,7 @@ enum sock_flags {
SOCK_TIMESTAMPING_SYS_HARDWARE, /* %SOF_TIMESTAMPING_SYS_HARDWARE */
SOCK_FASYNC, /* fasync() active */
SOCK_RXQ_OVFL,
+ SOCK_ZEROCOPY,
};
static inline void sock_copy_flags(struct sock *nsk, struct sock *osk)
^ permalink raw reply related
* [RFC PATCH V2 0/5] macvtap TX zero copy between guest and host kernel
From: Shirley Ma @ 2010-12-10 9:51 UTC (permalink / raw)
To: Avi Kivity, Arnd Bergmann, mst; +Cc: xiaohui.xin, netdev, kvm, linux-kernel
This patchset add supports for TX zero-copy between guest and host
kernel through vhost. It significantly reduces CPU utilization on the
local host on which the guest is located (It reduced 30-50% CPU usage
for vhost thread for single stream test). The patchset is based on
previous submission and comments from the community regarding when/how
to handle guest kernel buffers to be released. This is the simplest
approach I can think of after comparing with several other solutions.
This patchset includes:
1. Induce a new sock zero-copy flag, SOCK_ZEROCOPY;
2. Induce a new device flag, NETIF_F_ZEROCOPY for device can support
zero-copy;
3. Add a new struct skb_ubuf_info in skb_share_info for userspace
buffers release callback when device DMA has done for that skb;
4. Add vhost zero-copy callback in vhost when skb last refcnt is gone;
add vhost_zerocopy_add_used_and_signal to notify guest to release TX
skb buffers.
5. Add macvtap zero-copy in lower device when sending packet is greater
than 128 bytes.
The patchset has passed netperf/netserver test on Chelsio, and
continuing test on other 10GbE NICs, like Intel ixgbe, Mellanox mlx4...
I will provide guest to host, host to guest performance data next week.
However when running stress test, vhost & virtio_net seems out of sync,
and virito_net interrupt was disabled somehow, and it stopped to send
any packet. This problem has bothered me for a long long time, I will
continue to look at this.
Please review this.
Thanks
Shirley
^ permalink raw reply
* [net-next-2.6 09/27] Intel Wired LAN drivers: Use static const
From: Jeff Kirsher @ 2010-12-10 9:50 UTC (permalink / raw)
To: davem, davem; +Cc: Jeff Kirsher, netdev, gospo, bphilips, joe
In-Reply-To: <1291974667-30254-1-git-send-email-jeffrey.t.kirsher@intel.com>
Based on work by Joe Perches <joe@perches.com>
Using static const to decrease data and overall object size.
CC: Joe Perches <joe@perches.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
---
drivers/net/e1000/e1000_hw.c | 20 ++++++++++----------
drivers/net/e1000/e1000_param.c | 13 +++++++------
drivers/net/e1000e/phy.c | 11 ++++++-----
drivers/net/igb/e1000_phy.c | 11 ++++++-----
drivers/net/ixgb/ixgb_param.c | 21 +++++++++++----------
drivers/net/ixgbe/ixgbe_ethtool.c | 24 ++++++++++++++----------
drivers/net/ixgbevf/ethtool.c | 18 +++++++++++-------
7 files changed, 65 insertions(+), 53 deletions(-)
diff --git a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c
index c7e242b6..77d08e6 100644
--- a/drivers/net/e1000/e1000_hw.c
+++ b/drivers/net/e1000/e1000_hw.c
@@ -4892,11 +4892,11 @@ static s32 e1000_get_cable_length(struct e1000_hw *hw, u16 *min_length,
} else if (hw->phy_type == e1000_phy_igp) { /* For IGP PHY */
u16 cur_agc_value;
u16 min_agc_value = IGP01E1000_AGC_LENGTH_TABLE_SIZE;
- u16 agc_reg_array[IGP01E1000_PHY_CHANNEL_NUM] =
- { IGP01E1000_PHY_AGC_A,
- IGP01E1000_PHY_AGC_B,
- IGP01E1000_PHY_AGC_C,
- IGP01E1000_PHY_AGC_D
+ static const u16 agc_reg_array[IGP01E1000_PHY_CHANNEL_NUM] = {
+ IGP01E1000_PHY_AGC_A,
+ IGP01E1000_PHY_AGC_B,
+ IGP01E1000_PHY_AGC_C,
+ IGP01E1000_PHY_AGC_D
};
/* Read the AGC registers for all channels */
for (i = 0; i < IGP01E1000_PHY_CHANNEL_NUM; i++) {
@@ -5071,11 +5071,11 @@ static s32 e1000_config_dsp_after_link_change(struct e1000_hw *hw, bool link_up)
{
s32 ret_val;
u16 phy_data, phy_saved_data, speed, duplex, i;
- u16 dsp_reg_array[IGP01E1000_PHY_CHANNEL_NUM] =
- { IGP01E1000_PHY_AGC_PARAM_A,
- IGP01E1000_PHY_AGC_PARAM_B,
- IGP01E1000_PHY_AGC_PARAM_C,
- IGP01E1000_PHY_AGC_PARAM_D
+ static const u16 dsp_reg_array[IGP01E1000_PHY_CHANNEL_NUM] = {
+ IGP01E1000_PHY_AGC_PARAM_A,
+ IGP01E1000_PHY_AGC_PARAM_B,
+ IGP01E1000_PHY_AGC_PARAM_C,
+ IGP01E1000_PHY_AGC_PARAM_D
};
u16 min_length, max_length;
diff --git a/drivers/net/e1000/e1000_param.c b/drivers/net/e1000/e1000_param.c
index 10d8d98..1301eba 100644
--- a/drivers/net/e1000/e1000_param.c
+++ b/drivers/net/e1000/e1000_param.c
@@ -352,12 +352,13 @@ void __devinit e1000_check_options(struct e1000_adapter *adapter)
}
{ /* Flow Control */
- struct e1000_opt_list fc_list[] =
- {{ E1000_FC_NONE, "Flow Control Disabled" },
- { E1000_FC_RX_PAUSE,"Flow Control Receive Only" },
- { E1000_FC_TX_PAUSE,"Flow Control Transmit Only" },
- { E1000_FC_FULL, "Flow Control Enabled" },
- { E1000_FC_DEFAULT, "Flow Control Hardware Default" }};
+ static const struct e1000_opt_list fc_list[] = {
+ { E1000_FC_NONE, "Flow Control Disabled" },
+ { E1000_FC_RX_PAUSE, "Flow Control Receive Only" },
+ { E1000_FC_TX_PAUSE, "Flow Control Transmit Only" },
+ { E1000_FC_FULL, "Flow Control Enabled" },
+ { E1000_FC_DEFAULT, "Flow Control Hardware Default" }
+ };
opt = (struct e1000_option) {
.type = list_option,
diff --git a/drivers/net/e1000e/phy.c b/drivers/net/e1000e/phy.c
index 3d3dc0c..6ad90cc 100644
--- a/drivers/net/e1000e/phy.c
+++ b/drivers/net/e1000e/phy.c
@@ -1840,11 +1840,12 @@ s32 e1000e_get_cable_length_igp_2(struct e1000_hw *hw)
u16 phy_data, i, agc_value = 0;
u16 cur_agc_index, max_agc_index = 0;
u16 min_agc_index = IGP02E1000_CABLE_LENGTH_TABLE_SIZE - 1;
- u16 agc_reg_array[IGP02E1000_PHY_CHANNEL_NUM] =
- {IGP02E1000_PHY_AGC_A,
- IGP02E1000_PHY_AGC_B,
- IGP02E1000_PHY_AGC_C,
- IGP02E1000_PHY_AGC_D};
+ static const u16 agc_reg_array[IGP02E1000_PHY_CHANNEL_NUM] = {
+ IGP02E1000_PHY_AGC_A,
+ IGP02E1000_PHY_AGC_B,
+ IGP02E1000_PHY_AGC_C,
+ IGP02E1000_PHY_AGC_D
+ };
/* Read the AGC registers for all channels */
for (i = 0; i < IGP02E1000_PHY_CHANNEL_NUM; i++) {
diff --git a/drivers/net/igb/e1000_phy.c b/drivers/net/igb/e1000_phy.c
index ddd036a..6694bf3 100644
--- a/drivers/net/igb/e1000_phy.c
+++ b/drivers/net/igb/e1000_phy.c
@@ -1757,11 +1757,12 @@ s32 igb_get_cable_length_igp_2(struct e1000_hw *hw)
u16 phy_data, i, agc_value = 0;
u16 cur_agc_index, max_agc_index = 0;
u16 min_agc_index = IGP02E1000_CABLE_LENGTH_TABLE_SIZE - 1;
- u16 agc_reg_array[IGP02E1000_PHY_CHANNEL_NUM] =
- {IGP02E1000_PHY_AGC_A,
- IGP02E1000_PHY_AGC_B,
- IGP02E1000_PHY_AGC_C,
- IGP02E1000_PHY_AGC_D};
+ static const u16 agc_reg_array[IGP02E1000_PHY_CHANNEL_NUM] = {
+ IGP02E1000_PHY_AGC_A,
+ IGP02E1000_PHY_AGC_B,
+ IGP02E1000_PHY_AGC_C,
+ IGP02E1000_PHY_AGC_D
+ };
/* Read the AGC registers for all channels */
for (i = 0; i < IGP02E1000_PHY_CHANNEL_NUM; i++) {
diff --git a/drivers/net/ixgb/ixgb_param.c b/drivers/net/ixgb/ixgb_param.c
index 88a08f0..dd7fbeb 100644
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -191,9 +191,9 @@ struct ixgb_option {
} r;
struct { /* list_option info */
int nr;
- struct ixgb_opt_list {
+ const struct ixgb_opt_list {
int i;
- char *str;
+ const char *str;
} *p;
} l;
} arg;
@@ -226,7 +226,7 @@ ixgb_validate_option(unsigned int *value, const struct ixgb_option *opt)
break;
case list_option: {
int i;
- struct ixgb_opt_list *ent;
+ const struct ixgb_opt_list *ent;
for (i = 0; i < opt->arg.l.nr; i++) {
ent = &opt->arg.l.p[i];
@@ -322,14 +322,15 @@ ixgb_check_options(struct ixgb_adapter *adapter)
}
{ /* Flow Control */
- struct ixgb_opt_list fc_list[] =
- {{ ixgb_fc_none, "Flow Control Disabled" },
- { ixgb_fc_rx_pause,"Flow Control Receive Only" },
- { ixgb_fc_tx_pause,"Flow Control Transmit Only" },
- { ixgb_fc_full, "Flow Control Enabled" },
- { ixgb_fc_default, "Flow Control Hardware Default" }};
+ static const struct ixgb_opt_list fc_list[] = {
+ { ixgb_fc_none, "Flow Control Disabled" },
+ { ixgb_fc_rx_pause, "Flow Control Receive Only" },
+ { ixgb_fc_tx_pause, "Flow Control Transmit Only" },
+ { ixgb_fc_full, "Flow Control Enabled" },
+ { ixgb_fc_default, "Flow Control Hardware Default" }
+ };
- const struct ixgb_option opt = {
+ static const struct ixgb_option opt = {
.type = list_option,
.name = "Flow Control",
.err = "reading default settings from EEPROM",
diff --git a/drivers/net/ixgbe/ixgbe_ethtool.c b/drivers/net/ixgbe/ixgbe_ethtool.c
index ef3f910..90a740d 100644
--- a/drivers/net/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ixgbe/ixgbe_ethtool.c
@@ -1157,7 +1157,7 @@ struct ixgbe_reg_test {
#define TABLE64_TEST_HI 6
/* default 82599 register test */
-static struct ixgbe_reg_test reg_test_82599[] = {
+static const struct ixgbe_reg_test reg_test_82599[] = {
{ IXGBE_FCRTL_82599(0), 1, PATTERN_TEST, 0x8007FFF0, 0x8007FFF0 },
{ IXGBE_FCRTH_82599(0), 1, PATTERN_TEST, 0x8007FFF0, 0x8007FFF0 },
{ IXGBE_PFCTOP, 1, PATTERN_TEST, 0xFFFFFFFF, 0xFFFFFFFF },
@@ -1181,7 +1181,7 @@ static struct ixgbe_reg_test reg_test_82599[] = {
};
/* default 82598 register test */
-static struct ixgbe_reg_test reg_test_82598[] = {
+static const struct ixgbe_reg_test reg_test_82598[] = {
{ IXGBE_FCRTL(0), 1, PATTERN_TEST, 0x8007FFF0, 0x8007FFF0 },
{ IXGBE_FCRTH(0), 1, PATTERN_TEST, 0x8007FFF0, 0x8007FFF0 },
{ IXGBE_PFCTOP, 1, PATTERN_TEST, 0xFFFFFFFF, 0xFFFFFFFF },
@@ -1208,18 +1208,22 @@ static struct ixgbe_reg_test reg_test_82598[] = {
{ 0, 0, 0, 0 }
};
+static const u32 register_test_patterns[] = {
+ 0x5A5A5A5A, 0xA5A5A5A5, 0x00000000, 0xFFFFFFFF
+};
+
#define REG_PATTERN_TEST(R, M, W) \
{ \
u32 pat, val, before; \
- const u32 _test[] = {0x5A5A5A5A, 0xA5A5A5A5, 0x00000000, 0xFFFFFFFF}; \
- for (pat = 0; pat < ARRAY_SIZE(_test); pat++) { \
+ for (pat = 0; pat < ARRAY_SIZE(register_test_patterns); pat++) { \
before = readl(adapter->hw.hw_addr + R); \
- writel((_test[pat] & W), (adapter->hw.hw_addr + R)); \
+ writel((register_test_patterns[pat] & W), \
+ (adapter->hw.hw_addr + R)); \
val = readl(adapter->hw.hw_addr + R); \
- if (val != (_test[pat] & W & M)) { \
- e_err(drv, "pattern test reg %04X failed: got " \
- "0x%08X expected 0x%08X\n", \
- R, val, (_test[pat] & W & M)); \
+ if (val != (register_test_patterns[pat] & W & M)) { \
+ e_err(drv, "pattern test reg %04X failed: got " \
+ "0x%08X expected 0x%08X\n", \
+ R, val, (register_test_patterns[pat] & W & M)); \
*data = R; \
writel(before, adapter->hw.hw_addr + R); \
return 1; \
@@ -1246,7 +1250,7 @@ static struct ixgbe_reg_test reg_test_82598[] = {
static int ixgbe_reg_test(struct ixgbe_adapter *adapter, u64 *data)
{
- struct ixgbe_reg_test *test;
+ const struct ixgbe_reg_test *test;
u32 value, before, after;
u32 i, toggle;
diff --git a/drivers/net/ixgbevf/ethtool.c b/drivers/net/ixgbevf/ethtool.c
index 4cc817a..fa29b3c 100644
--- a/drivers/net/ixgbevf/ethtool.c
+++ b/drivers/net/ixgbevf/ethtool.c
@@ -544,7 +544,7 @@ struct ixgbevf_reg_test {
#define TABLE64_TEST_HI 6
/* default VF register test */
-static struct ixgbevf_reg_test reg_test_vf[] = {
+static const struct ixgbevf_reg_test reg_test_vf[] = {
{ IXGBE_VFRDBAL(0), 2, PATTERN_TEST, 0xFFFFFF80, 0xFFFFFF80 },
{ IXGBE_VFRDBAH(0), 2, PATTERN_TEST, 0xFFFFFFFF, 0xFFFFFFFF },
{ IXGBE_VFRDLEN(0), 2, PATTERN_TEST, 0x000FFF80, 0x000FFFFF },
@@ -557,19 +557,23 @@ static struct ixgbevf_reg_test reg_test_vf[] = {
{ 0, 0, 0, 0 }
};
+static const u32 register_test_patterns[] = {
+ 0x5A5A5A5A, 0xA5A5A5A5, 0x00000000, 0xFFFFFFFF
+};
+
#define REG_PATTERN_TEST(R, M, W) \
{ \
u32 pat, val, before; \
- const u32 _test[] = {0x5A5A5A5A, 0xA5A5A5A5, 0x00000000, 0xFFFFFFFF}; \
- for (pat = 0; pat < ARRAY_SIZE(_test); pat++) { \
+ for (pat = 0; pat < ARRAY_SIZE(register_test_patterns); pat++) { \
before = readl(adapter->hw.hw_addr + R); \
- writel((_test[pat] & W), (adapter->hw.hw_addr + R)); \
+ writel((register_test_patterns[pat] & W), \
+ (adapter->hw.hw_addr + R)); \
val = readl(adapter->hw.hw_addr + R); \
- if (val != (_test[pat] & W & M)) { \
+ if (val != (register_test_patterns[pat] & W & M)) { \
hw_dbg(&adapter->hw, \
"pattern test reg %04X failed: got " \
"0x%08X expected 0x%08X\n", \
- R, val, (_test[pat] & W & M)); \
+ R, val, (register_test_patterns[pat] & W & M)); \
*data = R; \
writel(before, adapter->hw.hw_addr + R); \
return 1; \
@@ -596,7 +600,7 @@ static struct ixgbevf_reg_test reg_test_vf[] = {
static int ixgbevf_reg_test(struct ixgbevf_adapter *adapter, u64 *data)
{
- struct ixgbevf_reg_test *test;
+ const struct ixgbevf_reg_test *test;
u32 i;
test = reg_test_vf;
--
1.7.3.2
^ permalink raw reply related
* [net-next-2.6 07/27] MAINTAINERS: Update Intel Wired LAN info
From: Jeff Kirsher @ 2010-12-10 9:50 UTC (permalink / raw)
To: davem, davem; +Cc: Jeff Kirsher, netdev, gospo, bphilips
In-Reply-To: <1291974667-30254-1-git-send-email-jeffrey.t.kirsher@intel.com>
Update with Intel Wired Ethernet public git trees.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
MAINTAINERS | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9206cb4..4a77d0d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3115,6 +3115,8 @@ M: Alex Duyck <alexander.h.duyck@intel.com>
M: John Ronciak <john.ronciak@intel.com>
L: e1000-devel@lists.sourceforge.net
W: http://e1000.sourceforge.net/
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-2.6.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next-2.6.git
S: Supported
F: Documentation/networking/e100.txt
F: Documentation/networking/e1000.txt
--
1.7.3.2
^ permalink raw reply related
* [net-next-2.6 05/27] Documentation/networking/ixgbe.txt: Update ixgbe documentation
From: Jeff Kirsher @ 2010-12-10 9:50 UTC (permalink / raw)
To: davem, davem; +Cc: Jeff Kirsher, netdev, gospo, bphilips
In-Reply-To: <1291974667-30254-1-git-send-email-jeffrey.t.kirsher@intel.com>
Update Intel Wired LAN ixgbe documentation.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
Documentation/networking/ixgbe.txt | 211 +++++++++++++++++++++++-------------
1 files changed, 136 insertions(+), 75 deletions(-)
diff --git a/Documentation/networking/ixgbe.txt b/Documentation/networking/ixgbe.txt
index eeb6868..9ade280 100644
--- a/Documentation/networking/ixgbe.txt
+++ b/Documentation/networking/ixgbe.txt
@@ -1,107 +1,126 @@
Linux Base Driver for 10 Gigabit PCI Express Intel(R) Network Connection
========================================================================
-March 10, 2009
-
+Intel Gigabit Linux driver.
+Copyright(c) 1999 - 2010 Intel Corporation.
Contents
========
-- In This Release
- Identifying Your Adapter
-- Building and Installation
- Additional Configurations
+- Performance Tuning
+- Known Issues
- Support
+Identifying Your Adapter
+========================
+The driver in this release is compatible with 82598 and 82599-based Intel
+Network Connections.
-In This Release
-===============
+For more information on how to identify your adapter, go to the Adapter &
+Driver ID Guide at:
-This file describes the ixgbe Linux Base Driver for the 10 Gigabit PCI
-Express Intel(R) Network Connection. This driver includes support for
-Itanium(R)2-based systems.
+ http://support.intel.com/support/network/sb/CS-012904.htm
-For questions related to hardware requirements, refer to the documentation
-supplied with your 10 Gigabit adapter. All hardware requirements listed apply
-to use with Linux.
+SFP+ Devices with Pluggable Optics
+----------------------------------
-The following features are available in this kernel:
- - Native VLANs
- - Channel Bonding (teaming)
- - SNMP
- - Generic Receive Offload
- - Data Center Bridging
+82599-BASED ADAPTERS
-Channel Bonding documentation can be found in the Linux kernel source:
-/Documentation/networking/bonding.txt
+NOTES: If your 82599-based Intel(R) Network Adapter came with Intel optics, or
+is an Intel(R) Ethernet Server Adapter X520-2, then it only supports Intel
+optics and/or the direct attach cables listed below.
-Ethtool, lspci, and ifconfig can be used to display device and driver
-specific information.
+When 82599-based SFP+ devices are connected back to back, they should be set to
+the same Speed setting via Ethtool. Results may vary if you mix speed settings.
+82598-based adapters support all passive direct attach cables that comply
+with SFF-8431 v4.1 and SFF-8472 v10.4 specifications. Active direct attach
+cables are not supported.
+Supplier Type Part Numbers
-Identifying Your Adapter
-========================
+SR Modules
+Intel DUAL RATE 1G/10G SFP+ SR (bailed) FTLX8571D3BCV-IT
+Intel DUAL RATE 1G/10G SFP+ SR (bailed) AFBR-703SDDZ-IN1
+Intel DUAL RATE 1G/10G SFP+ SR (bailed) AFBR-703SDZ-IN2
+LR Modules
+Intel DUAL RATE 1G/10G SFP+ LR (bailed) FTLX1471D3BCV-IT
+Intel DUAL RATE 1G/10G SFP+ LR (bailed) AFCT-701SDDZ-IN1
+Intel DUAL RATE 1G/10G SFP+ LR (bailed) AFCT-701SDZ-IN2
-This driver supports devices based on the 82598 controller and the 82599
-controller.
+The following is a list of 3rd party SFP+ modules and direct attach cables that
+have received some testing. Not all modules are applicable to all devices.
-For specific information on identifying which adapter you have, please visit:
+Supplier Type Part Numbers
- http://support.intel.com/support/network/sb/CS-008441.htm
+Finisar SFP+ SR bailed, 10g single rate FTLX8571D3BCL
+Avago SFP+ SR bailed, 10g single rate AFBR-700SDZ
+Finisar SFP+ LR bailed, 10g single rate FTLX1471D3BCL
+Finisar DUAL RATE 1G/10G SFP+ SR (No Bail) FTLX8571D3QCV-IT
+Avago DUAL RATE 1G/10G SFP+ SR (No Bail) AFBR-703SDZ-IN1
+Finisar DUAL RATE 1G/10G SFP+ LR (No Bail) FTLX1471D3QCV-IT
+Avago DUAL RATE 1G/10G SFP+ LR (No Bail) AFCT-701SDZ-IN1
+Finistar 1000BASE-T SFP FCLF8522P2BTL
+Avago 1000BASE-T SFP ABCU-5710RZ
-Building and Installation
-=========================
+82599-based adapters support all passive and active limiting direct attach
+cables that comply with SFF-8431 v4.1 and SFF-8472 v10.4 specifications.
-select m for "Intel(R) 10GbE PCI Express adapters support" located at:
- Location:
- -> Device Drivers
- -> Network device support (NETDEVICES [=y])
- -> Ethernet (10000 Mbit) (NETDEV_10000 [=y])
+Laser turns off for SFP+ when ifconfig down
+-------------------------------------------
+"ifconfig down" turns off the laser for 82599-based SFP+ fiber adapters.
+"ifconfig up" turns on the later.
-1. make modules & make modules_install
-2. Load the module:
+82598-BASED ADAPTERS
-# modprobe ixgbe
+NOTES for 82598-Based Adapters:
+- Intel(R) Network Adapters that support removable optical modules only support
+ their original module type (i.e., the Intel(R) 10 Gigabit SR Dual Port
+ Express Module only supports SR optical modules). If you plug in a different
+ type of module, the driver will not load.
+- Hot Swapping/hot plugging optical modules is not supported.
+- Only single speed, 10 gigabit modules are supported.
+- LAN on Motherboard (LOMs) may support DA, SR, or LR modules. Other module
+ types are not supported. Please see your system documentation for details.
- The insmod command can be used if the full
- path to the driver module is specified. For example:
+The following is a list of 3rd party SFP+ modules and direct attach cables that
+have received some testing. Not all modules are applicable to all devices.
- insmod /lib/modules/<KERNEL VERSION>/kernel/drivers/net/ixgbe/ixgbe.ko
+Supplier Type Part Numbers
- With 2.6 based kernels also make sure that older ixgbe drivers are
- removed from the kernel, before loading the new module:
+Finisar SFP+ SR bailed, 10g single rate FTLX8571D3BCL
+Avago SFP+ SR bailed, 10g single rate AFBR-700SDZ
+Finisar SFP+ LR bailed, 10g single rate FTLX1471D3BCL
- rmmod ixgbe; modprobe ixgbe
+82598-based adapters support all passive direct attach cables that comply
+with SFF-8431 v4.1 and SFF-8472 v10.4 specifications. Active direct attach
+cables are not supported.
-3. Assign an IP address to the interface by entering the following, where
- x is the interface number:
- ifconfig ethx <IP_address>
+Flow Control
+------------
+Ethernet Flow Control (IEEE 802.3x) can be configured with ethtool to enable
+receiving and transmitting pause frames for ixgbe. When TX is enabled, PAUSE
+frames are generated when the receive packet buffer crosses a predefined
+threshold. When rx is enabled, the transmit unit will halt for the time delay
+specified when a PAUSE frame is received.
-4. Verify that the interface works. Enter the following, where <IP_address>
- is the IP address for another machine on the same subnet as the interface
- that is being tested:
+Flow Control is enabled by default. If you want to disable a flow control
+capable link partner, use Ethtool:
- ping <IP_address>
+ ethtool -A eth? autoneg off RX off TX off
+NOTE: For 82598 backplane cards entering 1 gig mode, flow control default
+behavior is changed to off. Flow control in 1 gig mode on these devices can
+lead to Tx hangs.
Additional Configurations
=========================
- Viewing Link Messages
- ---------------------
- Link messages will not be displayed to the console if the distribution is
- restricting system messages. In order to see network driver link messages on
- your console, set dmesg to eight by entering the following:
-
- dmesg -n 8
-
- NOTE: This setting is not saved across reboots.
-
-
Jumbo Frames
------------
The driver supports Jumbo Frames for all adapters. Jumbo Frames support is
@@ -123,13 +142,8 @@ Additional Configurations
other protocols besides TCP. It's also safe to use with configurations that
are problematic for LRO, namely bridging and iSCSI.
- GRO is enabled by default in the driver. Future versions of ethtool will
- support disabling and re-enabling GRO on the fly.
-
-
Data Center Bridging, aka DCB
-----------------------------
-
DCB is a configuration Quality of Service implementation in hardware.
It uses the VLAN priority tag (802.1p) to filter traffic. That means
that there are 8 different priorities that traffic can be filtered into.
@@ -163,24 +177,71 @@ Additional Configurations
http://e1000.sf.net
-
Ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
- diagnostics, as well as displaying statistical information. Ethtool
- version 3.0 or later is required for this functionality.
+ diagnostics, as well as displaying statistical information. The latest
+ Ethtool version is required for this functionality.
The latest release of ethtool can be found from
http://sourceforge.net/projects/gkernel.
-
- NAPI
+ FCoE
----
+ This release of the ixgbe driver contains new code to enable users to use
+ Fiber Channel over Ethernet (FCoE) and Data Center Bridging (DCB)
+ functionality that is supported by the 82598-based hardware. This code has
+ no default effect on the regular driver operation, and configuring DCB and
+ FCoE is outside the scope of this driver README. Refer to
+ http://www.open-fcoe.org/ for FCoE project information and contact
+ e1000-eedc@lists.sourceforge.net for DCB information.
+
+ MAC and VLAN anti-spoofing feature
+ ----------------------------------
+ When a malicious driver attempts to send a spoofed packet, it is dropped by
+ the hardware and not transmitted. An interrupt is sent to the PF driver
+ notifying it of the spoof attempt.
+
+ When a spoofed packet is detected the PF driver will send the following
+ message to the system log (displayed by the "dmesg" command):
+
+ Spoof event(s) detected on VF (n)
+
+ Where n=the VF that attempted to do the spoofing.
+
+
+Performance Tuning
+==================
+
+An excellent article on performance tuning can be found at:
+
+http://www.redhat.com/promo/summit/2008/downloads/pdf/Thursday/Mark_Wagner.pdf
+
+
+Known Issues
+============
+
+ Enabling SR-IOV in a 32-bit Microsoft* Windows* Server 2008 Guest OS using
+ Intel (R) 82576-based GbE or Intel (R) 82599-based 10GbE controller under KVM
+ -----------------------------------------------------------------------------
+ KVM Hypervisor/VMM supports direct assignment of a PCIe device to a VM. This
+ includes traditional PCIe devices, as well as SR-IOV-capable devices using
+ Intel 82576-based and 82599-based controllers.
+
+ While direct assignment of a PCIe device or an SR-IOV Virtual Function (VF)
+ to a Linux-based VM running 2.6.32 or later kernel works fine, there is a
+ known issue with Microsoft Windows Server 2008 VM that results in a "yellow
+ bang" error. This problem is within the KVM VMM itself, not the Intel driver,
+ or the SR-IOV logic of the VMM, but rather that KVM emulates an older CPU
+ model for the guests, and this older CPU model does not support MSI-X
+ interrupts, which is a requirement for Intel SR-IOV.
- NAPI (Rx polling mode) is supported in the ixgbe driver. NAPI is enabled
- by default in the driver.
+ If you wish to use the Intel 82576 or 82599-based controllers in SR-IOV mode
+ with KVM and a Microsoft Windows Server 2008 guest try the following
+ workaround. The workaround is to tell KVM to emulate a different model of CPU
+ when using qemu to create the KVM guest:
- See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI.
+ "-cpu qemu64,model=13"
Support
--
1.7.3.2
^ permalink raw reply related
* [net-next-2.6 03/27] Documentation/networking/igb.txt: update documentation
From: Jeff Kirsher @ 2010-12-10 9:50 UTC (permalink / raw)
To: davem, davem; +Cc: Jeff Kirsher, netdev, gospo, bphilips
In-Reply-To: <1291974667-30254-1-git-send-email-jeffrey.t.kirsher@intel.com>
Update Intel Wired LAN igb documentation.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
Documentation/networking/igb.txt | 22 +++++++++++++++++++---
1 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/networking/igb.txt b/Documentation/networking/igb.txt
index ab2d718..393bdb7 100644
--- a/Documentation/networking/igb.txt
+++ b/Documentation/networking/igb.txt
@@ -36,6 +36,7 @@ Default Value: 0
This parameter adds support for SR-IOV. It causes the driver to spawn up to
max_vfs worth of virtual function.
+
Additional Configurations
=========================
@@ -60,7 +61,8 @@ Additional Configurations
Ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
- diagnostics, as well as displaying statistical information.
+ diagnostics, as well as displaying statistical information. The latest
+ version of Ethtool can be found at:
http://sourceforge.net/projects/gkernel.
@@ -103,8 +105,8 @@ Additional Configurations
NOTE: You need to have inet_lro enabled via either the CONFIG_INET_LRO or
CONFIG_INET_LRO_MODULE kernel config option. Additionally, if
- CONFIG_INET_LRO_MODULE is used, the inet_lro module needs to be loaded
- before the igb driver.
+ CONFIG_INET_LRO_MODULE is used, the inet_lro module needs to be loaded before
+ the igb driver.
You can verify that the driver is using LRO by looking at these counters in
Ethtool:
@@ -116,6 +118,20 @@ Additional Configurations
NOTE: IPv6 and UDP are not supported by LRO.
+ MAC and VLAN anti-spoofing feature
+ ----------------------------------
+ When a malicious driver attempts to send a spoofed packet, it is dropped by
+ the hardware and not transmitted. An interrupt is sent to the PF driver
+ notifying it of the spoof attempt.
+
+ When a spoofed packet is detected the PF driver will send the following
+ message to the system log (displayed by the "dmesg" command):
+
+ Spoof event(s) detected on VF(n)
+
+ Where n=the VF that attempted to do the spoofing.
+
+
Support
=======
--
1.7.3.2
^ permalink raw reply related
* [net-next-2.6 02/27] Documentation/networking/e1000e.txt: Update documentation
From: Jeff Kirsher @ 2010-12-10 9:50 UTC (permalink / raw)
To: davem, davem; +Cc: Jeff Kirsher, netdev, gospo, bphilips
In-Reply-To: <1291974667-30254-1-git-send-email-jeffrey.t.kirsher@intel.com>
Update Intel Wired LAN e1000e documentation.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
Documentation/networking/e1000e.txt | 40 +++++++++++++++++++---------------
1 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/Documentation/networking/e1000e.txt b/Documentation/networking/e1000e.txt
index 6aa048b..81a66e6 100644
--- a/Documentation/networking/e1000e.txt
+++ b/Documentation/networking/e1000e.txt
@@ -1,5 +1,5 @@
Linux* Driver for Intel(R) Network Connection
-===============================================================
+=============================================
Intel Gigabit Linux driver.
Copyright(c) 1999 - 2010 Intel Corporation.
@@ -61,6 +61,12 @@ per second, even if more packets have come in. This reduces interrupt
load on the system and can lower CPU utilization under heavy load,
but will increase latency as packets are not processed as quickly.
+The default behaviour of the driver previously assumed a static
+InterruptThrottleRate value of 8000, providing a good fallback value for
+all traffic types, but lacking in small packet performance and latency.
+The hardware can handle many more small packets per second however, and
+for this reason an adaptive interrupt moderation algorithm was implemented.
+
The driver has two adaptive modes (setting 1 or 3) in which
it dynamically adjusts the InterruptThrottleRate value based on the traffic
that it receives. After determining the type of incoming traffic in the last
@@ -86,8 +92,8 @@ InterruptThrottleRate is set to mode 1. In this mode, which operates
the same as mode 3, the InterruptThrottleRate will be increased stepwise to
70000 for traffic in class "Lowest latency".
-In simplified mode the interrupt rate is based on the ratio of Tx and
-Rx traffic. If the bytes per second rate is approximately equal the
+In simplified mode the interrupt rate is based on the ratio of TX and
+RX traffic. If the bytes per second rate is approximately equal, the
interrupt rate will drop as low as 2000 interrupts per second. If the
traffic is mostly transmit or mostly receive, the interrupt rate could
be as high as 8000.
@@ -177,7 +183,7 @@ Copybreak
Valid Range: 0-xxxxxxx (0=off)
Default Value: 256
-Driver copies all packets below or equaling this size to a fresh Rx
+Driver copies all packets below or equaling this size to a fresh RX
buffer before handing it up the stack.
This parameter is different than other parameters, in that it is a
@@ -223,17 +229,17 @@ loading or enabling the driver, try disabling this feature.
WriteProtectNVM
---------------
-Valid Range: 0-1
-Default Value: 1 (enabled)
-
-Set the hardware to ignore all write/erase cycles to the GbE region in the
-ICHx NVM (non-volatile memory). This feature can be disabled by the
-WriteProtectNVM module parameter (enabled by default) only after a hardware
-reset, but the machine must be power cycled before trying to enable writes.
-
-Note: the kernel boot option iomem=relaxed may need to be set if the kernel
-config option CONFIG_STRICT_DEVMEM=y, if the root user wants to write the
-NVM from user space via ethtool.
+Valid Range: 0,1
+Default Value: 1
+
+If set to 1, configure the hardware to ignore all write/erase cycles to the
+GbE region in the ICHx NVM (in order to prevent accidental corruption of the
+NVM). This feature can be disabled by setting the parameter to 0 during initial
+driver load.
+NOTE: The machine must be power cycled (full off/on) when enabling NVM writes
+via setting the parameter to zero. Once the NVM has been locked (via the
+parameter at 1 when the driver loads) it cannot be unlocked except via power
+cycle.
Additional Configurations
=========================
@@ -259,7 +265,6 @@ Additional Configurations
- Some adapters limit Jumbo Frames sized packets to a maximum of
4096 bytes and some adapters do not support Jumbo Frames.
-
Ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
@@ -283,8 +288,7 @@ Additional Configurations
loaded when shutting down or rebooting the system.
In most cases Wake On LAN is only supported on port A for multiple port
- adapters. To verify if a port supports Wake on LAN run ethtool eth<X>.
-
+ adapters. To verify if a port supports Wake on Lan run Ethtool eth<X>.
Support
=======
--
1.7.3.2
^ permalink raw reply related
* [net-next-2.6 01/27] Documentation/networking/e1000.txt: Update documentation
From: Jeff Kirsher @ 2010-12-10 9:50 UTC (permalink / raw)
To: davem, davem; +Cc: Jeff Kirsher, netdev, gospo, bphilips
In-Reply-To: <1291974667-30254-1-git-send-email-jeffrey.t.kirsher@intel.com>
Update Intel Wired LAN e1000 documentation.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
Documentation/networking/e1000.txt | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/networking/e1000.txt b/Documentation/networking/e1000.txt
index d9271e7..6cb13e9 100644
--- a/Documentation/networking/e1000.txt
+++ b/Documentation/networking/e1000.txt
@@ -79,7 +79,7 @@ InterruptThrottleRate
---------------------
(not supported on Intel(R) 82542, 82543 or 82544-based adapters)
Valid Range: 0,1,3,4,100-100000 (0=off, 1=dynamic, 3=dynamic conservative,
- 4=simplified balancing)
+ 4=simplified balancing)
Default Value: 3
The driver can limit the amount of interrupts per second that the adapter
@@ -124,8 +124,8 @@ InterruptThrottleRate is set to mode 1. In this mode, which operates
the same as mode 3, the InterruptThrottleRate will be increased stepwise to
70000 for traffic in class "Lowest latency".
-In simplified mode the interrupt rate is based on the ratio of Tx and
-Rx traffic. If the bytes per second rate is approximately equal, the
+In simplified mode the interrupt rate is based on the ratio of TX and
+RX traffic. If the bytes per second rate is approximately equal, the
interrupt rate will drop as low as 2000 interrupts per second. If the
traffic is mostly transmit or mostly receive, the interrupt rate could
be as high as 8000.
@@ -245,7 +245,7 @@ NOTE: Depending on the available system resources, the request for a
TxDescriptorStep
----------------
Valid Range: 1 (use every Tx Descriptor)
- 4 (use every 4th Tx Descriptor)
+ 4 (use every 4th Tx Descriptor)
Default Value: 1 (use every Tx Descriptor)
@@ -312,7 +312,7 @@ Valid Range: 0-xxxxxxx (0=off)
Default Value: 256
Usage: insmod e1000.ko copybreak=128
-Driver copies all packets below or equaling this size to a fresh Rx
+Driver copies all packets below or equaling this size to a fresh RX
buffer before handing it up the stack.
This parameter is different than other parameters, in that it is a
--
1.7.3.2
^ permalink raw reply related
* [net-next 00/27][pull-request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2010-12-10 9:50 UTC (permalink / raw)
To: davem, davem; +Cc: Jeff Kirsher, netdev, gospo, bphilips
Here are a batch of fixes and cleanups intended for 2.6.38.
The following changes since commit:
commit defb3519a64141608725e2dac5a5aa9a3c644bae
Author: David S. Miller <davem@davemloft.net>
Date: Wed Dec 8 21:16:57 2010 -0800
net: Abstract away all dst_entry metrics accesses
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6.git master
Bruce Allan (11):
e1000e: 82571-based mezzanine card can fail ethtool link test
e1000e: 82574/82583 performance improvement
e1000e: 82577/8 must acquire h/w semaphore before workaround
e1000e: 82571 Serdes can fail to get link
e1000e: 82577/8/9 mis-configured OEM bits during S0->Sx
e1000e: 82579 PHY incorrectly identified during init
e1000e: support new PBA format from EEPROM
e1000e: prevent null ptr dereference in e1000_tx_queue()
e1000e: minor error message corrections
e1000e: static analysis tools complain of a possible null ptr p
dereference
e1000e: increment the driver version
Carolyn Wyborny (1):
igb: Add new function to read part number from EEPROM in string
format
Dean Nelson (1):
e1000: fix return value not set on error
Don Skidmore (3):
ixgbe: fix X540 phy id to correct value
ixgbe: fix X540 to use it's own info struct
ixgbe: cleanup string function calls to use bound checking versions.
Emil Tantilov (2):
ixgb: Don't check for vlan group on transmit
ixgbe: fix ntuple support
Holger Eitzenberger (1):
e1000e: fix double initialization in blink path
Jeff Kirsher (8):
Documentation/networking/e1000.txt: Update documentation
Documentation/networking/e1000e.txt: Update documentation
Documentation/networking/igb.txt: update documentation
Documentation/networking/igbvf.txt: Update documentation
Documentation/networking/ixgbe.txt: Update ixgbe documentation
Documentation/networking/ixgbevf.txt: Update documentation
MAINTAINERS: Update Intel Wired LAN info
Intel Wired LAN drivers: Use static const
Documentation/networking/e1000.txt | 10 +-
Documentation/networking/e1000e.txt | 40 ++++---
Documentation/networking/igb.txt | 22 +++-
Documentation/networking/igbvf.txt | 4 +-
Documentation/networking/ixgbe.txt | 211 ++++++++++++++++++++++------------
Documentation/networking/ixgbevf.txt | 4 -
MAINTAINERS | 2 +
drivers/net/e1000/e1000_hw.c | 20 ++--
drivers/net/e1000/e1000_main.c | 10 +-
drivers/net/e1000/e1000_param.c | 13 +-
drivers/net/e1000e/82571.c | 46 ++++++--
drivers/net/e1000e/defines.h | 8 +-
drivers/net/e1000e/e1000.h | 4 +-
drivers/net/e1000e/ethtool.c | 14 ++-
drivers/net/e1000e/ich8lan.c | 18 ++-
drivers/net/e1000e/lib.c | 135 ++++++++++++++++++----
drivers/net/e1000e/netdev.c | 21 ++--
drivers/net/e1000e/param.c | 2 +-
drivers/net/e1000e/phy.c | 25 +++-
drivers/net/igb/e1000_defines.h | 7 +
drivers/net/igb/e1000_nvm.c | 93 ++++++++++++++-
drivers/net/igb/e1000_nvm.h | 2 +
drivers/net/igb/e1000_phy.c | 11 +-
drivers/net/igb/igb_main.c | 11 +-
drivers/net/ixgb/ixgb_main.c | 51 +++++----
drivers/net/ixgb/ixgb_param.c | 21 ++--
drivers/net/ixgbe/ixgbe_ethtool.c | 31 +++--
drivers/net/ixgbe/ixgbe_main.c | 32 +++---
drivers/net/ixgbe/ixgbe_phy.c | 2 +-
drivers/net/ixgbe/ixgbe_type.h | 2 +-
drivers/net/ixgbe/ixgbe_x540.c | 4 +-
drivers/net/ixgbevf/ethtool.c | 18 ++-
32 files changed, 624 insertions(+), 270 deletions(-)
--
1.7.3.2
^ permalink raw reply
* [net-next-2.6 08/27] e1000: fix return value not set on error
From: Jeff Kirsher @ 2010-12-10 9:50 UTC (permalink / raw)
To: davem, davem, dnelson
Cc: netdev, Dean Nelson, bphilips, Jesse Brandeburg, Jeff Kirsher,
gospo, stable
In-Reply-To: <1291974667-30254-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Dean Nelson <dnelson@redhat.com>
Dean noticed that 'err' wasn't being set when the "goto err_dma"
statement is executed in the following hunk from the commit. It's value
will be zero as a result of a successful call to e1000_init_hw_struct().
This patch changes the error condition to be correctly propagated.
CC: stable@kernel.org
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000/e1000_main.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 06c7d1c..491bf2a 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -971,11 +971,13 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
*/
dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
pci_using_dac = 1;
- } else if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(32))) {
- dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
} else {
- pr_err("No usable DMA config, aborting\n");
- goto err_dma;
+ err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+ if (err) {
+ pr_err("No usable DMA config, aborting\n");
+ goto err_dma;
+ }
+ dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
}
netdev->netdev_ops = &e1000_netdev_ops;
--
1.7.3.2
^ permalink raw reply related
* Re: Adding Support for SG,GSO,GRO
From: Michał Mirosław @ 2010-12-10 8:27 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Govindarajan, Sriramakrishnan, netdev@vger.kernel.org
In-Reply-To: <1291921115.2647.28.camel@bwh-desktop>
W dniu 9 grudnia 2010 19:58 użytkownik Ben Hutchings
<bhutchings@solarflare.com> napisał:
> On Thu, 2010-12-09 at 19:47 +0100, Michał Mirosław wrote:
>> 2010/12/9 Ben Hutchings <bhutchings@solarflare.com>:
>> > On Thu, 2010-12-09 at 16:03 +0530, Govindarajan, Sriramakrishnan wrote:
>> >> Hi
>> >> We have a NAPI compliant driver(net/drivers/davinci_emac.c), that does
>> >> well at 10/100Mbps loads. Now the same controller/driver is used for
>> >> 1000Mbps
>> >> mode as well, where the CPU gets saturated easily
>> >>
>> >> Internally the module supports scatter gather DMA(which is currently not
>> >> exercised) but there is no HW checksum support.
>> >>
>> >> To specifically implement GRO, GSO support would it be sufficient to add
>> >> SG support to the driver? Are there other means of increasing the throughput
>> >> and decreasing the CPU loading?
>> [...]
>> > On the TX side, NETIF_F_SG means that the stack may include data in the
>> > skb by reference to arbitrary pages *even if their contents are still
>> > being changed* (think sendfile()), which means it depends on hardware
>> > checksum generation.
>>
>> Isn't that condition too broad? If the data could change after packet
>> is submitted to the driver then results would be unpredictable and
>> allow sending wrong data with correct (because hw-calculated)
>> checksum.
> This is not done for a regular send(), only for functions such as
> sendfile() which are specified to read the data asynchronously.
>
>> Right now NETIF_F_SG is removed from dev->features by
>> netdev_fix_features() if no checksum offloads are enabled.
>>
>> Just an idea: would driver with NETIF_F_SG|NETIF_F_HW_CSUM using
>> skb_checksum_help() in xmit path work? This would allow to use DMA
>> scatter-gather without hardware checksumming (and avoid copying the
>> packet's data before sending).
> No, you cannot calculate a checksum for the fragments without also
> copying them to ensure the data doesn't change afterward and invalidate
> the checksum. You could in theory make a copy into multiple fragments,
> but there's no point in doing that unless the frame size is larger than
> a page.
Then at least couple of drivers are broken in this way (ibmveth,
chelsio for UDP, there are other hits on skb_checksum_help).
I'm not familiar with splice/sendfile code, but I would expect, that
pages transferred with it have to be submitted after "data ready"
notification and pinned in memory by DMA mapping (with hardware
checksumming, CPU does not need to see the data, but still it has to
be there already) until the frame is transferred to the network
device. So, even if the contents of the page changes (because further
data is transferred), the part that is submitted to be sent should
not.
If that's really not the case, then splice/sendfile to network is
useless as it means random data corruption. Googling around shows
reports about sendfile() correllated corruption - could this the
cause?
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH] fix hostap registration order
From: Meelis Roos @ 2010-12-10 7:19 UTC (permalink / raw)
To: j; +Cc: David Miller, netdev, linux-wireless
In-Reply-To: <20101209.195315.193716225.davem@davemloft.net>
> > In 2.6.37-rc4, hostap_pci init gives a WARNING with backtrace telling
> > that netif_stop_queue is called before register_netdev. Fix it by moving
> > this call after register_netdev. Removes the warning and seems to work,
> > but why is the call to netif_stop_queue needed at all after
> > register_netdev?
>
> It should simply not touch the queue state at all at this point.
>
> Your change would add a race. At the moment the device is registered
> it can be brought up, and then your code will eroneously modify
> the queue state.
OK, I can make a simpler patch for that but I would like to understand
the original reasons for having netif_stop_queue there. Just a relict or
still somehow important?
Jouni?
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: [PATCH v2 3/4] kthread: NUMA aware kthread_create_on_cpu()
From: Andrew Morton @ 2010-12-10 7:09 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andi Kleen, linux-kernel, netdev, David Miller, Tejun Heo,
Rusty Russell, Tony Luck, Fenghua Yu
In-Reply-To: <1291964561.2803.25.camel@edumazet-laptop>
On Fri, 10 Dec 2010 08:02:41 +0100 Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 09 d__cembre 2010 __ 22:32 -0800, Andrew Morton a __crit :
>
> > but but but. The name "kthread_create_on_cpu" sucks. It's plain wrong.
>
> Okay you are right Andrew ;) I dont have better idea for the moment.
Dunno. kthread_create_with_memory_on_node() :)
How's about kthread_create_for_node()? That's sufficiently vague to
not mislead readers into thinking that it schedules the thread on that
CPU and leaves room in the namespace for a real kthread_create_on_cpu()
(which we could well end up creating).
kthread_create_node_mem()?
> Note that all callers I converted really create one kthread per cpu, not
> per node. They didnt care of node affinity, only me :)
>
> kthread_create_on_node() seems misleading to me (some cpus run on
> memoryless nodes)
True, but what we're doing here is specifying on which node the
kthread's memory resources should reside - we need to do that even for
CPUs which live on memoryless nodes.
^ permalink raw reply
* Re: [PATCH v2 3/4] kthread: NUMA aware kthread_create_on_cpu()
From: Eric Dumazet @ 2010-12-10 7:02 UTC (permalink / raw)
To: Andrew Morton
Cc: Andi Kleen, linux-kernel, netdev, David Miller, Tejun Heo,
Rusty Russell, Tony Luck, Fenghua Yu
In-Reply-To: <20101209223210.acd540de.akpm@linux-foundation.org>
Le jeudi 09 décembre 2010 à 22:32 -0800, Andrew Morton a écrit :
> but but but. The name "kthread_create_on_cpu" sucks. It's plain wrong.
Okay you are right Andrew ;) I dont have better idea for the moment.
Note that all callers I converted really create one kthread per cpu, not
per node. They didnt care of node affinity, only me :)
kthread_create_on_node() seems misleading to me (some cpus run on
memoryless nodes)
^ permalink raw reply
* Re: [PATCH v2 3/4] kthread: NUMA aware kthread_create_on_cpu()
From: Andrew Morton @ 2010-12-10 6:32 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andi Kleen, linux-kernel, netdev, David Miller, Tejun Heo,
Rusty Russell, Tony Luck, Fenghua Yu
In-Reply-To: <1291960798.2803.18.camel@edumazet-laptop>
On Fri, 10 Dec 2010 06:59:58 +0100 Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 09 d__cembre 2010 __ 16:44 -0800, Andrew Morton a __crit :
>
> > The name "kthread_create_on_cpu" is pretty misleading.
> >
> > One would expect such a function to create a kthread which is bound to
> > that CPU. But what it in fact does is to create a kthread which is
> > bound to all CPUs and whose stack, task_struct and thread_info were
> > allocated from the node which contains `cpu'.
> >
> > Also, a saner interface would be one which takes the numa_node_id, not
> > the cpu number.
> >
>
>
> > >
> > > ...
> > >
> > > /**
> > > - * kthread_create - create a kthread.
> > > + * kthread_create_on_cpu - create a kthread.
> > > * @threadfn: the function to run until signal_pending(current).
> > > * @data: data ptr for @threadfn.
> > > + * @cpu: cpu number.
> > > * @namefmt: printf-style name for the thread.
> > > *
> > > * Description: This helper function creates and names a kernel
> > > * thread. The thread will be stopped: use wake_up_process() to start
> > > * it. See also kthread_run().
> > > *
> > > + * If thread is going to be bound on a particular cpu, give its number
> > > + * in @cpu, to get NUMA affinity for kthread stack, or else give -1.
> >
> > This is a bit presumptuous. The caller might wish to later bind this
> > thread to some or all of the CPUs on the node, rather than to a single
> > CPU (eg, kswapd()).
> >
> >
> > So what to do? Maybe add a new kthread_create_node() which prepares a
> > kthread whose memory is bound to that node, then add a
> > kthread_create_cpu() convenience wrapper around that?
> >
>
> We probably can add the "bind to cpu" as a fifth patch, to avoid one
> kthread_bind(p, cpu); done by these callers.
>
> My reasoning not including this kthread_bind(p, cpu) in initial patch
> series that I was focusing on NUMA properties first, not on scheduling
> (this part already runs correctly as far as I know)
>
> Thanks for taking the patch series, I was about to resubmit it today :)
>
but but but. The name "kthread_create_on_cpu" sucks. It's plain wrong.
^ permalink raw reply
* Re: ip rule and/or route problem in 2.6.37-rc5+
From: Ben Greear @ 2010-12-10 6:19 UTC (permalink / raw)
To: NetDev, therbert
In-Reply-To: <4D017D0D.50907@candelatech.com>
On 12/09/2010 05:06 PM, Ben Greear wrote:
>
> This problem appears to have happened between 2.6.36.1 and 2.6.37-rc2.
> We haven't fully bisected the problem yet.
>
>
> The basic test:
>
> * one normal interface using DHCP
> * A second interface specified to use it's own routing table.
> * 'ip rules' to determine behaviour.
>
> After running these commands abelow, the system can no longer
> route out it's normal interface. It appears that the final line
> is the one that messes things up. If you flush table 10001 after
> that, things start working again.
>
> The 'pref 20' rule is also important. It should not have
> any affect on this ping, but it appears that it does, somehow.
> If you remove it, the problem also goes away, regardless of
> the routes in table 10001.
>
>
> ip rule add pref 512 lookup local
> ip rule del pref 0 lookup local
> ip link set eth2 up
> ip -4 addr add 172.16.0.102/24 broadcast 172.16.0.255 dev eth2
> ip rule add to 172.16.0.102 iif eth2 lookup local pref 10
> ip rule add iif eth2 lookup 10001 pref 20
> ip route add 172.16.0.0/24 dev eth2 table 10001
> ip route add unreachable 0/0 table 10001
Seems this is the commit that broke this behaviour:
4465b469008bc03b98a1b8df4e9ae501b6c69d4b is first bad commit
commit 4465b469008bc03b98a1b8df4e9ae501b6c69d4b
Author: Tom Herbert <therbert@google.com>
Date: Sun May 23 19:54:12 2010 +0000
ipv4: Allow configuring subnets as local addresses
This patch allows a host to be configured to respond to any address in
a specified range as if it were local, without actually needing to
configure the address on an interface. This is done through routing
table configuration. For instance, to configure a host to respond
to any address in 10.1/16 received on eth0 as a local address we can do:
ip rule add from all iif eth0 lookup 200
ip route add local 10.1/16 dev lo proto kernel scope host src 127.0.0.1 table 200
This host is now reachable by any 10.1/16 address (route lookup on
input for packets received on eth0 can find the route). On output, the
rule will not be matched so that this host can still send packets to
10.1/16 (not sent on loopback). Presumably, external routing can be
configured to make sense out of this.
To make this work, we needed to modify the logic in finding the
interface which is assigned a given source address for output
(dev_ip_find). We perform a normal fib_lookup instead of just a
lookup on the local table, and in the lookup we ignore the input
interface for matching.
This patch is useful to implement IP-anycast for subnets of virtual
addresses.
Signed-off-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
>
>
>
>
> [root@ct503-60 ~]# ping 192.168.100.1
> PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
> 64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.257 ms
> 64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.285 ms
> \x03
> --- 192.168.100.1 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1290ms
> rtt min/avg/max/mdev = 0.257/0.271/0.285/0.014 ms
> [root@ct503-60 ~]# ifconfig
> eth0 Link encap:Ethernet HWaddr 00:30:48:DA:60:1C
> inet addr:192.168.100.173 Bcast:192.168.100.255 Mask:255.255.255.0
> inet6 addr: fe80::230:48ff:feda:601c/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:99 errors:0 dropped:0 overruns:0 frame:0
> TX packets:97 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:10562 (10.3 KiB) TX bytes:9634 (9.4 KiB)
> Memory:fa7e0000-fa800000
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> inet6 addr: ::1/128 Scope:Host
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:54 errors:0 dropped:0 overruns:0 frame:0
> TX packets:54 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:5280 (5.1 KiB) TX bytes:5280 (5.1 KiB)
>
> [root@ct503-60 ~]# ip rule add pref 512 lookup local
> local[root@ct503-60 ~]# ip rule del pref 0 lookup local
> [root@ct503-60 ~]# ping 192.168.100.1
> PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
> 64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.266 ms
> 64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.238 ms
> \x03
> --- 192.168.100.1 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1101ms
> rtt min/avg/max/mdev = 0.238/0.252/0.266/0.014 ms
> [root@ct503-60 ~]# ip link set eth2 up
> adcast 172.16.0.255 dev eth2Dec 10 11:50:01 localhost kernel: e1000e 0000:08:00.0: irq 49 for MSI/MSI-X
> Dec 10 11:50:01 localhost kernel: e1000e 0000:08:00.0: irq 49 for MSI/MSI-X
> Dec 10 11:50:01 localhost kernel: ADDRCONF(NETDEV_UP): eth2: link is not ready
> 2root@ct503-60 ~]# ping 192.168.100.1
> PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
> 64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.247 ms
> Dec 10 11:50:04 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
> Dec 10 11:50:04 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
> 64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.271 ms
> 64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=0.263 ms
> \x03
> --- 192.168.100.1 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2317ms
> rtt min/avg/max/mdev = 0.247/0.260/0.271/0.016 ms
> [root@ct503-60 ~]# ip rule add to 172.16.0.102 iif eth2 lookup local pref 10
> 001 pref 20[root@ct503-60 ~]# ip rule add iif eth2 lookup 10001 pref 20
> [root@ct503-60 ~]# ping 192.168.100.1
> PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
> 64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.346 ms
> Dec 10 11:50:14 localhost kernel: eth2: no IPv6 routers present
> 64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.251 ms
> \x03
> --- 192.168.100.1 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1245ms
> rtt min/avg/max/mdev = 0.251/0.298/0.346/0.050 ms
> [root@ct503-60 ~]# ip route add 172.16.0.0/24 dev eth2 table 10001
> 10001[root@ct503-60 ~]# ip route add unreachable 0/0 table 10001
> [root@ct503-60 ~]# ping 192.168.100.1
> connect: Invalid argument
> [root@ct503-60 ~]# ip route show
> 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.173
> 172.16.0.0/24 dev eth2 proto kernel scope link src 172.16.0.102
> 169.254.0.0/16 dev eth0 scope link metric 1003
> default via 192.168.100.1 dev eth0
> You have new mail in /var/spool/mail/root
> [root@ct503-60 ~]# ip route show table 10001
> 172.16.0.0/24 dev eth2 scope link
> unreachable default
> [root@ct503-60 ~]#
>
> [root@ct503-60 ~]# ip route flush table 10001
> [root@ct503-60 ~]# ping 192.168.100.1
> PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
> 64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=4.10 ms
> 64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.260 ms
> \x03
> --- 192.168.100.1 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1300ms
> rtt min/avg/max/mdev = 0.260/2.181/4.102/1.921 ms
> [root@ct503-60 ~]#
>
>
> Thanks,
> Ben
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2 3/4] kthread: NUMA aware kthread_create_on_cpu()
From: Eric Dumazet @ 2010-12-10 5:59 UTC (permalink / raw)
To: Andrew Morton
Cc: Andi Kleen, linux-kernel, netdev, David Miller, Tejun Heo,
Rusty Russell, Tony Luck, Fenghua Yu
In-Reply-To: <20101209164438.fae1ba4c.akpm@linux-foundation.org>
Le jeudi 09 décembre 2010 à 16:44 -0800, Andrew Morton a écrit :
> The name "kthread_create_on_cpu" is pretty misleading.
>
> One would expect such a function to create a kthread which is bound to
> that CPU. But what it in fact does is to create a kthread which is
> bound to all CPUs and whose stack, task_struct and thread_info were
> allocated from the node which contains `cpu'.
>
> Also, a saner interface would be one which takes the numa_node_id, not
> the cpu number.
>
> >
> > ...
> >
> > /**
> > - * kthread_create - create a kthread.
> > + * kthread_create_on_cpu - create a kthread.
> > * @threadfn: the function to run until signal_pending(current).
> > * @data: data ptr for @threadfn.
> > + * @cpu: cpu number.
> > * @namefmt: printf-style name for the thread.
> > *
> > * Description: This helper function creates and names a kernel
> > * thread. The thread will be stopped: use wake_up_process() to start
> > * it. See also kthread_run().
> > *
> > + * If thread is going to be bound on a particular cpu, give its number
> > + * in @cpu, to get NUMA affinity for kthread stack, or else give -1.
>
> This is a bit presumptuous. The caller might wish to later bind this
> thread to some or all of the CPUs on the node, rather than to a single
> CPU (eg, kswapd()).
>
>
> So what to do? Maybe add a new kthread_create_node() which prepares a
> kthread whose memory is bound to that node, then add a
> kthread_create_cpu() convenience wrapper around that?
>
We probably can add the "bind to cpu" as a fifth patch, to avoid one
kthread_bind(p, cpu); done by these callers.
My reasoning not including this kthread_bind(p, cpu) in initial patch
series that I was focusing on NUMA properties first, not on scheduling
(this part already runs correctly as far as I know)
Thanks for taking the patch series, I was about to resubmit it today :)
^ permalink raw reply
* Re: [PATCH 0/7] e1000e: cleanup
From: Kirsher, Jeffrey T @ 2010-12-10 5:20 UTC (permalink / raw)
To: asbjorn@asbjorn.biz
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1291862457-16671-1-git-send-email-asbjorn@asbjorn.biz>
[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]
On Thu, 2010-12-09 at 02:40 +0000, Asbjoern Sloth Toennesen wrote:
> Hi,
>
> This patchset fixes most checkstyle problems in e1000e.
>
> Checkpatch summary:
> pre: total: 221 errors, 129 warnings, 24520 lines checked
> post: total: 2 errors, 34 warnings, 24533 lines checked
>
> The two remaining errors are of the type "Macros with complex values
> should be enclosed in parenthesis", with macros containing 3 comma
> seperated values.
>
> The remaining warnings are all caused by <20ms msleep usage, that should
> be replaced with usleep_range calls.
>
> This patchset is based on top of jkirsher/net-next-2.6.git (67d5288)
>
> Asbjoern Sloth Toennesen (7):
> e1000e: cleanup: fix spacing issues
> e1000e: cleanup: fix bracket issues
> e1000e: cleanup: simplify E1000_ALL_* defines
> e1000e: cleanup: fix long lines
> e1000e: cleanup: fix space issues in ich8_* structs
> e1000e: cleanup: swap arguments to avoid checkpatch errors
> e1000e: cleanup: fix copyright notices to preferred style
>
> drivers/net/e1000e/82571.c | 70 +++++++-------
> drivers/net/e1000e/defines.h | 110 ++++++++++++-----------
> drivers/net/e1000e/e1000.h | 93 +++++++++++---------
> drivers/net/e1000e/es2lan.c | 135 ++++++++++++++--------------
> drivers/net/e1000e/ethtool.c | 75 ++++++++--------
> drivers/net/e1000e/hw.h | 56 ++++++------
> drivers/net/e1000e/ich8lan.c | 185 +++++++++++++++++++-------------------
> drivers/net/e1000e/lib.c | 78 ++++++++--------
> drivers/net/e1000e/netdev.c | 171 +++++++++++++++++------------------
> drivers/net/e1000e/param.c | 60 +++++++------
> drivers/net/e1000e/phy.c | 204 +++++++++++++++++++++---------------------
> 11 files changed, 625 insertions(+), 612 deletions(-)
>
> --
> 1.7.2.3
>
We already have patches queued up internally and are under validation
for the changes in patches 1 through 5 along along with other patches
for e1000e. These patches will be posted shortly.
Patch 6 should be fixed in checkpatch.pl and from Florian's response, it
sounds like the fix is already out there.
Patch 7 does not resolve any warnings in checkpatch.pl and there is no
impending need to make this change.
So I won't be applying this series of patches.
Cheers,
Jeff
[-- Attachment #2: Type: text/plain, Size: 79 bytes --]
------------------------------------------------------------------------------
[-- Attachment #3: Type: text/plain, Size: 257 bytes --]
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH net-next 4/4] bnx2x: Update version number and a date.
From: David Miller @ 2010-12-10 4:50 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong
In-Reply-To: <1291808617.30114.68.camel@lb-tlvb-vladz>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Wed, 8 Dec 2010 13:43:37 +0200
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 3/4] bnx2x: Fixed a compilation warning
From: David Miller @ 2010-12-10 4:50 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong
In-Reply-To: <1291808609.30114.67.camel@lb-tlvb-vladz>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Wed, 8 Dec 2010 13:43:29 +0200
> bnx2x_src_init_t2() is used only when BCM_CNIC is defined.
> So, to avoid a compilation warning, we won't define it unless
> BCM_CNIC is defined.
>
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/4] bnx2x: Use dma_alloc_coherent() semantics for ILT memory allocation
From: David Miller @ 2010-12-10 4:50 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong
In-Reply-To: <1291808598.30114.66.camel@lb-tlvb-vladz>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Wed, 8 Dec 2010 13:43:17 +0200
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/4] bnx2x: LSO code was broken on BE platforms
From: David Miller @ 2010-12-10 4:50 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong
In-Reply-To: <1291808589.30114.65.camel@lb-tlvb-vladz>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Wed, 8 Dec 2010 13:43:09 +0200
> Make the LSO code work on BE platforms: parsing_data field of
> a parsing BD (PBD) for 57712 was improperly composed which made FW read wrong
> values for TCP header's length and offset and, as a result, the corresponding
> PCI device was performing bad DMA reads triggering EEH.
>
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] filter: use size of fetched data in __load_pointer()
From: David Miller @ 2010-12-10 4:46 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1291796775.2883.21.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 08 Dec 2010 09:26:15 +0100
> __load_pointer() checks data we fetch from skb is included in head
> portion, but assumes we fetch one byte, instead of up to four.
>
> This wont crash because we have extra bytes (struct skb_shared_info)
> after head, but this can read uninitialized bytes.
>
> Fix this using size of the data (1, 2, 4 bytes) in the test.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
I'll apply this, thanks Eric.
^ 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