aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/intel/e1000/e1000_main.c
diff options
context:
space:
mode:
authorDavid S. Miller <[email protected]>2014-08-25 17:27:47 -0700
committerDavid S. Miller <[email protected]>2014-08-25 17:27:47 -0700
commit8dbb200fa4589174202a131bd6dc45b7d569df96 (patch)
treefe056ca032ee9d8b0307b4502e198f0efc3a2209 /drivers/net/ethernet/intel/e1000/e1000_main.c
parent2b7890e757bc42f963c835521c2657bd16d7b7d6 (diff)
parent1ee1cfe7d3df00bff11dd28576eeac1875d7d51f (diff)
Merge branch 'tso_fix'
Vladislav Yasevich says: ==================== Fix TSO and checksum issues with non-accelerated vlan traffic. I've recently ran across something rather interesting when testing vlans from inside VMs. In some scenarios I was getting awfull thruput. Some debugging uncovered a very scary packet corruption. I was seeing packets that had original TSO length as IP total length and their ip checksum was 0. This was with e1000e driver. A bit more debugging uncovered an assumption made by that driver that skb->protocol will contain l3 protocol information. This was not the case in my setup since I manually turned off vlan tx acceleration for the device. This caused the driver to not initialize the tso information correctly and resulted in corrupt TSO frames on the wire. I decided to do some auditing of the usage of skb->protocols in the drivers. Out of all the drivers, the included 8 appear to be effected. They all allow user to control vlan acceleration settings, all support TSO on vlan devices, and all use skb->protocol to decide how to encode TSO information. Some also have similar problems when initializing hw checksum information. On such device, it is simple enough to reproduce the issue. Simply turn off TX VLAN acceleration on the device, create a vlan, and run you favorite network performance tool. There is 1 driver I ran across that I belive will trigger a BUG in the system when used with vlans. That driver is tile/tilepro.c I have not changed it in this patch set and would hope that the maintainer has time to look at it. V2: Fix i40ev using the wrong function name. Full build. ==================== Signed-off-by: David S. Miller <[email protected]>
Diffstat (limited to 'drivers/net/ethernet/intel/e1000/e1000_main.c')
-rw-r--r--drivers/net/ethernet/intel/e1000/e1000_main.c19
1 files changed, 11 insertions, 8 deletions
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index cbc330b301cd..ad3d5d12173f 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -2674,7 +2674,8 @@ set_itr_now:
#define E1000_TX_FLAGS_VLAN_SHIFT 16
static int e1000_tso(struct e1000_adapter *adapter,
- struct e1000_tx_ring *tx_ring, struct sk_buff *skb)
+ struct e1000_tx_ring *tx_ring, struct sk_buff *skb,
+ __be16 protocol)
{
struct e1000_context_desc *context_desc;
struct e1000_buffer *buffer_info;
@@ -2692,7 +2693,7 @@ static int e1000_tso(struct e1000_adapter *adapter,
hdr_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
mss = skb_shinfo(skb)->gso_size;
- if (skb->protocol == htons(ETH_P_IP)) {
+ if (protocol == htons(ETH_P_IP)) {
struct iphdr *iph = ip_hdr(skb);
iph->tot_len = 0;
iph->check = 0;
@@ -2702,7 +2703,7 @@ static int e1000_tso(struct e1000_adapter *adapter,
0);
cmd_length = E1000_TXD_CMD_IP;
ipcse = skb_transport_offset(skb) - 1;
- } else if (skb->protocol == htons(ETH_P_IPV6)) {
+ } else if (skb_is_gso_v6(skb)) {
ipv6_hdr(skb)->payload_len = 0;
tcp_hdr(skb)->check =
~csum_ipv6_magic(&ipv6_hdr(skb)->saddr,
@@ -2745,7 +2746,8 @@ static int e1000_tso(struct e1000_adapter *adapter,
}
static bool e1000_tx_csum(struct e1000_adapter *adapter,
- struct e1000_tx_ring *tx_ring, struct sk_buff *skb)
+ struct e1000_tx_ring *tx_ring, struct sk_buff *skb,
+ __be16 protocol)
{
struct e1000_context_desc *context_desc;
struct e1000_buffer *buffer_info;
@@ -2756,7 +2758,7 @@ static bool e1000_tx_csum(struct e1000_adapter *adapter,
if (skb->ip_summed != CHECKSUM_PARTIAL)
return false;
- switch (skb->protocol) {
+ switch (protocol) {
case cpu_to_be16(ETH_P_IP):
if (ip_hdr(skb)->protocol == IPPROTO_TCP)
cmd_len |= E1000_TXD_CMD_TCP;
@@ -3097,6 +3099,7 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
int count = 0;
int tso;
unsigned int f;
+ __be16 protocol = vlan_get_protocol(skb);
/* This goes back to the question of how to logically map a Tx queue
* to a flow. Right now, performance is impacted slightly negatively
@@ -3210,7 +3213,7 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
first = tx_ring->next_to_use;
- tso = e1000_tso(adapter, tx_ring, skb);
+ tso = e1000_tso(adapter, tx_ring, skb, protocol);
if (tso < 0) {
dev_kfree_skb_any(skb);
return NETDEV_TX_OK;
@@ -3220,10 +3223,10 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
if (likely(hw->mac_type != e1000_82544))
tx_ring->last_tx_tso = true;
tx_flags |= E1000_TX_FLAGS_TSO;
- } else if (likely(e1000_tx_csum(adapter, tx_ring, skb)))
+ } else if (likely(e1000_tx_csum(adapter, tx_ring, skb, protocol)))
tx_flags |= E1000_TX_FLAGS_CSUM;
- if (likely(skb->protocol == htons(ETH_P_IP)))
+ if (protocol == htons(ETH_P_IP))
tx_flags |= E1000_TX_FLAGS_IPV4;
if (unlikely(skb->no_fcs))