[PATCH net-next 0/2] tg3: update on maintainer and fix for tx timeout

From: Siva Reddy Kallam <siva.kallam@broadcom.com>

First patch:
	This patch includes additional maintainer for tg3

Second patch:
	Fix for tg3 transmit queue 0 timed out when too many gso_segs

Siva Reddy Kallam (2):
  MAINTAINERS: Update tg3 maintainer
  tg3: Fix for tg3 transmit queue 0 timed out when too many gso_segs.

 MAINTAINERS                         |  1 +
 drivers/net/ethernet/broadcom/tg3.c | 25 +++++++++++++++++++------
 2 files changed, 20 insertions(+), 6 deletions(-)

-- 
1.9.1

From: Siva Reddy Kallam <siva.kallam@broadcom.com>

Signed-off-by: Siva Reddy Kallam <siva.kallam@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Acked-by: Prashant Sreedharan <redacted>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 04d62b1..0cfc43e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS

@@ -2386,6 +2386,7 @@ F:	drivers/irqchip/irq-bcm7*
 F:	drivers/irqchip/irq-brcmstb*
 
 BROADCOM TG3 GIGABIT ETHERNET DRIVER
+M:	Siva Reddy Kallam <siva.kallam@broadcom.com>
 M:	Prashant Sreedharan <prashant@broadcom.com>
 M:	Michael Chan <mchan@broadcom.com>
 L:	netdev@vger.kernel.org

-- 
1.9.1

From: Siva Reddy Kallam <siva.kallam@broadcom.com>

There is an issue on the GSO path inside tg3_tso_bug() when we don't
have sufficient descriptors available, we stop the queue. This queue
may never get started again as there are no Tx completions pending.

For example if the tcp segment size is as low as 88 bytes and TSO packet
from the stack is quite big(<64 K), gso_segs exceeds the limit of
descriptors available.

tg3_tso_bug_gso_check() is implemented to verify if the total no. of
descriptors available for gso are sufficient or not. If not sufficient
we simply linearize the the skb and transmit it once again or drop the
skb.

Signed-off-by: Siva Reddy Kallam <siva.kallam@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Acked-by: Prashant Sreedharan <redacted>
---
 drivers/net/ethernet/broadcom/tg3.c | 25 +++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 9293675..eb3d347 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c

@@ -7831,6 +7831,14 @@ static int tigon3_dma_hwbug_workaround(struct tg3_napi *tnapi,
 	return ret;
 }
 
+static bool tg3_tso_bug_gso_check(struct tg3_napi *tnapi, struct sk_buff *skb)
+{
+	/* Check if we will never have enough descriptors,
+	 * as gso_segs can be more than current ring size
+	 */
+	return skb_shinfo(skb)->gso_segs < tnapi->tx_pending / 3;
+}
+
 static netdev_tx_t tg3_start_xmit(struct sk_buff *, struct net_device *);
 
 /* Use GSO to workaround all TSO packets that meet HW bug conditions

@@ -7934,14 +7942,19 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
 		 * vlan encapsulated.
 		 */
 		if (skb->protocol == htons(ETH_P_8021Q) ||
-		    skb->protocol == htons(ETH_P_8021AD))
-			return tg3_tso_bug(tp, tnapi, txq, skb);
+		    skb->protocol == htons(ETH_P_8021AD)) {
+			if (tg3_tso_bug_gso_check(tnapi, skb))
+				return tg3_tso_bug(tp, tnapi, txq, skb);
+			goto drop;
+		}
 
 		if (!skb_is_gso_v6(skb)) {
 			if (unlikely((ETH_HLEN + hdr_len) > 80) &&
-			    tg3_flag(tp, TSO_BUG))
-				return tg3_tso_bug(tp, tnapi, txq, skb);
-
+			    tg3_flag(tp, TSO_BUG)) {
+				if (tg3_tso_bug_gso_check(tnapi, skb))
+					return tg3_tso_bug(tp, tnapi, txq, skb);
+				goto drop;
+			}
 			ip_csum = iph->check;
 			ip_tot_len = iph->tot_len;
 			iph->check = 0;

@@ -8073,7 +8086,7 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	if (would_hit_hwbug) {
 		tg3_tx_skb_unmap(tnapi, tnapi->tx_prod, i);
 
-		if (mss) {
+		if (mss && tg3_tso_bug_gso_check(tnapi, skb)) {
 			/* If it's a TSO packet, do GSO instead of
 			 * allocating and copying to a large linear SKB
 			 */

-- 
1.9.1

From: skallam <siva.kallam@broadcom.com>
Date: Wed, 20 Jan 2016 17:16:56 +0530

From: Siva Reddy Kallam <siva.kallam@broadcom.com>

First patch:
	This patch includes additional maintainer for tg3

Second patch:
	Fix for tg3 transmit queue 0 timed out when too many gso_segs

Why are you targetting bug fixes at the 'net-next' tree?

On Wed, 2016-01-20 at 17:16 +0530, skallam wrote:

From: Siva Reddy Kallam <siva.kallam@broadcom.com>

There is an issue on the GSO path inside tg3_tso_bug() when we don't
have sufficient descriptors available, we stop the queue. This queue
may never get started again as there are no Tx completions pending.

For example if the tcp segment size is as low as 88 bytes and TSO packet
from the stack is quite big(<64 K), gso_segs exceeds the limit of
descriptors available.

tg3_tso_bug_gso_check() is implemented to verify if the total no. of
descriptors available for gso are sufficient or not. If not sufficient
we simply linearize the the skb and transmit it once again or drop the
skb.

I find this changelog misleading.

linearize wont change gso_segs

You are in fact segmenting the GSO packet, which is very different than
linearizing it.

On Wed, 2016-01-20 at 20:36 -0800, Eric Dumazet wrote: 

On Wed, 2016-01-20 at 17:16 +0530, skallam wrote:

quoted

From: Siva Reddy Kallam <siva.kallam@broadcom.com>

There is an issue on the GSO path inside tg3_tso_bug() when we don't
have sufficient descriptors available, we stop the queue. This queue
may never get started again as there are no Tx completions pending.

For example if the tcp segment size is as low as 88 bytes and TSO packet
from the stack is quite big(<64 K), gso_segs exceeds the limit of
descriptors available.

tg3_tso_bug_gso_check() is implemented to verify if the total no. of
descriptors available for gso are sufficient or not. If not sufficient
we simply linearize the the skb and transmit it once again or drop the
skb.

I find this changelog misleading.

linearize wont change gso_segs

You are in fact segmenting the GSO packet, which is very different than
linearizing it.

He is referring to linearizing it for the hardware to perform TSO.

There are 2 cases that this code is trying to handle:

1. The hardware has TSO bugs.  The code detects the condtions and then
falls back to GSO.

2. The hardware has DMA bugs (such as short DMA length, 4G DMA
boundaries, etc).  In this case, the hardware can still do TSO but
requires the SKB to be linearized.  Linearizing is expensive, so we also
try to do GSO if possible.  This patch will check whether it is possible
to do GSO or not.  If not, it will linearize the SKB and have the
hardware do TSO.

I will ask Siva to try to clarify the descriptions.