[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1332190018.9397.61.camel@edumazet-glaptop>
Date: Mon, 19 Mar 2012 13:46:58 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Haiyang Zhang <haiyangz@...rosoft.com>
Cc: Stephen Hemminger <shemminger@...tta.com>,
KY Srinivasan <kys@...rosoft.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>
Subject: RE: [PATCH 1/1] net/hyperv: Fix the code handling tx busy
On Mon, 2012-03-19 at 19:17 +0000, Haiyang Zhang wrote:
> Yes, we called the stop_queue before returning NETDEV_TX_BUSY.
>
> The stop_queue was called in the function netvsc_send() in file
> netvsc.c, then it returns to rndis_filter_send(), which returns to
> netvsc_start_xmit() in file netvsc_drv.c. So the NETDEV_TX_BUSY is
> indeed returned AFTER queue is stopped.
>
Thats should be in your changelog, so that next time, reviewers dont
have to spend their time to check you did it right, especially when
start_xmit() code is not self contained or at least in a single file.
Each time we see a NETDEV_TX_BUSY in a patch, this is a sign of a
possible problem.
Your initial changelog was :
Instead of dropping the packet, we keep the skb buffer, and return
NETDEV_TX_BUSY to let upper layer retry send. This will not cause
endless loop, because the host is taking data away from ring buffer.
And this is the typical message that doesnt explain why its safe.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists