* [PATCH 14/15] ehea: Add GRO support
From: Thadeu Lima de Souza Cascardo @ 2011-10-14 15:31 UTC (permalink / raw)
To: netdev; +Cc: Anton Blanchard, Thadeu Lima de Souza Cascardo
In-Reply-To: <1318606272-27647-1-git-send-email-cascardo@linux.vnet.ibm.com>
From: Anton Blanchard <anton@samba.org>
Add GRO support to the ehea driver.
v3:
[cascardo] no need to enable GRO, since it's enabled by default
[cascardo] vgrp was removed in the vlan cleanup
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ehea/ehea_main.c | 15 +++++----------
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ehea/ehea_main.c b/drivers/net/ethernet/ibm/ehea/ehea_main.c
index 3b8e657..bfd08b2 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_main.c
+++ b/drivers/net/ethernet/ibm/ehea/ehea_main.c
@@ -647,15 +647,6 @@ static int ehea_treat_poll_error(struct ehea_port_res *pr, int rq,
return 0;
}
-static void ehea_proc_skb(struct ehea_port_res *pr, struct ehea_cqe *cqe,
- struct sk_buff *skb)
-{
- if (cqe->status & EHEA_CQE_VLAN_TAG_XTRACT)
- __vlan_hwaccel_put_tag(skb, cqe->vlan_tag);
-
- netif_receive_skb(skb);
-}
-
static int ehea_proc_rwqes(struct net_device *dev,
struct ehea_port_res *pr,
int budget)
@@ -732,7 +723,11 @@ static int ehea_proc_rwqes(struct net_device *dev,
}
processed_bytes += skb->len;
- ehea_proc_skb(pr, cqe, skb);
+
+ if (cqe->status & EHEA_CQE_VLAN_TAG_XTRACT)
+ __vlan_hwaccel_put_tag(skb, cqe->vlan_tag);
+
+ napi_gro_receive(&pr->napi, skb);
} else {
pr->p_stats.poll_receive_errors++;
port_reset = ehea_treat_poll_error(pr, rq, cqe,
--
1.7.4.4
^ permalink raw reply related
* [PATCH 13/15] ehea: Remove LRO support
From: Thadeu Lima de Souza Cascardo @ 2011-10-14 15:31 UTC (permalink / raw)
To: netdev; +Cc: Anton Blanchard, Thadeu Lima de Souza Cascardo
In-Reply-To: <1318606272-27647-1-git-send-email-cascardo@linux.vnet.ibm.com>
From: Anton Blanchard <anton@samba.org>
In preparation for adding GRO to ehea, remove LRO.
v3:
[cascardo] fixed conflict with vlan cleanup
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ehea/ehea.h | 7 ---
drivers/net/ethernet/ibm/ehea/ehea_ethtool.c | 16 -------
drivers/net/ethernet/ibm/ehea/ehea_main.c | 61 +-------------------------
3 files changed, 1 insertions(+), 83 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ehea/ehea.h b/drivers/net/ethernet/ibm/ehea/ehea.h
index c9dbe52..410d6a1 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea.h
+++ b/drivers/net/ethernet/ibm/ehea/ehea.h
@@ -33,7 +33,6 @@
#include <linux/ethtool.h>
#include <linux/vmalloc.h>
#include <linux/if_vlan.h>
-#include <linux/inet_lro.h>
#include <asm/ibmebus.h>
#include <asm/abs_addr.h>
@@ -58,7 +57,6 @@
#define EHEA_MIN_ENTRIES_QP 127
#define EHEA_SMALL_QUEUES
-#define EHEA_LRO_MAX_AGGR 64
#ifdef EHEA_SMALL_QUEUES
#define EHEA_MAX_CQE_COUNT 1023
@@ -85,8 +83,6 @@
#define EHEA_RQ2_PKT_SIZE 2048
#define EHEA_L_PKT_SIZE 256 /* low latency */
-#define MAX_LRO_DESCRIPTORS 8
-
/* Send completion signaling */
/* Protection Domain Identifier */
@@ -382,8 +378,6 @@ struct ehea_port_res {
u64 tx_bytes;
u64 rx_packets;
u64 rx_bytes;
- struct net_lro_mgr lro_mgr;
- struct net_lro_desc lro_desc[MAX_LRO_DESCRIPTORS];
int sq_restart_flag;
};
@@ -468,7 +462,6 @@ struct ehea_port {
u32 msg_enable;
u32 sig_comp_iv;
u32 state;
- u32 lro_max_aggr;
u8 phy_link;
u8 full_duplex;
u8 autoneg;
diff --git a/drivers/net/ethernet/ibm/ehea/ehea_ethtool.c b/drivers/net/ethernet/ibm/ehea/ehea_ethtool.c
index d185016..05b7359 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_ethtool.c
+++ b/drivers/net/ethernet/ibm/ehea/ehea_ethtool.c
@@ -205,9 +205,6 @@ static const char ehea_ethtool_stats_keys[][ETH_GSTRING_LEN] = {
{"PR13 free_swqes"},
{"PR14 free_swqes"},
{"PR15 free_swqes"},
- {"LRO aggregated"},
- {"LRO flushed"},
- {"LRO no_desc"},
};
static void ehea_get_strings(struct net_device *dev, u32 stringset, u8 *data)
@@ -264,19 +261,6 @@ static void ehea_get_ethtool_stats(struct net_device *dev,
for (k = 0; k < 16; k++)
data[i++] = atomic_read(&port->port_res[k].swqe_avail);
-
- for (k = 0, tmp = 0; k < EHEA_MAX_PORT_RES; k++)
- tmp |= port->port_res[k].lro_mgr.stats.aggregated;
- data[i++] = tmp;
-
- for (k = 0, tmp = 0; k < EHEA_MAX_PORT_RES; k++)
- tmp |= port->port_res[k].lro_mgr.stats.flushed;
- data[i++] = tmp;
-
- for (k = 0, tmp = 0; k < EHEA_MAX_PORT_RES; k++)
- tmp |= port->port_res[k].lro_mgr.stats.no_desc;
- data[i++] = tmp;
-
}
const struct ethtool_ops ehea_ethtool_ops = {
diff --git a/drivers/net/ethernet/ibm/ehea/ehea_main.c b/drivers/net/ethernet/ibm/ehea/ehea_main.c
index a0a3c5f..3b8e657 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_main.c
+++ b/drivers/net/ethernet/ibm/ehea/ehea_main.c
@@ -62,8 +62,6 @@ static int rq2_entries = EHEA_DEF_ENTRIES_RQ2;
static int rq3_entries = EHEA_DEF_ENTRIES_RQ3;
static int sq_entries = EHEA_DEF_ENTRIES_SQ;
static int use_mcs = 1;
-static int use_lro;
-static int lro_max_aggr = EHEA_LRO_MAX_AGGR;
static int prop_carrier_state;
module_param(msg_level, int, 0);
@@ -73,8 +71,6 @@ module_param(rq3_entries, int, 0);
module_param(sq_entries, int, 0);
module_param(prop_carrier_state, int, 0);
module_param(use_mcs, int, 0);
-module_param(use_lro, int, 0);
-module_param(lro_max_aggr, int, 0);
MODULE_PARM_DESC(msg_level, "msg_level");
MODULE_PARM_DESC(prop_carrier_state, "Propagate carrier state of physical "
@@ -94,11 +90,6 @@ MODULE_PARM_DESC(sq_entries, " Number of entries for the Send Queue "
MODULE_PARM_DESC(use_mcs, " Multiple receive queues, 1: enable, 0: disable, "
"Default = 1");
-MODULE_PARM_DESC(lro_max_aggr, " LRO: Max packets to be aggregated. Default = "
- __MODULE_STRING(EHEA_LRO_MAX_AGGR));
-MODULE_PARM_DESC(use_lro, " Large Receive Offload, 1: enable, 0: disable, "
- "Default = 0");
-
static int port_name_cnt;
static LIST_HEAD(adapter_list);
static unsigned long ehea_driver_flags;
@@ -656,47 +647,13 @@ static int ehea_treat_poll_error(struct ehea_port_res *pr, int rq,
return 0;
}
-static int get_skb_hdr(struct sk_buff *skb, void **iphdr,
- void **tcph, u64 *hdr_flags, void *priv)
-{
- struct ehea_cqe *cqe = priv;
- unsigned int ip_len;
- struct iphdr *iph;
-
- /* non tcp/udp packets */
- if (!cqe->header_length)
- return -1;
-
- /* non tcp packet */
- skb_reset_network_header(skb);
- iph = ip_hdr(skb);
- if (iph->protocol != IPPROTO_TCP)
- return -1;
-
- ip_len = ip_hdrlen(skb);
- skb_set_transport_header(skb, ip_len);
- *tcph = tcp_hdr(skb);
-
- /* check if ip header and tcp header are complete */
- if (ntohs(iph->tot_len) < ip_len + tcp_hdrlen(skb))
- return -1;
-
- *hdr_flags = LRO_IPV4 | LRO_TCP;
- *iphdr = iph;
-
- return 0;
-}
-
static void ehea_proc_skb(struct ehea_port_res *pr, struct ehea_cqe *cqe,
struct sk_buff *skb)
{
if (cqe->status & EHEA_CQE_VLAN_TAG_XTRACT)
__vlan_hwaccel_put_tag(skb, cqe->vlan_tag);
- if (skb->dev->features & NETIF_F_LRO)
- lro_receive_skb(&pr->lro_mgr, skb, cqe);
- else
- netif_receive_skb(skb);
+ netif_receive_skb(skb);
}
static int ehea_proc_rwqes(struct net_device *dev,
@@ -786,8 +743,6 @@ static int ehea_proc_rwqes(struct net_device *dev,
}
cqe = ehea_poll_rq1(qp, &wqe_index);
}
- if (dev->features & NETIF_F_LRO)
- lro_flush_all(&pr->lro_mgr);
pr->rx_packets += processed;
pr->rx_bytes += processed_bytes;
@@ -1611,15 +1566,6 @@ static int ehea_init_port_res(struct ehea_port *port, struct ehea_port_res *pr,
netif_napi_add(pr->port->netdev, &pr->napi, ehea_poll, 64);
- pr->lro_mgr.max_aggr = pr->port->lro_max_aggr;
- pr->lro_mgr.max_desc = MAX_LRO_DESCRIPTORS;
- pr->lro_mgr.lro_arr = pr->lro_desc;
- pr->lro_mgr.get_skb_header = get_skb_hdr;
- pr->lro_mgr.features = LRO_F_NAPI | LRO_F_EXTRACT_VLAN_ID;
- pr->lro_mgr.dev = port->netdev;
- pr->lro_mgr.ip_summed = CHECKSUM_UNNECESSARY;
- pr->lro_mgr.ip_summed_aggr = CHECKSUM_UNNECESSARY;
-
ret = 0;
goto out;
@@ -3082,9 +3028,6 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
NETIF_F_IP_CSUM;
dev->watchdog_timeo = EHEA_WATCH_DOG_TIMEOUT;
- if (use_lro)
- dev->features |= NETIF_F_LRO;
-
INIT_WORK(&port->reset_task, ehea_reset_port);
INIT_DELAYED_WORK(&port->stats_work, ehea_update_stats);
@@ -3098,8 +3041,6 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
goto out_unreg_port;
}
- port->lro_max_aggr = lro_max_aggr;
-
ret = ehea_get_jumboframe_status(port, &jumbo);
if (ret)
netdev_err(dev, "failed determining jumbo frame status\n");
--
1.7.4.4
^ permalink raw reply related
* [PATCH 11/15] ehea: Remove some unused definitions
From: Thadeu Lima de Souza Cascardo @ 2011-10-14 15:31 UTC (permalink / raw)
To: netdev; +Cc: Anton Blanchard, Thadeu Lima de Souza Cascardo
In-Reply-To: <1318606272-27647-1-git-send-email-cascardo@linux.vnet.ibm.com>
From: Anton Blanchard <anton@samba.org>
The queue macros are many levels deep and it makes it harder to
work your way through them when many of the versions are unused.
Remove the unused versions.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ehea/ehea_hw.h | 25 -------------------------
1 files changed, 0 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ehea/ehea_hw.h b/drivers/net/ethernet/ibm/ehea/ehea_hw.h
index 567981b..1a2fe4d 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_hw.h
+++ b/drivers/net/ethernet/ibm/ehea/ehea_hw.h
@@ -210,36 +210,11 @@ static inline void epa_store_acc(struct h_epa epa, u32 offset, u64 value)
__raw_writeq(value, (void __iomem *)(epa.addr + offset));
}
-#define epa_store_eq(epa, offset, value)\
- epa_store(epa, EQTEMM_OFFSET(offset), value)
-#define epa_load_eq(epa, offset)\
- epa_load(epa, EQTEMM_OFFSET(offset))
-
#define epa_store_cq(epa, offset, value)\
epa_store(epa, CQTEMM_OFFSET(offset), value)
#define epa_load_cq(epa, offset)\
epa_load(epa, CQTEMM_OFFSET(offset))
-#define epa_store_qp(epa, offset, value)\
- epa_store(epa, QPTEMM_OFFSET(offset), value)
-#define epa_load_qp(epa, offset)\
- epa_load(epa, QPTEMM_OFFSET(offset))
-
-#define epa_store_qped(epa, offset, value)\
- epa_store(epa, QPEDMM_OFFSET(offset), value)
-#define epa_load_qped(epa, offset)\
- epa_load(epa, QPEDMM_OFFSET(offset))
-
-#define epa_store_mrmw(epa, offset, value)\
- epa_store(epa, MRMWMM_OFFSET(offset), value)
-#define epa_load_mrmw(epa, offset)\
- epa_load(epa, MRMWMM_OFFSET(offset))
-
-#define epa_store_base(epa, offset, value)\
- epa_store(epa, HCAGR_OFFSET(offset), value)
-#define epa_load_base(epa, offset)\
- epa_load(epa, HCAGR_OFFSET(offset))
-
static inline void ehea_update_sqa(struct ehea_qp *qp, u16 nr_wqes)
{
struct h_epa epa = qp->epas.kernel;
--
1.7.4.4
^ permalink raw reply related
* [PATCH 15/15] ehea: Remove unused tcp_end field in send WQ
From: Thadeu Lima de Souza Cascardo @ 2011-10-14 15:31 UTC (permalink / raw)
To: netdev; +Cc: Anton Blanchard, Thadeu Lima de Souza Cascardo
In-Reply-To: <1318606272-27647-1-git-send-email-cascardo@linux.vnet.ibm.com>
From: Anton Blanchard <anton@samba.org>
The tcp_end field is not actually used by the hardware, so there
is no need to set it.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ehea/ehea_main.c | 2 --
drivers/net/ethernet/ibm/ehea/ehea_qmr.h | 2 +-
2 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ehea/ehea_main.c b/drivers/net/ethernet/ibm/ehea/ehea_main.c
index bfd08b2..adb462d 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_main.c
+++ b/drivers/net/ethernet/ibm/ehea/ehea_main.c
@@ -2001,7 +2001,6 @@ static void xmit_common(struct sk_buff *skb, struct ehea_swqe *swqe)
swqe->tcp_offset = swqe->ip_end + 1 +
offsetof(struct udphdr, check);
- swqe->tcp_end = skb->len - 1;
break;
case IPPROTO_TCP:
@@ -2010,7 +2009,6 @@ static void xmit_common(struct sk_buff *skb, struct ehea_swqe *swqe)
swqe->tcp_offset = swqe->ip_end + 1 +
offsetof(struct tcphdr, check);
- swqe->tcp_end = skb->len - 1;
break;
}
}
diff --git a/drivers/net/ethernet/ibm/ehea/ehea_qmr.h b/drivers/net/ethernet/ibm/ehea/ehea_qmr.h
index fddff8e..337a47e 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_qmr.h
+++ b/drivers/net/ethernet/ibm/ehea/ehea_qmr.h
@@ -107,7 +107,7 @@ struct ehea_swqe {
u8 immediate_data_length;
u8 tcp_offset;
u8 reserved2;
- u16 tcp_end;
+ u16 reserved2b;
u8 wrap_tag;
u8 descriptors; /* number of valid descriptors in WQE */
u16 reserved3;
--
1.7.4.4
^ permalink raw reply related
* [PATCH 12/15] ehea: Add 64bit statistics
From: Thadeu Lima de Souza Cascardo @ 2011-10-14 15:31 UTC (permalink / raw)
To: netdev; +Cc: Anton Blanchard, Thadeu Lima de Souza Cascardo
In-Reply-To: <1318606272-27647-1-git-send-email-cascardo@linux.vnet.ibm.com>
From: Anton Blanchard <anton@samba.org>
Switch to using ndo_get_stats64 to get 64bit statistics.
v3:
[cascardo] use rtnl_link_stats64 as port stats
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ehea/ehea.h | 2 +-
drivers/net/ethernet/ibm/ehea/ehea_main.c | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ehea/ehea.h b/drivers/net/ethernet/ibm/ehea/ehea.h
index 7aa47d8..c9dbe52 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea.h
+++ b/drivers/net/ethernet/ibm/ehea/ehea.h
@@ -448,7 +448,7 @@ struct ehea_bcmc_reg_array {
struct ehea_port {
struct ehea_adapter *adapter; /* adapter that owns this port */
struct net_device *netdev;
- struct net_device_stats stats;
+ struct rtnl_link_stats64 stats;
struct ehea_port_res port_res[EHEA_MAX_PORT_RES];
struct platform_device ofdev; /* Open Firmware Device */
struct ehea_mc_list *mc_list; /* Multicast MAC addresses */
diff --git a/drivers/net/ethernet/ibm/ehea/ehea_main.c b/drivers/net/ethernet/ibm/ehea/ehea_main.c
index 289ad4d..a0a3c5f 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_main.c
+++ b/drivers/net/ethernet/ibm/ehea/ehea_main.c
@@ -323,10 +323,10 @@ out:
spin_unlock_irqrestore(&ehea_bcmc_regs.lock, flags);
}
-static struct net_device_stats *ehea_get_stats(struct net_device *dev)
+static struct rtnl_link_stats64 *ehea_get_stats64(struct net_device *dev,
+ struct rtnl_link_stats64 *stats)
{
struct ehea_port *port = netdev_priv(dev);
- struct net_device_stats *stats = &port->stats;
u64 rx_packets = 0, tx_packets = 0, rx_bytes = 0, tx_bytes = 0;
int i;
@@ -353,7 +353,7 @@ static void ehea_update_stats(struct work_struct *work)
struct ehea_port *port =
container_of(work, struct ehea_port, stats_work.work);
struct net_device *dev = port->netdev;
- struct net_device_stats *stats = &port->stats;
+ struct rtnl_link_stats64 *stats = &port->stats;
struct hcp_ehea_port_cb2 *cb2;
u64 hret;
@@ -3004,7 +3004,7 @@ static const struct net_device_ops ehea_netdev_ops = {
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = ehea_netpoll,
#endif
- .ndo_get_stats = ehea_get_stats,
+ .ndo_get_stats64 = ehea_get_stats64,
.ndo_set_mac_address = ehea_set_mac_addr,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_rx_mode = ehea_set_multicast_list,
--
1.7.4.4
^ permalink raw reply related
* [PATCH 05/15] ehea: Dont check NETIF_F_TSO in TX path
From: Thadeu Lima de Souza Cascardo @ 2011-10-14 15:31 UTC (permalink / raw)
To: netdev; +Cc: Anton Blanchard, Thadeu Lima de Souza Cascardo
In-Reply-To: <1318606272-27647-1-git-send-email-cascardo@linux.vnet.ibm.com>
From: Anton Blanchard <anton@samba.org>
It seems like the ehea xmit routine and an ethtool change of TSO
mode could race, resulting in corrupt packets. Checking gso_size
is enough and we can use the helper function.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ehea/ehea_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ehea/ehea_main.c b/drivers/net/ethernet/ibm/ehea/ehea_main.c
index 6ded42a..0cb3a9b 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_main.c
+++ b/drivers/net/ethernet/ibm/ehea/ehea_main.c
@@ -1787,7 +1787,7 @@ static inline void write_swqe2_data(struct sk_buff *skb, struct net_device *dev,
swqe->descriptors = 0;
sg1entry_contains_frag_data = 0;
- if ((dev->features & NETIF_F_TSO) && skb_shinfo(skb)->gso_size)
+ if (skb_is_gso(skb))
write_swqe2_TSO(skb, swqe, lkey);
else
write_swqe2_nonTSO(skb, swqe, lkey);
--
1.7.4.4
^ permalink raw reply related
* [PATCH 08/15] ehea: Simplify ehea_xmit2 and ehea_xmit3
From: Thadeu Lima de Souza Cascardo @ 2011-10-14 15:31 UTC (permalink / raw)
To: netdev; +Cc: Anton Blanchard, Thadeu Lima de Souza Cascardo
In-Reply-To: <1318606272-27647-1-git-send-email-cascardo@linux.vnet.ibm.com>
From: Anton Blanchard <anton@samba.org>
Based on a patch from Michael Ellerman, clean up a significant
portion of the transmit path. There was a lot of duplication here.
Even worse, we were always checksumming tx packets and ignoring the
skb->ip_summed field.
Also remove NETIF_F_FRAGLIST from dev->features, I'm not sure why
it was enabled.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ehea/ehea_main.c | 137 ++++++++---------------------
1 files changed, 36 insertions(+), 101 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ehea/ehea_main.c b/drivers/net/ethernet/ibm/ehea/ehea_main.c
index 1321809..77aafba 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_main.c
+++ b/drivers/net/ethernet/ibm/ehea/ehea_main.c
@@ -1676,37 +1676,6 @@ static int ehea_clean_portres(struct ehea_port *port, struct ehea_port_res *pr)
return ret;
}
-/*
- * The write_* functions store information in swqe which is used by
- * the hardware to calculate the ip/tcp/udp checksum
- */
-
-static inline void write_ip_start_end(struct ehea_swqe *swqe,
- const struct sk_buff *skb)
-{
- swqe->ip_start = skb_network_offset(skb);
- swqe->ip_end = (u8)(swqe->ip_start + ip_hdrlen(skb) - 1);
-}
-
-static inline void write_tcp_offset_end(struct ehea_swqe *swqe,
- const struct sk_buff *skb)
-{
- swqe->tcp_offset =
- (u8)(swqe->ip_end + 1 + offsetof(struct tcphdr, check));
-
- swqe->tcp_end = (u16)skb->len - 1;
-}
-
-static inline void write_udp_offset_end(struct ehea_swqe *swqe,
- const struct sk_buff *skb)
-{
- swqe->tcp_offset =
- (u8)(swqe->ip_end + 1 + offsetof(struct udphdr, check));
-
- swqe->tcp_end = (u16)skb->len - 1;
-}
-
-
static void write_swqe2_TSO(struct sk_buff *skb,
struct ehea_swqe *swqe, u32 lkey)
{
@@ -2105,41 +2074,46 @@ static int ehea_change_mtu(struct net_device *dev, int new_mtu)
return 0;
}
-static void ehea_xmit2(struct sk_buff *skb, struct net_device *dev,
- struct ehea_swqe *swqe, u32 lkey)
+static void xmit_common(struct sk_buff *skb, struct ehea_swqe *swqe)
{
- if (skb->protocol == htons(ETH_P_IP)) {
- const struct iphdr *iph = ip_hdr(skb);
+ swqe->tx_control |= EHEA_SWQE_IMM_DATA_PRESENT | EHEA_SWQE_CRC;
- /* IPv4 */
- swqe->tx_control |= EHEA_SWQE_CRC
- | EHEA_SWQE_IP_CHECKSUM
- | EHEA_SWQE_TCP_CHECKSUM
- | EHEA_SWQE_IMM_DATA_PRESENT
- | EHEA_SWQE_DESCRIPTORS_PRESENT;
+ if (skb->protocol != htons(ETH_P_IP))
+ return;
- write_ip_start_end(swqe, skb);
+ if (skb->ip_summed == CHECKSUM_PARTIAL)
+ swqe->tx_control |= EHEA_SWQE_IP_CHECKSUM;
- if (iph->protocol == IPPROTO_UDP) {
- if ((iph->frag_off & IP_MF) ||
- (iph->frag_off & IP_OFFSET))
- /* IP fragment, so don't change cs */
- swqe->tx_control &= ~EHEA_SWQE_TCP_CHECKSUM;
- else
- write_udp_offset_end(swqe, skb);
- } else if (iph->protocol == IPPROTO_TCP) {
- write_tcp_offset_end(swqe, skb);
- }
+ swqe->ip_start = skb_network_offset(skb);
+ swqe->ip_end = swqe->ip_start + ip_hdrlen(skb) - 1;
- /* icmp (big data) and ip segmentation packets (all other ip
- packets) do not require any special handling */
+ switch (ip_hdr(skb)->protocol) {
+ case IPPROTO_UDP:
+ if (skb->ip_summed == CHECKSUM_PARTIAL)
+ swqe->tx_control |= EHEA_SWQE_TCP_CHECKSUM;
- } else {
- /* Other Ethernet Protocol */
- swqe->tx_control |= EHEA_SWQE_CRC
- | EHEA_SWQE_IMM_DATA_PRESENT
- | EHEA_SWQE_DESCRIPTORS_PRESENT;
+ swqe->tcp_offset = swqe->ip_end + 1 +
+ offsetof(struct udphdr, check);
+ swqe->tcp_end = skb->len - 1;
+ break;
+
+ case IPPROTO_TCP:
+ if (skb->ip_summed == CHECKSUM_PARTIAL)
+ swqe->tx_control |= EHEA_SWQE_TCP_CHECKSUM;
+
+ swqe->tcp_offset = swqe->ip_end + 1 +
+ offsetof(struct tcphdr, check);
+ swqe->tcp_end = skb->len - 1;
+ break;
}
+}
+
+static void ehea_xmit2(struct sk_buff *skb, struct net_device *dev,
+ struct ehea_swqe *swqe, u32 lkey)
+{
+ swqe->tx_control |= EHEA_SWQE_DESCRIPTORS_PRESENT;
+
+ xmit_common(skb, swqe);
write_swqe2_data(skb, dev, swqe, lkey);
}
@@ -2152,51 +2126,11 @@ static void ehea_xmit3(struct sk_buff *skb, struct net_device *dev,
skb_frag_t *frag;
int i;
- if (skb->protocol == htons(ETH_P_IP)) {
- const struct iphdr *iph = ip_hdr(skb);
+ xmit_common(skb, swqe);
- /* IPv4 */
- write_ip_start_end(swqe, skb);
-
- if (iph->protocol == IPPROTO_TCP) {
- swqe->tx_control |= EHEA_SWQE_CRC
- | EHEA_SWQE_IP_CHECKSUM
- | EHEA_SWQE_TCP_CHECKSUM
- | EHEA_SWQE_IMM_DATA_PRESENT;
-
- write_tcp_offset_end(swqe, skb);
-
- } else if (iph->protocol == IPPROTO_UDP) {
- if ((iph->frag_off & IP_MF) ||
- (iph->frag_off & IP_OFFSET))
- /* IP fragment, so don't change cs */
- swqe->tx_control |= EHEA_SWQE_CRC
- | EHEA_SWQE_IMM_DATA_PRESENT;
- else {
- swqe->tx_control |= EHEA_SWQE_CRC
- | EHEA_SWQE_IP_CHECKSUM
- | EHEA_SWQE_TCP_CHECKSUM
- | EHEA_SWQE_IMM_DATA_PRESENT;
-
- write_udp_offset_end(swqe, skb);
- }
- } else {
- /* icmp (big data) and
- ip segmentation packets (all other ip packets) */
- swqe->tx_control |= EHEA_SWQE_CRC
- | EHEA_SWQE_IP_CHECKSUM
- | EHEA_SWQE_IMM_DATA_PRESENT;
- }
- } else {
- /* Other Ethernet Protocol */
- swqe->tx_control |= EHEA_SWQE_CRC | EHEA_SWQE_IMM_DATA_PRESENT;
- }
- /* copy (immediate) data */
if (nfrags == 0) {
- /* data is in a single piece */
skb_copy_from_linear_data(skb, imm_data, skb->len);
} else {
- /* first copy data from the skb->data buffer ... */
skb_copy_from_linear_data(skb, imm_data,
skb_headlen(skb));
imm_data += skb_headlen(skb);
@@ -2208,6 +2142,7 @@ static void ehea_xmit3(struct sk_buff *skb, struct net_device *dev,
imm_data += frag->size;
}
}
+
swqe->immediate_data_length = skb->len;
dev_kfree_skb(skb);
}
@@ -3184,7 +3119,7 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
dev->netdev_ops = &ehea_netdev_ops;
ehea_set_ethtool_ops(dev);
- dev->hw_features = NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_TSO
+ dev->hw_features = NETIF_F_SG | NETIF_F_TSO
| NETIF_F_IP_CSUM | NETIF_F_HW_VLAN_TX | NETIF_F_LRO;
dev->features = NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_TSO
| NETIF_F_HIGHDMA | NETIF_F_IP_CSUM | NETIF_F_HW_VLAN_TX
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH net-next] bnx2x: Disable LRO on FCoE or iSCSI boot device
From: Rick Jones @ 2011-10-14 15:31 UTC (permalink / raw)
To: Michael Chan; +Cc: davem, netdev, dmitry, eilong
In-Reply-To: <1318563481-19631-1-git-send-email-mchan@broadcom.com>
On 10/13/2011 08:38 PM, Michael Chan wrote:
> From: Dmitry Kravkov<dmitry@broadcom.com>
>
> For an FCoE or iSCSI boot device, the networking side must stay "up" all
> the time. Otherwise, the FCoE/iSCSI interface driven by bnx2i/bnx2fc
> will be reset and we'll lose the root file system.
>
> If LRO is enabled, scripts that enable IP forwarding or bridging will
> disable LRO and cause the device to be reset. Disabling LRO on these
> boot devices will prevent the reset.
Is this perhaps saying that a bnx2x-driven device being used for FCoE or
iSCSI boot must not permit *any* run-time configuration change which
leads to a NIC reset?
rick jones
^ permalink raw reply
* [PATCH 10/15] ehea: Simplify type 3 transmit routine
From: Thadeu Lima de Souza Cascardo @ 2011-10-14 15:31 UTC (permalink / raw)
To: netdev; +Cc: Anton Blanchard, Thadeu Lima de Souza Cascardo
In-Reply-To: <1318606272-27647-1-git-send-email-cascardo@linux.vnet.ibm.com>
From: Anton Blanchard <anton@samba.org>
If a nonlinear skb fits within the immediate area, use skb_copy_bits
instead of copying the frags by hand.
v3:
[cascardo] fixed conflict with use of skb frag API
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ehea/ehea_main.c | 19 +++----------------
1 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ehea/ehea_main.c b/drivers/net/ethernet/ibm/ehea/ehea_main.c
index 0fc0ae8..289ad4d 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_main.c
+++ b/drivers/net/ethernet/ibm/ehea/ehea_main.c
@@ -2087,27 +2087,14 @@ static void ehea_xmit2(struct sk_buff *skb, struct net_device *dev,
static void ehea_xmit3(struct sk_buff *skb, struct net_device *dev,
struct ehea_swqe *swqe)
{
- int nfrags = skb_shinfo(skb)->nr_frags;
u8 *imm_data = &swqe->u.immdata_nodesc.immediate_data[0];
- skb_frag_t *frag;
- int i;
xmit_common(skb, swqe);
- if (nfrags == 0) {
+ if (!skb->data_len)
skb_copy_from_linear_data(skb, imm_data, skb->len);
- } else {
- skb_copy_from_linear_data(skb, imm_data,
- skb_headlen(skb));
- imm_data += skb_headlen(skb);
-
- /* ... then copy data from the fragments */
- for (i = 0; i < nfrags; i++) {
- frag = &skb_shinfo(skb)->frags[i];
- memcpy(imm_data, skb_frag_address(frag), frag->size);
- imm_data += frag->size;
- }
- }
+ else
+ skb_copy_bits(skb, 0, imm_data, skb->len);
swqe->immediate_data_length = skb->len;
dev_kfree_skb(skb);
--
1.7.4.4
^ permalink raw reply related
* Re: iwlagn: WARN_ON() in iwl_get_idle_rx_chain_count()
From: wwguy @ 2011-10-14 15:29 UTC (permalink / raw)
To: Michał Mirosław
Cc: Intel Linux Wireless, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20111014150219.GA20672@rere.qmqm.pl>
[-- Attachment #1: Type: text/plain, Size: 23360 bytes --]
Hi Michal,
Could you try the attach patch and see if it fix your problem.
Thanks
Wey
On Fri, 2011-10-14 at 08:02 -0700, Michał Mirosław wrote:
> WARN_ON() in iwl_get_idle_rx_chain_count() gets triggered on system shutdown
> when WiFi card is associated to an AP. This is on kernel built from
> Linus' tree, commit 37cf95162af4036b4198756a590aab8126fa2ce4 (3.1.0-rc9+).
> It looks HT-related, I can't reproduce this on 802.11g network.
>
> Best Regards,
> Michał Mirosław
>
>
> 09:00.0 Network controller: Intel Corporation Centrino Wireless-N 1030 (rev 34)
> Subsystem: Intel Corporation Centrino Wireless-N 1030 BGN
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 52
> Region 0: Memory at f7a00000 (64-bit, non-prefetchable) [size=8K]
> Capabilities: <access denied>
> Kernel driver in use: iwlagn
>
> Oct 14 00:04:26 oko kernel: [ 2796.354030] ------------[ cut here ]------------
> Oct 14 00:04:26 oko kernel: [ 2796.354996] WARNING: at /usr/src/linux-git/drivers/net/wireless/iwlwifi/iwl-agn-lib.c:1766 iwlagn_set_rxon_chain+0x107/0x1b2 [iwlagn]()
> Oct 14 00:04:26 oko kernel: [ 2796.355955] Hardware name: Vostro 3350
> Oct 14 00:04:26 oko kernel: [ 2796.356906] invalid SMPS mode 0
> Oct 14 00:04:26 oko kernel: [ 2796.356920] Modules linked in: acpi_cpufreq mperf cpufreq_conservative autofs4 rfcomm cpufreq_stats bnep cpufreq_powersave cpufreq_userspace pci_stub binfmt_misc microcode uinput nfs lockd auth_rpcgss nfs_acl sunrpc ext2 coretemp loop kvm_intel kvm aesni_intel cryptd aes_x86_64 aes_generic ecb btusb radeon bluetooth uvcvideo usb_storage videodev arc4 media uas iwlagn v4l2_compat_ioctl32 i915 crc16 snd_hda_codec_idt ttm drm_kms_helper mac80211 drm snd_hda_intel snd_hda_codec ehci_hcd snd_hwdep xhci_hcd snd_pcm snd_seq usbcore joydev sg cfg80211 snd_timer sr_mod snd_seq_device snd r8169 psmouse dell_wmi cdrom dell_laptop soundcore i2c_algo_bit pcspkr evdev sparse_keymap processor snd_page_alloc video cfbcopyarea mii dcdbas button cfbimgblt cfbfillrect wmi ac
battery ext3 jbd mbcache dm_mod sd_mod crc_t10dif ahci libahci libata scsi_mod thermal thermal_sys [last unloaded: vboxdrv]
> Oct 14 00:04:26 oko kernel: [ 2796.365031] Pid: 3017, comm: wpa_supplicant Not tainted 3.1.0-rc9+ #12
> Oct 14 00:04:26 oko kernel: [ 2796.366263] Call Trace:
> Oct 14 00:04:26 oko kernel: [ 2796.367490] [<ffffffff8103437f>] ? warn_slowpath_common+0x78/0x8c
> Oct 14 00:04:26 oko kernel: [ 2796.368673] [<ffffffff8103442b>] ? warn_slowpath_fmt+0x45/0x4a
> Oct 14 00:04:26 oko kernel: [ 2796.369836] [<ffffffffa0310733>] ? __sta_info_destroy+0x267/0x2af [mac80211]
> Oct 14 00:04:26 oko kernel: [ 2796.371046] [<ffffffffa03a93f1>] ? iwlagn_set_rxon_chain+0x107/0x1b2 [iwlagn]
> Oct 14 00:04:26 oko kernel: [ 2796.372274] [<ffffffffa03b2f9e>] ? iwlagn_bss_info_changed+0x245/0x4b3 [iwlagn]
> Oct 14 00:04:26 oko kernel: [ 2796.373753] [<ffffffff8102c1e5>] ? get_parent_ip+0x9/0x1b
> Oct 14 00:04:26 oko kernel: [ 2796.374990] [<ffffffffa031c03a>] ? __ieee80211_recalc_idle+0xef/0x194 [mac80211]
> Oct 14 00:04:26 oko kernel: [ 2796.376272] [<ffffffffa031cbee>] ? ieee80211_recalc_idle+0x1e/0x42 [mac80211]
> Oct 14 00:04:26 oko kernel: [ 2796.377506] [<ffffffffa0319690>] ? ieee80211_mgd_deauth+0x19c/0x1c0 [mac80211]
> Oct 14 00:04:26 oko kernel: [ 2796.378771] [<ffffffff812e96ed>] ? sub_preempt_count+0x83/0x94
> Oct 14 00:04:26 oko kernel: [ 2796.380083] [<ffffffffa01ca76c>] ? __cfg80211_mlme_deauth+0x107/0x116 [cfg80211]
> Oct 14 00:04:26 oko kernel: [ 2796.381293] [<ffffffff812e64d9>] ? schedule_hrtimeout_range_clock+0xc8/0x103
> Oct 14 00:04:26 oko kernel: [ 2796.382550] [<ffffffff8102c1e5>] ? get_parent_ip+0x9/0x1b
> Oct 14 00:04:26 oko kernel: [ 2796.383803] [<ffffffffa01ca7e4>] ? cfg80211_mlme_deauth+0x69/0x82 [cfg80211]
> Oct 14 00:04:26 oko kernel: [ 2796.385039] [<ffffffff81023735>] ? __wake_up_common+0x40/0x77
> Oct 14 00:04:26 oko kernel: [ 2796.386309] [<ffffffffa01c15ed>] ? nl80211_deauthenticate+0xbc/0xc7 [cfg80211]
> Oct 14 00:04:26 oko kernel: [ 2796.387607] [<ffffffffa01c35cb>] ? nl80211_pre_doit+0x85/0xfb [cfg80211]
> Oct 14 00:04:26 oko kernel: [ 2796.389171] [<ffffffff81250f71>] ? genl_rcv_msg+0x1cb/0x1f9
> Oct 14 00:04:26 oko kernel: [ 2796.390753] [<ffffffff81250da6>] ? genl_rcv+0x28/0x28
> Oct 14 00:04:26 oko kernel: [ 2796.392295] [<ffffffff81250a06>] ? netlink_rcv_skb+0x36/0x7a
> Oct 14 00:04:26 oko kernel: [ 2796.393896] [<ffffffff81250d9d>] ? genl_rcv+0x1f/0x28
> Oct 14 00:04:26 oko kernel: [ 2796.395521] [<ffffffff81250537>] ? netlink_unicast+0xe6/0x14e
> Oct 14 00:04:26 oko kernel: [ 2796.397095] [<ffffffff81250819>] ? netlink_sendmsg+0x27a/0x2b2
> Oct 14 00:04:26 oko kernel: [ 2796.398741] [<ffffffff810f45dc>] ? __pollwait+0xce/0xce
> Oct 14 00:04:26 oko kernel: [ 2796.400378] [<ffffffff8122172d>] ? sock_sendmsg+0xc1/0xde
> Oct 14 00:04:26 oko kernel: [ 2796.402042] [<ffffffff8122160e>] ? sock_recvmsg+0xcd/0xec
> Oct 14 00:04:26 oko kernel: [ 2796.403645] [<ffffffff8102c1e5>] ? get_parent_ip+0x9/0x1b
> Oct 14 00:04:26 oko kernel: [ 2796.405148] [<ffffffff8122160e>] ? sock_recvmsg+0xcd/0xec
> Oct 14 00:04:26 oko kernel: [ 2796.406650] [<ffffffff812228d4>] ? move_addr_to_kernel+0x24/0x46
> Oct 14 00:04:26 oko kernel: [ 2796.408098] [<ffffffff812219c5>] ? __sys_sendmsg+0x1e8/0x288
> Oct 14 00:04:26 oko kernel: [ 2796.408102] [<ffffffff812e9798>] ? add_preempt_count+0x9a/0x9c
> Oct 14 00:04:26 oko kernel: [ 2796.408107] [<ffffffff8102c1e5>] ? get_parent_ip+0x9/0x1b
> Oct 14 00:04:26 oko kernel: [ 2796.408109] [<ffffffff812e96ed>] ? sub_preempt_count+0x83/0x94
> Oct 14 00:04:26 oko kernel: [ 2796.408112] [<ffffffff812e6f14>] ? _raw_spin_unlock_irq+0x23/0x2f
> Oct 14 00:04:26 oko kernel: [ 2796.408115] [<ffffffff810022e1>] ? do_signal+0x51d/0x5f3
> Oct 14 00:04:26 oko kernel: [ 2796.408119] [<ffffffff81008f1b>] ? init_fpu+0x72/0x7f
> Oct 14 00:04:26 oko kernel: [ 2796.408122] [<ffffffff8100969f>] ? check_for_xstate+0x1c/0x6f
> Oct 14 00:04:26 oko kernel: [ 2796.408124] [<ffffffff81009966>] ? restore_i387_xstate+0x9e/0x17c
> Oct 14 00:04:26 oko kernel: [ 2796.408128] [<ffffffff81044e92>] ? do_sigaltstack+0xaa/0x13e
> Oct 14 00:04:26 oko kernel: [ 2796.408131] [<ffffffff812233c5>] ? sys_sendmsg+0x39/0x58
> Oct 14 00:04:26 oko kernel: [ 2796.408134] [<ffffffff812ec17b>] ? system_call_fastpath+0x16/0x1b
> Oct 14 00:04:26 oko kernel: [ 2796.408176] ---[ end trace 634279251cfb99d1 ]---
> Oct 14 00:04:26 oko kernel: [ 2796.409026] ------------[ cut here ]------------
> Oct 14 00:04:26 oko kernel: [ 2796.409046] WARNING: at /usr/src/linux-git/drivers/net/wireless/iwlwifi/iwl-agn-lib.c:1766 iwlagn_set_rxon_chain+0x107/0x1b2 [iwlagn]()
> Oct 14 00:04:26 oko kernel: [ 2796.409048] Hardware name: Vostro 3350
> Oct 14 00:04:26 oko kernel: [ 2796.409049] invalid SMPS mode 0
> Oct 14 00:04:26 oko kernel: [ 2796.409050] Modules linked in: acpi_cpufreq mperf cpufreq_conservative autofs4 rfcomm cpufreq_stats bnep cpufreq_powersave cpufreq_userspace pci_stub binfmt_misc microcode uinput nfs lockd auth_rpcgss nfs_acl sunrpc ext2 coretemp loop kvm_intel kvm aesni_intel cryptd aes_x86_64 aes_generic ecb btusb radeon bluetooth uvcvideo usb_storage videodev arc4 media uas iwlagn v4l2_compat_ioctl32 i915 crc16 snd_hda_codec_idt ttm drm_kms_helper mac80211 drm snd_hda_intel snd_hda_codec ehci_hcd snd_hwdep xhci_hcd snd_pcm snd_seq usbcore joydev sg cfg80211 snd_timer sr_mod snd_seq_device snd r8169 psmouse dell_wmi cdrom dell_laptop soundcore i2c_algo_bit pcspkr evdev sparse_keymap processor snd_page_alloc video cfbcopyarea mii dcdbas button cfbimgblt cfbfillrect wmi ac
battery ext3 jbd mbcache dm_mod sd_mod crc_t10dif ahci libahci libata scsi_mod thermal thermal_sys [last unloaded: vboxdrv]
> Oct 14 00:04:26 oko kernel: [ 2796.409109] Pid: 3017, comm: wpa_supplicant Tainted: G W 3.1.0-rc9+ #12
> Oct 14 00:04:26 oko kernel: [ 2796.409110] Call Trace:
> Oct 14 00:04:26 oko kernel: [ 2796.409116] [<ffffffff8103437f>] ? warn_slowpath_common+0x78/0x8c
> Oct 14 00:04:26 oko kernel: [ 2796.409119] [<ffffffff8103442b>] ? warn_slowpath_fmt+0x45/0x4a
> Oct 14 00:04:26 oko kernel: [ 2796.409133] [<ffffffffa03b78e7>] ? iwl_send_cmd+0x1a4/0x303 [iwlagn]
> Oct 14 00:04:26 oko kernel: [ 2796.409140] [<ffffffffa03a93f1>] ? iwlagn_set_rxon_chain+0x107/0x1b2 [iwlagn]
> Oct 14 00:04:26 oko kernel: [ 2796.409145] [<ffffffffa03a276d>] ? iwl_update_chain_flags+0x32/0x58 [iwlagn]
> Oct 14 00:04:26 oko kernel: [ 2796.409156] [<ffffffffa03af7cd>] ? iwl_power_set_mode+0xf4/0x157 [iwlagn]
> Oct 14 00:04:26 oko kernel: [ 2796.409163] [<ffffffffa03af9e0>] ? iwl_power_update_mode+0x1b0/0x1b9 [iwlagn]
> Oct 14 00:04:26 oko kernel: [ 2796.409170] [<ffffffffa03b2cd8>] ? iwlagn_mac_config+0x206/0x287 [iwlagn]
> Oct 14 00:04:26 oko kernel: [ 2796.409185] [<ffffffffa0319690>] ? ieee80211_mgd_deauth+0x19c/0x1c0 [mac80211]
> Oct 14 00:04:26 oko kernel: [ 2796.409188] [<ffffffff812e96ed>] ? sub_preempt_count+0x83/0x94
> Oct 14 00:04:26 oko kernel: [ 2796.409201] [<ffffffffa01ca76c>] ? __cfg80211_mlme_deauth+0x107/0x116 [cfg80211]
> Oct 14 00:04:26 oko kernel: [ 2796.409206] [<ffffffff812e64d9>] ? schedule_hrtimeout_range_clock+0xc8/0x103
> Oct 14 00:04:26 oko kernel: [ 2796.409208] [<ffffffff8102c1e5>] ? get_parent_ip+0x9/0x1b
> Oct 14 00:04:26 oko kernel: [ 2796.409216] [<ffffffffa01ca7e4>] ? cfg80211_mlme_deauth+0x69/0x82 [cfg80211]
> Oct 14 00:04:26 oko kernel: [ 2796.409220] [<ffffffff81023735>] ? __wake_up_common+0x40/0x77
> Oct 14 00:04:26 oko kernel: [ 2796.409228] [<ffffffffa01c15ed>] ? nl80211_deauthenticate+0xbc/0xc7 [cfg80211]
> Oct 14 00:04:26 oko kernel: [ 2796.409238] [<ffffffffa01c35cb>] ? nl80211_pre_doit+0x85/0xfb [cfg80211]
> Oct 14 00:04:26 oko kernel: [ 2796.409244] [<ffffffff81250f71>] ? genl_rcv_msg+0x1cb/0x1f9
> Oct 14 00:04:26 oko kernel: [ 2796.409246] [<ffffffff81250da6>] ? genl_rcv+0x28/0x28
> Oct 14 00:04:26 oko kernel: [ 2796.409249] [<ffffffff81250a06>] ? netlink_rcv_skb+0x36/0x7a
> Oct 14 00:04:26 oko kernel: [ 2796.409251] [<ffffffff81250d9d>] ? genl_rcv+0x1f/0x28
> Oct 14 00:04:26 oko kernel: [ 2796.409253] [<ffffffff81250537>] ? netlink_unicast+0xe6/0x14e
> Oct 14 00:04:26 oko kernel: [ 2796.409256] [<ffffffff81250819>] ? netlink_sendmsg+0x27a/0x2b2
> Oct 14 00:04:26 oko kernel: [ 2796.409262] [<ffffffff810f45dc>] ? __pollwait+0xce/0xce
> Oct 14 00:04:26 oko kernel: [ 2796.409266] [<ffffffff8122172d>] ? sock_sendmsg+0xc1/0xde
> Oct 14 00:04:26 oko kernel: [ 2796.409268] [<ffffffff8122160e>] ? sock_recvmsg+0xcd/0xec
> Oct 14 00:04:26 oko kernel: [ 2796.409271] [<ffffffff8102c1e5>] ? get_parent_ip+0x9/0x1b
> Oct 14 00:04:26 oko kernel: [ 2796.409273] [<ffffffff8122160e>] ? sock_recvmsg+0xcd/0xec
> Oct 14 00:04:26 oko kernel: [ 2796.409276] [<ffffffff812228d4>] ? move_addr_to_kernel+0x24/0x46
> Oct 14 00:04:26 oko kernel: [ 2796.409279] [<ffffffff812219c5>] ? __sys_sendmsg+0x1e8/0x288
> Oct 14 00:04:26 oko kernel: [ 2796.409282] [<ffffffff812e9798>] ? add_preempt_count+0x9a/0x9c
> Oct 14 00:04:26 oko kernel: [ 2796.409284] [<ffffffff8102c1e5>] ? get_parent_ip+0x9/0x1b
> Oct 14 00:04:26 oko kernel: [ 2796.409286] [<ffffffff812e96ed>] ? sub_preempt_count+0x83/0x94
> Oct 14 00:04:26 oko kernel: [ 2796.409289] [<ffffffff812e6f14>] ? _raw_spin_unlock_irq+0x23/0x2f
> Oct 14 00:04:26 oko kernel: [ 2796.409294] [<ffffffff810022e1>] ? do_signal+0x51d/0x5f3
> Oct 14 00:04:26 oko kernel: [ 2796.409297] [<ffffffff81008f1b>] ? init_fpu+0x72/0x7f
> Oct 14 00:04:26 oko kernel: [ 2796.409300] [<ffffffff8100969f>] ? check_for_xstate+0x1c/0x6f
> Oct 14 00:04:26 oko kernel: [ 2796.409303] [<ffffffff81009966>] ? restore_i387_xstate+0x9e/0x17c
> Oct 14 00:04:26 oko kernel: [ 2796.409305] [<ffffffff81044e92>] ? do_sigaltstack+0xaa/0x13e
> Oct 14 00:04:26 oko kernel: [ 2796.409308] [<ffffffff812233c5>] ? sys_sendmsg+0x39/0x58
> Oct 14 00:04:26 oko kernel: [ 2796.409312] [<ffffffff812ec17b>] ? system_call_fastpath+0x16/0x1b
> Oct 14 00:04:26 oko kernel: [ 2796.409314] ---[ end trace 634279251cfb99d2 ]---
> Oct 14 00:04:26 oko kernel: [ 2796.409315] ------------[ cut here ]------------
> Oct 14 00:04:26 oko kernel: [ 2796.409325] WARNING: at /usr/src/linux-git/drivers/net/wireless/iwlwifi/iwl-agn-lib.c:1766 iwlagn_set_rxon_chain+0x107/0x1b2 [iwlagn]()
> Oct 14 00:04:26 oko kernel: [ 2796.409327] Hardware name: Vostro 3350
> Oct 14 00:04:26 oko kernel: [ 2796.409328] invalid SMPS mode 0
> Oct 14 00:04:26 oko kernel: [ 2796.409329] Modules linked in: acpi_cpufreq mperf cpufreq_conservative autofs4 rfcomm cpufreq_stats bnep cpufreq_powersave cpufreq_userspace pci_stub binfmt_misc microcode uinput nfs lockd auth_rpcgss nfs_acl sunrpc ext2 coretemp loop kvm_intel kvm aesni_intel cryptd aes_x86_64 aes_generic ecb btusb radeon bluetooth uvcvideo usb_storage videodev arc4 media uas iwlagn v4l2_compat_ioctl32 i915 crc16 snd_hda_codec_idt ttm drm_kms_helper mac80211 drm snd_hda_intel snd_hda_codec ehci_hcd snd_hwdep xhci_hcd snd_pcm snd_seq usbcore joydev sg cfg80211 snd_timer sr_mod snd_seq_device snd r8169 psmouse dell_wmi cdrom dell_laptop soundcore i2c_algo_bit pcspkr evdev sparse_keymap processor snd_page_alloc video cfbcopyarea mii dcdbas button cfbimgblt cfbfillrect wmi ac
battery ext3 jbd mbcache dm_mod sd_mod crc_t10dif ahci libahci libata scsi_mod thermal thermal_sys [last unloaded: vboxdrv]
> Oct 14 00:04:26 oko kernel: [ 2796.409371] Pid: 3017, comm: wpa_supplicant Tainted: G W 3.1.0-rc9+ #12
> Oct 14 00:04:26 oko kernel: [ 2796.409372] Call Trace:
> Oct 14 00:04:26 oko kernel: [ 2796.409381] [<ffffffff8103437f>] ? warn_slowpath_common+0x78/0x8c
> Oct 14 00:04:26 oko kernel: [ 2796.409384] [<ffffffff8103442b>] ? warn_slowpath_fmt+0x45/0x4a
> Oct 14 00:04:26 oko kernel: [ 2796.409392] [<ffffffffa03b78e7>] ? iwl_send_cmd+0x1a4/0x303 [iwlagn]
> Oct 14 00:04:26 oko kernel: [ 2796.409399] [<ffffffffa03a93f1>] ? iwlagn_set_rxon_chain+0x107/0x1b2 [iwlagn]
> Oct 14 00:04:26 oko kernel: [ 2796.409408] [<ffffffffa03a276d>] ? iwl_update_chain_flags+0x32/0x58 [iwlagn]
> Oct 14 00:04:26 oko kernel: [ 2796.409415] [<ffffffffa03af7cd>] ? iwl_power_set_mode+0xf4/0x157 [iwlagn]
> Oct 14 00:04:26 oko kernel: [ 2796.409421] [<ffffffffa03af9e0>] ? iwl_power_update_mode+0x1b0/0x1b9 [iwlagn]
> Oct 14 00:04:26 oko kernel: [ 2796.409429] [<ffffffffa03b2cd8>] ? iwlagn_mac_config+0x206/0x287 [iwlagn]
> Oct 14 00:04:26 oko kernel: [ 2796.409439] [<ffffffffa0319690>] ? ieee80211_mgd_deauth+0x19c/0x1c0 [mac80211]
> Oct 14 00:04:26 oko kernel: [ 2796.409442] [<ffffffff812e96ed>] ? sub_preempt_count+0x83/0x94
> Oct 14 00:04:26 oko kernel: [ 2796.409457] [<ffffffffa01ca76c>] ? __cfg80211_mlme_deauth+0x107/0x116 [cfg80211]
> Oct 14 00:04:26 oko kernel: [ 2796.409460] [<ffffffff812e64d9>] ? schedule_hrtimeout_range_clock+0xc8/0x103
> Oct 14 00:04:26 oko kernel: [ 2796.409463] [<ffffffff8102c1e5>] ? get_parent_ip+0x9/0x1b
> Oct 14 00:04:26 oko kernel: [ 2796.409477] [<ffffffffa01ca7e4>] ? cfg80211_mlme_deauth+0x69/0x82 [cfg80211]
> Oct 14 00:04:26 oko kernel: [ 2796.409479] [<ffffffff81023735>] ? __wake_up_common+0x40/0x77
> Oct 14 00:04:26 oko kernel: [ 2796.409490] [<ffffffffa01c15ed>] ? nl80211_deauthenticate+0xbc/0xc7 [cfg80211]
> Oct 14 00:04:26 oko kernel: [ 2796.409498] [<ffffffffa01c35cb>] ? nl80211_pre_doit+0x85/0xfb [cfg80211]
> Oct 14 00:04:26 oko kernel: [ 2796.409502] [<ffffffff81250f71>] ? genl_rcv_msg+0x1cb/0x1f9
> Oct 14 00:04:26 oko kernel: [ 2796.409505] [<ffffffff81250da6>] ? genl_rcv+0x28/0x28
> Oct 14 00:04:26 oko kernel: [ 2796.409507] [<ffffffff81250a06>] ? netlink_rcv_skb+0x36/0x7a
> Oct 14 00:04:26 oko kernel: [ 2796.409509] [<ffffffff81250d9d>] ? genl_rcv+0x1f/0x28
> Oct 14 00:04:26 oko kernel: [ 2796.409511] [<ffffffff81250537>] ? netlink_unicast+0xe6/0x14e
> Oct 14 00:04:26 oko kernel: [ 2796.409514] [<ffffffff81250819>] ? netlink_sendmsg+0x27a/0x2b2
> Oct 14 00:04:26 oko kernel: [ 2796.409517] [<ffffffff810f45dc>] ? __pollwait+0xce/0xce
> Oct 14 00:04:26 oko kernel: [ 2796.409519] [<ffffffff8122172d>] ? sock_sendmsg+0xc1/0xde
> Oct 14 00:04:26 oko kernel: [ 2796.409521] [<ffffffff8122160e>] ? sock_recvmsg+0xcd/0xec
> Oct 14 00:04:26 oko kernel: [ 2796.409526] [<ffffffff8102c1e5>] ? get_parent_ip+0x9/0x1b
> Oct 14 00:04:26 oko kernel: [ 2796.409529] [<ffffffff8122160e>] ? sock_recvmsg+0xcd/0xec
> Oct 14 00:04:26 oko kernel: [ 2796.409532] [<ffffffff812228d4>] ? move_addr_to_kernel+0x24/0x46
> Oct 14 00:04:26 oko kernel: [ 2796.409534] [<ffffffff812219c5>] ? __sys_sendmsg+0x1e8/0x288
> Oct 14 00:04:26 oko kernel: [ 2796.409537] [<ffffffff812e9798>] ? add_preempt_count+0x9a/0x9c
> Oct 14 00:04:26 oko kernel: [ 2796.409539] [<ffffffff8102c1e5>] ? get_parent_ip+0x9/0x1b
> Oct 14 00:04:26 oko kernel: [ 2796.409542] [<ffffffff812e96ed>] ? sub_preempt_count+0x83/0x94
> Oct 14 00:04:26 oko kernel: [ 2796.409544] [<ffffffff812e6f14>] ? _raw_spin_unlock_irq+0x23/0x2f
> Oct 14 00:04:26 oko kernel: [ 2796.409548] [<ffffffff810022e1>] ? do_signal+0x51d/0x5f3
> Oct 14 00:04:26 oko kernel: [ 2796.409551] [<ffffffff81008f1b>] ? init_fpu+0x72/0x7f
> Oct 14 00:04:26 oko kernel: [ 2796.409554] [<ffffffff8100969f>] ? check_for_xstate+0x1c/0x6f
> Oct 14 00:04:26 oko kernel: [ 2796.409556] [<ffffffff81009966>] ? restore_i387_xstate+0x9e/0x17c
> Oct 14 00:04:26 oko kernel: [ 2796.409559] [<ffffffff81044e92>] ? do_sigaltstack+0xaa/0x13e
> Oct 14 00:04:26 oko kernel: [ 2796.409564] [<ffffffff812233c5>] ? sys_sendmsg+0x39/0x58
> Oct 14 00:04:26 oko kernel: [ 2796.409568] [<ffffffff812ec17b>] ? system_call_fastpath+0x16/0x1b
> Oct 14 00:04:26 oko kernel: [ 2796.409570] ---[ end trace 634279251cfb99d3 ]---
> Oct 14 00:04:26 oko kernel: [ 2796.409586] cfg80211: Calling CRDA for country: PL
> Oct 14 00:04:27 oko kernel: [ 2796.573759] ------------[ cut here ]------------
> Oct 14 00:04:27 oko kernel: [ 2796.575276] WARNING: at /usr/src/linux-git/drivers/net/wireless/iwlwifi/iwl-agn-lib.c:1766 iwlagn_set_rxon_chain+0x107/0x1b2 [iwlagn]()
> Oct 14 00:04:27 oko kernel: [ 2796.576866] Hardware name: Vostro 3350
> Oct 14 00:04:27 oko kernel: [ 2796.578449] invalid SMPS mode 0
> Oct 14 00:04:27 oko kernel: [ 2796.578488] Modules linked in: acpi_cpufreq mperf cpufreq_conservative autofs4 rfcomm cpufreq_stats bnep cpufreq_powersave cpufreq_userspace pci_stub binfmt_misc microcode uinput nfs lockd auth_rpcgss nfs_acl sunrpc ext2 coretemp loop kvm_intel kvm aesni_intel cryptd aes_x86_64 aes_generic ecb btusb radeon bluetooth uvcvideo usb_storage videodev arc4 media uas iwlagn v4l2_compat_ioctl32 i915 crc16 snd_hda_codec_idt ttm drm_kms_helper mac80211 drm snd_hda_intel snd_hda_codec ehci_hcd snd_hwdep xhci_hcd snd_pcm snd_seq usbcore joydev sg cfg80211 snd_timer sr_mod snd_seq_device snd r8169 psmouse dell_wmi cdrom dell_laptop soundcore i2c_algo_bit pcspkr evdev sparse_keymap processor snd_page_alloc video cfbcopyarea mii dcdbas button cfbimgblt cfbfillrect wmi ac
battery ext3 jbd mbcache dm_mod sd_mod crc_t10dif ahci libahci libata scsi_mod thermal thermal_sys [last unloaded: vboxdrv]
> Oct 14 00:04:27 oko kernel: [ 2796.591110] Pid: 2973, comm: NetworkManager Tainted: G W 3.1.0-rc9+ #12
> Oct 14 00:04:27 oko kernel: [ 2796.592295] Call Trace:
> Oct 14 00:04:27 oko kernel: [ 2796.593474] [<ffffffff8103437f>] ? warn_slowpath_common+0x78/0x8c
> Oct 14 00:04:27 oko kernel: [ 2796.594693] [<ffffffff8103442b>] ? warn_slowpath_fmt+0x45/0x4a
> Oct 14 00:04:27 oko kernel: [ 2796.595910] [<ffffffff812e96ed>] ? sub_preempt_count+0x83/0x94
> Oct 14 00:04:27 oko kernel: [ 2796.597087] [<ffffffffa03a93f1>] ? iwlagn_set_rxon_chain+0x107/0x1b2 [iwlagn]
> Oct 14 00:04:27 oko kernel: [ 2796.598296] [<ffffffff812e6f14>] ? _raw_spin_unlock_irq+0x23/0x2f
> Oct 14 00:04:27 oko kernel: [ 2796.599507] [<ffffffffa03adc8c>] ? iwl_teardown_interface+0x4a/0x7e [iwlagn]
> Oct 14 00:04:27 oko kernel: [ 2796.600697] [<ffffffffa03ae569>] ? iwl_mac_remove_interface+0x4e/0x5e [iwlagn]
> Oct 14 00:04:27 oko kernel: [ 2796.601914] [<ffffffffa031c3f3>] ? ieee80211_do_stop+0x314/0x465 [mac80211]
> Oct 14 00:04:27 oko kernel: [ 2796.603133] [<ffffffff81039618>] ? _local_bh_enable_ip.isra.12+0x94/0xa2
> Oct 14 00:04:27 oko kernel: [ 2796.604328] [<ffffffffa031c557>] ? ieee80211_stop+0x13/0x17 [mac80211]
> Oct 14 00:04:27 oko kernel: [ 2796.605523] [<ffffffff8122f754>] ? __dev_close_many+0x7f/0xab
> Oct 14 00:04:27 oko kernel: [ 2796.606752] [<ffffffff8122f7b0>] ? __dev_close+0x30/0x47
> Oct 14 00:04:27 oko kernel: [ 2796.607981] [<ffffffff812e96ed>] ? sub_preempt_count+0x83/0x94
> Oct 14 00:04:27 oko kernel: [ 2796.609179] [<ffffffff81233e6a>] ? __dev_change_flags+0x9d/0x118
> Oct 14 00:04:27 oko kernel: [ 2796.610406] [<ffffffff81233f4b>] ? dev_change_flags+0x12/0x42
> Oct 14 00:04:27 oko kernel: [ 2796.611639] [<ffffffff8123da18>] ? do_setlink+0x287/0x6f8
> Oct 14 00:04:27 oko kernel: [ 2796.612848] [<ffffffff810da6a2>] ? __kmalloc_node_track_caller+0xcb/0x105
> Oct 14 00:04:27 oko kernel: [ 2796.614089] [<ffffffff812263ef>] ? sock_rmalloc+0x2b/0x4b
> Oct 14 00:04:27 oko kernel: [ 2796.615338] [<ffffffff8123e20a>] ? __rtnl_unlock+0xc/0xc
> Oct 14 00:04:27 oko kernel: [ 2796.616549] [<ffffffff8123e0d2>] ? rtnl_setlink+0xc4/0xe6
> Oct 14 00:04:27 oko kernel: [ 2796.617799] [<ffffffff81250a06>] ? netlink_rcv_skb+0x36/0x7a
> Oct 14 00:04:27 oko kernel: [ 2796.619042] [<ffffffff8123d64d>] ? rtnetlink_rcv+0x1f/0x28
> Oct 14 00:04:27 oko kernel: [ 2796.620261] [<ffffffff81250537>] ? netlink_unicast+0xe6/0x14e
> Oct 14 00:04:27 oko kernel: [ 2796.621476] [<ffffffff81250819>] ? netlink_sendmsg+0x27a/0x2b2
> Oct 14 00:04:27 oko kernel: [ 2796.622718] [<ffffffff8122172d>] ? sock_sendmsg+0xc1/0xde
> Oct 14 00:04:27 oko kernel: [ 2796.623961] [<ffffffff8122160e>] ? sock_recvmsg+0xcd/0xec
> Oct 14 00:04:27 oko kernel: [ 2796.625173] [<ffffffff8122172d>] ? sock_sendmsg+0xc1/0xde
> Oct 14 00:04:27 oko kernel: [ 2796.626407] [<ffffffff8116d88c>] ? cpumask_any_but+0x24/0x34
> Oct 14 00:04:27 oko kernel: [ 2796.627641] [<ffffffff812228d4>] ? move_addr_to_kernel+0x24/0x46
> Oct 14 00:04:27 oko kernel: [ 2796.628853] [<ffffffff812219c5>] ? __sys_sendmsg+0x1e8/0x288
> Oct 14 00:04:27 oko kernel: [ 2796.630089] [<ffffffff812df81a>] ? __bad_area_nosemaphore+0x87/0x1f0
> Oct 14 00:04:27 oko kernel: [ 2796.631335] [<ffffffff810e79c6>] ? fget_light+0x85/0x8d
> Oct 14 00:04:27 oko kernel: [ 2796.632537] [<ffffffff812230a0>] ? sys_sendto+0x108/0x137
> Oct 14 00:04:27 oko kernel: [ 2796.633768] [<ffffffff810f6c44>] ? dput+0xe6/0xf3
> Oct 14 00:04:27 oko kernel: [ 2796.634992] [<ffffffff812233c5>] ? sys_sendmsg+0x39/0x58
> Oct 14 00:04:27 oko kernel: [ 2796.636194] [<ffffffff812ec17b>] ? system_call_fastpath+0x16/0x1b
> Oct 14 00:04:27 oko kernel: [ 2796.637398] ---[ end trace 634279251cfb99d4 ]---
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: 0001-iwlagn-check-for-SMPS-mode.patch --]
[-- Type: text/x-patch, Size: 1549 bytes --]
>From d52f49a327e7bfb4d07b056e16312ffd23477b8e Mon Sep 17 00:00:00 2001
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date: Fri, 14 Oct 2011 08:26:07 -0700
Subject: [PATCH 1/1] iwlagn: check for SMPS mode
Check and report WARN only when its invalid
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 1 +
drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
index 1a52ed2..6465983 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
@@ -827,6 +827,7 @@ static int iwl_get_idle_rx_chain_count(struct iwl_priv *priv, int active_cnt)
case IEEE80211_SMPS_STATIC:
case IEEE80211_SMPS_DYNAMIC:
return IWL_NUM_IDLE_CHAINS_SINGLE;
+ case IEEE80211_SMPS_AUTOMATIC:
case IEEE80211_SMPS_OFF:
return active_cnt;
default:
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c b/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c
index a580efe..94c7779 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c
@@ -541,6 +541,9 @@ int iwlagn_mac_config(struct ieee80211_hw *hw, u32 changed)
mutex_lock(&priv->shrd->mutex);
+ if (test_bit(STATUS_EXIT_PENDING, &priv->shrd->status))
+ goto out;
+
if (unlikely(test_bit(STATUS_SCANNING, &priv->shrd->status))) {
IWL_DEBUG_MAC80211(priv, "leave - scanning\n");
goto out;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH net-next] tcp: reduce memory needs of out of order queue
From: Rick Jones @ 2011-10-14 15:50 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20111014.034224.1197576516015404466.davem@davemloft.net>
On 10/14/2011 12:42 AM, David Miller wrote:
> No objection from me, although I wish wireless drivers were able to
> size their SKBs more appropriately. I wonder how many problems that
> look like "OMG we gotz da Buffer Bloat, arrr!" are actually due to
> this truesize issue.
I think the buffer bloat folks are looking at latency through transmit
queues - now perhaps some of their latency is really coming from
retransmissions thanks to packets being dropped thanks to overfilling
socket buffers, but I'm pretty sure they are clever enough to look for that.
> I think such large truesize SKBs will cause problems even in non loss
> situations, in that the receive buffer will hit it's limits more
> quickly. I not sure that the receive buffer autotuning is built to
> handle this sort of scenerio as a common occurance.
I believe that may be the case - at least during something like:
netperf -t TCP_RR -H <host> -l 30 -- -b 256 -D
which on an otherwise quiet test setup will report a non-trivial number
of retransmissions - either via looking at netstat -s output, or by
adding local_transport_retrans,remote_transport_retrans to an output
selector for netperf (eg -o
throughput,burst_size,local_transport_retrans,remote_transport_retrans,lss_size_end,rsr_size_end)
(I plan on providing more data after a laptop has gone through some
upgrades)
> You might want to check if this is the actual root cause of your
> problems. If the receive buffer autotuning doesn't expand the receive
> buffer enough to hold two windows worth of these large truesize SKBs,
> that's the real reason why we end up pruning.
>
> We have to decide if these kinds of SKBs are acceptable as a normal
> situation for MSS sized frames. And if they are then it's probably
> a good idea to adjust the receive buffer autotuning code too.
>
> Although I realize it might be difficult, getting rid of these weird
> SKBs in the first place would be ideal.
That means a semi-arbitrary alloc/copy in drivers, even when/if the
wasted space isn't going to be a problem no? That TCP_RR test above
would run "just fine" if the burst size was much smaller, but if there
was an arbitrary allocate/copy it would take a service demand and thus
transaction rate hit.
> It would also be a good idea to put the truesize inaccuracies into
> perspective when selecting how to fix this. It's trying to prevent
> 1 byte packets not accounting for the 256 byte SKB and metadata.
> That kind of case with such a high ratio of wastage is important.
>
> On the other hand, using 2048 bytes for a 1500 byte packet and claiming
> the truesize is 1500 + sizeof(metadata)... that might be an acceptable
> lie to tell :-) This is especially true if it allows an easy solution
> to this wireless problem.
Is the wireless problem strictly a wireless problem? Many of the
drivers where Eric has been fixing the truesize accounting have been
wired devices no?
rick jones
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: Disable LRO on FCoE or iSCSI boot device
From: Michael Chan @ 2011-10-14 15:53 UTC (permalink / raw)
To: 'Rick Jones'
Cc: 'davem@davemloft.net', 'netdev@vger.kernel.org',
Dmitry Kravkov, Eilon Greenstein
In-Reply-To: <4E9855EC.1020509@hp.com>
Rick Jones wrote:
> Is this perhaps saying that a bnx2x-driven device being used for FCoE
> or
> iSCSI boot must not permit *any* run-time configuration change which
> leads to a NIC reset?
>
That is right. Unless you have a multipath configuration with multiple
ports, then you can reset one port at a time.
^ permalink raw reply
* Re: [PATCH net-next] tcp: reduce memory needs of out of order queue
From: Eric Dumazet @ 2011-10-14 16:00 UTC (permalink / raw)
To: Rick Jones; +Cc: David Miller, netdev
In-Reply-To: <4E985A3F.5080103@hp.com>
Le vendredi 14 octobre 2011 à 08:50 -0700, Rick Jones a écrit :
> Is the wireless problem strictly a wireless problem? Many of the
> drivers where Eric has been fixing the truesize accounting have been
> wired devices no?
Yes, but the goal of such fixes it to make bugs happen too with said
wired devices ;)
About WIFI, I get these TCP Collapses on two different machines, one
using drivers/net/wireless/rt2x00 driver
Extract from drivers/net/wireless/rt2x00/rt2x00queue.h
/**
* DOC: Entry frame size
*
* Ralink PCI devices demand the Frame size to be a multiple of 128 bytes,
* for USB devices this restriction does not apply, but the value of
* 2432 makes sense since it is big enough to contain the maximum fragment
* size according to the ieee802.11 specs.
* The aggregation size depends on support from the driver, but should
* be something around 3840 bytes.
*/
#define DATA_FRAME_SIZE 2432
#define MGMT_FRAME_SIZE 256
#define AGGREGATION_SIZE 3840
You understand why we endup using skb->truesize > 4096 buffers
I liked doing the copybreak only if needed, I found the OFO case was
most of the time responsible of the Collapses.
Now we also could do the copybreak for frames queued into regular
receive_queue, if current wmem_alloc is above 25% of rcvbuf space...
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: Disable LRO on FCoE or iSCSI boot device
From: Rick Jones @ 2011-10-14 16:06 UTC (permalink / raw)
To: Michael Chan
Cc: 'davem@davemloft.net', 'netdev@vger.kernel.org',
Dmitry Kravkov, Eilon Greenstein
In-Reply-To: <C27F8246C663564A84BB7AB34397724266D2018303@IRVEXCHCCR01.corp.ad.broadcom.com>
On 10/14/2011 08:53 AM, Michael Chan wrote:
> Rick Jones wrote:
>
>> Is this perhaps saying that a bnx2x-driven device being used for
>> FCoE or iSCSI boot must not permit *any* run-time configuration
>> change which leads to a NIC reset?
>>
>
> That is right. Unless you have a multipath configuration with multiple
> ports, then you can reset one port at a time.
So, should there also be a "cnic_boot_device" check in many of the
"capital letter" ethtool paths?
rick
^ permalink raw reply
* Re: [PATCH net-next] tcp: reduce memory needs of out of order queue
From: Eric Dumazet @ 2011-10-14 16:11 UTC (permalink / raw)
To: Rick Jones; +Cc: David Miller, netdev
In-Reply-To: <1318608052.2223.35.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Le vendredi 14 octobre 2011 à 18:00 +0200, Eric Dumazet a écrit :
> Now we also could do the copybreak for frames queued into regular
> receive_queue, if current wmem_alloc is above 25% of rcvbuf space...
I mean rmem_alloc of course...
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index c1653fe..0fe0828 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4426,6 +4426,25 @@ static inline int tcp_try_rmem_schedule(struct sock *sk, unsigned int size)
return 0;
}
+/*
+ * Caller want to reduce memory needs before queueing skb
+ * The (expensive) copy should not be be done in fast path.
+ */
+static struct sk_buff *skb_reduce_truesize(struct sk_buff *skb)
+{
+ if (skb->truesize > 2 * SKB_TRUESIZE(skb->len)) {
+ struct sk_buff *nskb;
+
+ nskb = skb_copy_expand(skb, skb_headroom(skb), 0,
+ GFP_ATOMIC | __GFP_NOWARN);
+ if (nskb) {
+ __kfree_skb(skb);
+ skb = nskb;
+ }
+ }
+ return skb;
+}
+
static void tcp_data_queue(struct sock *sk, struct sk_buff *skb)
{
struct tcphdr *th = tcp_hdr(skb);
@@ -4475,6 +4494,10 @@ queue_and_out:
tcp_try_rmem_schedule(sk, skb->truesize))
goto drop;
+ if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf >> 2) {
+ skb = skb_reduce_truesize(skb);
+ th = tcp_hdr(skb);
+ }
skb_set_owner_r(skb, sk);
__skb_queue_tail(&sk->sk_receive_queue, skb);
}
@@ -4553,6 +4576,11 @@ drop:
SOCK_DEBUG(sk, "out of order segment: rcv_next %X seq %X - %X\n",
tp->rcv_nxt, TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_seq);
+ /* Since this skb might stay on ofo a long time, try to reduce
+ * its truesize (if its too big) to avoid future pruning.
+ * Many drivers allocate large buffers even to hold tiny frames.
+ */
+ skb = skb_reduce_truesize(skb);
skb_set_owner_r(skb, sk);
if (!skb_peek(&tp->out_of_order_queue)) {
^ permalink raw reply related
* Re: [PATCH net-next] bnx2x: Disable LRO on FCoE or iSCSI boot device
From: Michael Chan @ 2011-10-14 16:15 UTC (permalink / raw)
To: 'Rick Jones'
Cc: 'davem@davemloft.net', 'netdev@vger.kernel.org',
Dmitry Kravkov, Eilon Greenstein
In-Reply-To: <4E985DE8.3090308@hp.com>
Rick Jones wrote:
> On 10/14/2011 08:53 AM, Michael Chan wrote:
> > Rick Jones wrote:
> >
> >> Is this perhaps saying that a bnx2x-driven device being used for
> >> FCoE or iSCSI boot must not permit *any* run-time configuration
> >> change which leads to a NIC reset?
> >>
> >
> > That is right. Unless you have a multipath configuration with
> multiple
> > ports, then you can reset one port at a time.
>
> So, should there also be a "cnic_boot_device" check in many of the
> "capital letter" ethtool paths?
>
If the user is doing ethtool configuration changes or device shutdown,
it is more obvious what the consequence will be. The user may also be
careful to do it on a multipath setup.
The reset caused by the auto turn-off of LRO when you enable
ip_forward or bridging will not be obvious to the user. In addition,
all devices with LRO turned on will be reset at the same time so even
multipath will not survive.
^ permalink raw reply
* Re: [PATCH net-next] tcp: reduce memory needs of out of order queue
From: Eric Dumazet @ 2011-10-14 17:33 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1318579509.2533.110.camel@edumazet-laptop>
Le vendredi 14 octobre 2011 à 10:05 +0200, Eric Dumazet a écrit :
> This patch specifically addresses the OFO problem, trying to lower
> memory usage for machines handling lot of sockets (proxies for example)
Well, thinking a bit more about it is needed, so zap the patch please.
Thanks
^ permalink raw reply
* Re: [PATCH 3/4] net/can: the mailinglist moved to vger.kernel.org
From: David Miller @ 2011-10-14 17:59 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <1318581817-12352-4-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Fri, 14 Oct 2011 10:43:36 +0200
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Please, just remove these references from the source files, they
absolutely do not belong there.
The MAINTAINERS file is the place to obtain this kind of information
and automated tools can let you know which MAINTAINERS entry applies
to a particular source file as long as the entry has appropriate file
tags.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/4] drivers/net/can: the mailinglist moved to vger.kernel.org
From: David Miller @ 2011-10-14 18:00 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <1318581817-12352-3-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Fri, 14 Oct 2011 10:43:35 +0200
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Same comment as for the net/can patch, just get rid of these
reference altogether please.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] niu: fix skb truesize underestimation
From: Eric Dumazet @ 2011-10-14 18:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111014.003427.1515514811425011051.davem@davemloft.net>
Le vendredi 14 octobre 2011 à 00:34 -0400, David Miller a écrit :
>
> It would be pretty amazing for a leak of this magnitude to exist for
> so long. :-)
>
> A page can be split into multiple blocks, each block is some power
> of two in size.
>
> The chip splits up "blocks" into smaller (also power of two)
> fragments, and these fragments are what we en-tail to the SKBs.
>
> So at the top level we give the chip blocks. We try to make this
> equal to PAGE_SIZE. But if PAGE_SIZE is really large we limit the
> block size to 1 << 15. Note that it is only when we enforce this
> block size limit that the compount_page(page)->_count atomic increment
> will occur. As long as PAGE_SIZE <= 1 << 15, rbr_blocks_per_page
> will be 1.
>
> When the chip takes a block and starts using it, it decides which
> fragment size to use for that block. Once a fragment size has been
> choosen for a block, it will not change.
>
> The fragment sizes the chip can use is stored in rp->rbr_sizes[]. We
> always configure the chip to use 256 byte and 1024 byte blocks, then
> depending upon the MTU and the PAGE_SIZE we'll optionally enable other
> sizes such as 2048, 4096, and 8192.
>
> When we get an RX packet the descriptor tells us the DMA address
> and the fragment size in use for the block that the memory at
> DMA address belongs to.
>
> So the two seperate page reference count grabs you see are handling
> references for memory being chopped up at two different levels.
>
> I can't see how we could optimize the intra-block refcounts any
> further. Part of the problem is that we don't know apriori what
> fragment size the chip will use for a given block.
>
Thanks for taking the time to explain this David :)
^ permalink raw reply
* Re: [PATCH] staging: hv: move hv_netvsc out of staging area
From: Stephen Hemminger @ 2011-10-14 19:12 UTC (permalink / raw)
To: Haiyang Zhang
Cc: kys, gregkh, linux-kernel, devel, virtualization, Mike Sterling,
NetDev
In-Reply-To: <1318620026-8349-1-git-send-email-haiyangz@microsoft.com>
On Fri, 14 Oct 2011 12:20:26 -0700
Haiyang Zhang <haiyangz@microsoft.com> wrote:
> hv_netvsc has been reviewed on netdev mailing list on 6/09/2011.
> All recommended changes have been made. We are requesting to move
> it out of staging area.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Signed-off-by: KY Srinivasan <kys@microsoft.com>
> Signed-off-by: Mike Sterling <Mike.Sterling@microsoft.com>
> Cc: NetDev <netdev@vger.kernel.org>
Thanks for all the work.
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
^ permalink raw reply
* Re: [PATCH] staging: hv: move hv_netvsc out of staging area
From: Greg KH @ 2011-10-14 19:16 UTC (permalink / raw)
To: Haiyang Zhang
Cc: kys, linux-kernel, devel, virtualization, Mike Sterling, NetDev
In-Reply-To: <1318620026-8349-1-git-send-email-haiyangz@microsoft.com>
On Fri, Oct 14, 2011 at 12:20:26PM -0700, Haiyang Zhang wrote:
> hv_netvsc has been reviewed on netdev mailing list on 6/09/2011.
> All recommended changes have been made. We are requesting to move
> it out of staging area.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Signed-off-by: KY Srinivasan <kys@microsoft.com>
> Signed-off-by: Mike Sterling <Mike.Sterling@microsoft.com>
> Cc: NetDev <netdev@vger.kernel.org>
>
> ---
> drivers/net/Kconfig | 2 ++
> drivers/net/Makefile | 2 ++
> drivers/net/hyperv/Kconfig | 5 +++++
> drivers/net/hyperv/Makefile | 3 +++
> drivers/{staging/hv => net/hyperv}/hyperv_net.h | 0
> drivers/{staging/hv => net/hyperv}/netvsc.c | 0
> drivers/{staging/hv => net/hyperv}/netvsc_drv.c | 0
> drivers/{staging/hv => net/hyperv}/rndis_filter.c | 0
Because of renames, the network developers really can't review this. I
suggest posting a new patch, that just adds the driver to the
drivers/net/ directory, and have the network developer review it that
way.
Then, when it is accepted, I can delete the version in the staging
directory. We've done it this way for other drivers and it is the best
way to get proper reviews as well as handling cross-subsystem merge
issues.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] staging: hv: move hv_netvsc out of staging area
From: Haiyang Zhang @ 2011-10-14 19:20 UTC (permalink / raw)
To: haiyangz, kys, gregkh, linux-kernel, devel, virtualization
Cc: Mike Sterling, NetDev
hv_netvsc has been reviewed on netdev mailing list on 6/09/2011.
All recommended changes have been made. We are requesting to move
it out of staging area.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: KY Srinivasan <kys@microsoft.com>
Signed-off-by: Mike Sterling <Mike.Sterling@microsoft.com>
Cc: NetDev <netdev@vger.kernel.org>
---
drivers/net/Kconfig | 2 ++
drivers/net/Makefile | 2 ++
drivers/net/hyperv/Kconfig | 5 +++++
drivers/net/hyperv/Makefile | 3 +++
drivers/{staging/hv => net/hyperv}/hyperv_net.h | 0
drivers/{staging/hv => net/hyperv}/netvsc.c | 0
drivers/{staging/hv => net/hyperv}/netvsc_drv.c | 0
drivers/{staging/hv => net/hyperv}/rndis_filter.c | 0
drivers/staging/hv/Kconfig | 6 ------
drivers/staging/hv/Makefile | 2 --
drivers/staging/hv/TODO | 1 -
11 files changed, 12 insertions(+), 9 deletions(-)
create mode 100644 drivers/net/hyperv/Kconfig
create mode 100644 drivers/net/hyperv/Makefile
rename drivers/{staging/hv => net/hyperv}/hyperv_net.h (100%)
rename drivers/{staging/hv => net/hyperv}/netvsc.c (100%)
rename drivers/{staging/hv => net/hyperv}/netvsc_drv.c (100%)
rename drivers/{staging/hv => net/hyperv}/rndis_filter.c (100%)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 8d0314d..088c330 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -3451,4 +3451,6 @@ config VMXNET3
To compile this driver as a module, choose M here: the
module will be called vmxnet3.
+source "drivers/net/hyperv/Kconfig"
+
endif # NETDEVICES
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index e1eca2a..647c878 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -306,3 +306,5 @@ obj-$(CONFIG_CAIF) += caif/
obj-$(CONFIG_OCTEON_MGMT_ETHERNET) += octeon/
obj-$(CONFIG_PCH_GBE) += pch_gbe/
obj-$(CONFIG_TILE_NET) += tile/
+
+obj-$(CONFIG_HYPERV_NET) += hyperv/
diff --git a/drivers/net/hyperv/Kconfig b/drivers/net/hyperv/Kconfig
new file mode 100644
index 0000000..936968d
--- /dev/null
+++ b/drivers/net/hyperv/Kconfig
@@ -0,0 +1,5 @@
+config HYPERV_NET
+ tristate "Microsoft Hyper-V virtual network driver"
+ depends on HYPERV
+ help
+ Select this option to enable the Hyper-V virtual network driver.
diff --git a/drivers/net/hyperv/Makefile b/drivers/net/hyperv/Makefile
new file mode 100644
index 0000000..c8a6682
--- /dev/null
+++ b/drivers/net/hyperv/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_HYPERV_NET) += hv_netvsc.o
+
+hv_netvsc-y := netvsc_drv.o netvsc.o rndis_filter.o
diff --git a/drivers/staging/hv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
similarity index 100%
rename from drivers/staging/hv/hyperv_net.h
rename to drivers/net/hyperv/hyperv_net.h
diff --git a/drivers/staging/hv/netvsc.c b/drivers/net/hyperv/netvsc.c
similarity index 100%
rename from drivers/staging/hv/netvsc.c
rename to drivers/net/hyperv/netvsc.c
diff --git a/drivers/staging/hv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
similarity index 100%
rename from drivers/staging/hv/netvsc_drv.c
rename to drivers/net/hyperv/netvsc_drv.c
diff --git a/drivers/staging/hv/rndis_filter.c b/drivers/net/hyperv/rndis_filter.c
similarity index 100%
rename from drivers/staging/hv/rndis_filter.c
rename to drivers/net/hyperv/rndis_filter.c
diff --git a/drivers/staging/hv/Kconfig b/drivers/staging/hv/Kconfig
index 072185e..8a51166 100644
--- a/drivers/staging/hv/Kconfig
+++ b/drivers/staging/hv/Kconfig
@@ -4,12 +4,6 @@ config HYPERV_STORAGE
help
Select this option to enable the Hyper-V virtual storage driver.
-config HYPERV_NET
- tristate "Microsoft Hyper-V virtual network driver"
- depends on HYPERV && NET
- help
- Select this option to enable the Hyper-V virtual network driver.
-
config HYPERV_MOUSE
tristate "Microsoft Hyper-V mouse driver"
depends on HYPERV && HID
diff --git a/drivers/staging/hv/Makefile b/drivers/staging/hv/Makefile
index e071c12..b536584 100644
--- a/drivers/staging/hv/Makefile
+++ b/drivers/staging/hv/Makefile
@@ -1,7 +1,5 @@
obj-$(CONFIG_HYPERV) += hv_timesource.o
obj-$(CONFIG_HYPERV_STORAGE) += hv_storvsc.o
-obj-$(CONFIG_HYPERV_NET) += hv_netvsc.o
obj-$(CONFIG_HYPERV_MOUSE) += hv_mouse.o
hv_storvsc-y := storvsc_drv.o
-hv_netvsc-y := netvsc_drv.o netvsc.o rndis_filter.o
diff --git a/drivers/staging/hv/TODO b/drivers/staging/hv/TODO
index ed4d636..fd080cb 100644
--- a/drivers/staging/hv/TODO
+++ b/drivers/staging/hv/TODO
@@ -1,5 +1,4 @@
TODO:
- - audit the network driver
- audit the scsi driver
Please send patches for this code to Greg Kroah-Hartman <gregkh@suse.de>,
--
1.7.3.4
^ permalink raw reply related
* Re: iwlagn: WARN_ON() in iwl_get_idle_rx_chain_count()
From: Michał Mirosław @ 2011-10-14 19:21 UTC (permalink / raw)
To: wwguy
Cc: Intel Linux Wireless, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <1318606158.12009.2.camel@wwguy-ubuntu>
On Fri, Oct 14, 2011 at 08:29:18AM -0700, wwguy wrote:
> Could you try the attach patch and see if it fix your problem.
[attached patch removed]
Backported and applied. I'll test it for couple of days.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Problem with ixgbe and TX locked on one cpu
From: Paweł Staszewski @ 2011-10-14 19:18 UTC (permalink / raw)
To: Linux Network Development list
[-- Attachment #1: Type: text/plain, Size: 4338 bytes --]
Hello
I have weird problem with ixgbe and irq affinity / rx-tx queue assignment
Statistics for my ethernet - ixgbe driver:
ethtool -S eth4
NIC statistics:
rx_packets: 5815535848808
tx_packets: 5811202378421
rx_bytes: 4791001750842200
tx_bytes: 4781190419358301
rx_pkts_nic: 5815535848827
tx_pkts_nic: 5811202378510
rx_bytes_nic: 4837563124411799
tx_bytes_nic: 4829987507084013
lsc_int: 8
tx_busy: 0
non_eop_descs: 0
rx_errors: 0
tx_errors: 0
rx_dropped: 0
tx_dropped: 0
multicast: 92494273
broadcast: 268718206
rx_no_buffer_count: 28829
collisions: 0
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
hw_rsc_aggregated: 0
hw_rsc_flushed: 0
fdir_match: 0
fdir_miss: 0
rx_fifo_errors: 0
rx_missed_errors: 307051074
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_timeout_count: 0
tx_restart_queue: 15926219
rx_long_length_errors: 298
rx_short_length_errors: 0
tx_flow_control_xon: 0
rx_flow_control_xon: 0
tx_flow_control_xoff: 0
rx_flow_control_xoff: 0
rx_csum_offload_errors: 54173917
alloc_rx_page_failed: 0
alloc_rx_buff_failed: 0
rx_no_dma_resources: 0
tx_queue_0_packets: 68694825
tx_queue_0_bytes: 9443750332
tx_queue_1_packets: 8410961
tx_queue_1_bytes: 2527763233
tx_queue_2_packets: 14411252
tx_queue_2_bytes: 1317132394
tx_queue_3_packets: 15013508147
tx_queue_3_bytes: 17364767277348
tx_queue_4_packets: 62779891
tx_queue_4_bytes: 63476596221
tx_queue_5_packets: 11176001
tx_queue_5_bytes: 2763600253
tx_queue_6_packets: 4416357
tx_queue_6_bytes: 611874984
tx_queue_7_packets: 8933405
tx_queue_7_bytes: 1837198524
tx_queue_8_packets: 13292669
tx_queue_8_bytes: 3241333510
tx_queue_9_packets: 10747236
tx_queue_9_bytes: 1805109931
tx_queue_10_packets: 5795935258380
tx_queue_10_bytes: 4763725304722245
tx_queue_11_packets: 12073934
tx_queue_11_bytes: 2982743045
tx_queue_12_packets: 10523764
tx_queue_12_bytes: 2637451199
tx_queue_13_packets: 12480552
tx_queue_13_bytes: 2434827407
tx_queue_14_packets: 7401777
tx_queue_14_bytes: 2413618099
tx_queue_15_packets: 8269270
tx_queue_15_bytes: 2854359576
rx_queue_0_packets: 361373769507
rx_queue_0_bytes: 298565751248279
rx_queue_1_packets: 369901571908
rx_queue_1_bytes: 303414679798160
rx_queue_2_packets: 362508961738
rx_queue_2_bytes: 299852439447157
rx_queue_3_packets: 363449272013
rx_queue_3_bytes: 299738390792515
rx_queue_4_packets: 361876234461
rx_queue_4_bytes: 297483366939732
rx_queue_5_packets: 361402926316
rx_queue_5_bytes: 297633876486533
rx_queue_6_packets: 362261522767
rx_queue_6_bytes: 298026696344647
rx_queue_7_packets: 361248593301
rx_queue_7_bytes: 296756459279986
rx_queue_8_packets: 361654143416
rx_queue_8_bytes: 298272433659520
rx_queue_9_packets: 362781764710
rx_queue_9_bytes: 298804803191595
rx_queue_10_packets: 361386593064
rx_queue_10_bytes: 297434987797644
rx_queue_11_packets: 369886597895
rx_queue_11_bytes: 302353350171712
rx_queue_12_packets: 361582732276
rx_queue_12_bytes: 298670408005971
rx_queue_13_packets: 365248093536
rx_queue_13_bytes: 302573023878287
rx_queue_14_packets: 366571142073
rx_queue_14_bytes: 302396739276514
rx_queue_15_packets: 362401929830
rx_queue_15_bytes: 299024344526029
The problem is with queue 10
tx_queue_10_packets: 5795935258380
tx_queue_10_bytes: 4763725304722245
as you can see most of the queue processing is used in queue 10
Average difference is 1,854271229903958e-6 - compared to other queues
and the problem is that almost all TX packet processing is on one CPU
cat /proc/interrupts - in attached file
Is this driver or kernel problem ?
Kernel is: 2.6.38.2
ixgbe driver is:
ethtool -i eth4
driver: ixgbe
version: 3.2.9-k2
firmware-version: 1.12-2
bus-info: 0000:04:00.0
Thanks
Pawel
--
[-- Attachment #2: interrupts.txt --]
[-- Type: text/plain, Size: 3675 bytes --]
cat /proc/interrupts | grep eth4
135: 3109261876 4289060 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth4-TxRx-0
136: 2738300312 2654348120 4055848 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth4-TxRx-1
137: 43 2636245312 3776381478 4281702 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth4-TxRx-2
138: 340 2156086460 3340495 3269054231 4487452 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth4-TxRx-3
139: 38 0 2738519426 0 1088719123 4176363 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth4-TxRx-4
140: 39 0 2632858749 3512903 0 2307156010 4310322 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth4-TxRx-5
141: 41 0 0 2655130571 0 0 2492897896 4249569 0 0 0 0 0 0 0 0 PCI-MSI-edge eth4-TxRx-6
142: 173 0 0 2625727263 0 0 0 2509835335 8038276 0 0 0 0 0 0 0 PCI-MSI-edge eth4-TxRx-7
143: 44 0 0 0 2115559 0 0 0 3275187626 5066092 0 0 0 0 0 0 PCI-MSI-edge eth4-TxRx-8
144: 51 0 0 0 0 0 0 0 2668196538 1238317991 4373599 0 0 0 0 0 PCI-MSI-edge eth4-TxRx-9
145: 528852 0 0 0 386077 0 0 0 438158 294605430 1867115075 4806187 0 0 0 0 PCI-MSI-edge eth4-TxRx-10
146: 65 0 0 0 0 0 0 0 0 2378013639 3357280 1179087288 4668439 0 0 0 PCI-MSI-edge eth4-TxRx-11
147: 83 0 0 0 0 0 0 0 0 0 2447343915 0 1621496283 4718715 0 0 PCI-MSI-edge eth4-TxRx-12
148: 64 0 0 0 0 0 0 0 0 0 2719008413 3788138 0 2492359875 4697458 0 PCI-MSI-edge eth4-TxRx-13
149: 41 0 0 0 0 0 0 0 0 0 0 2569764726 0 0 3216415633 4546711 PCI-MSI-edge eth4-TxRx-14
150: 45 0 0 0 0 0 0 0 0 0 0 2553654902 0 0 0 2587543392 PCI-MSI-edge eth4-TxRx-15
151: 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 PCI-MSI-edge eth4:lsc
[-- Attachment #3: pstaszewski.vcf --]
[-- Type: text/x-vcard, Size: 336 bytes --]
begin:vcard
fn;quoted-printable:Pawe=C5=82 Staszewski
n;quoted-printable:Staszewski;Pawe=C5=82
org:ITCare
adr;quoted-printable;quoted-printable;dom:;;Sikorskiego 22;Libi=C4=85=C5=BC;Ma=C5=82opolskie;32-590
title:IT Manager
tel;work:+48 32 7203681
tel;fax:+48 32 7203682
tel;cell:+48 0 609911040
url:www.itcare.pl
version:2.1
end:vcard
^ 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