From: John Fastabend <john.r.fastabend@intel.com>
To: Tom Herbert <therbert@google.com>
Cc: Alexander Duyck <alexander.duyck@gmail.com>,
Alexander Duyck <alexander.h.duyck@intel.com>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com,
sassmann@redhat.com
Subject: Re: [net-next 04/14] net: Fix issue with netdev_tx_reset_queue not resetting queue from XOFF state
Date: Sat, 21 Apr 2012 09:27:31 -0700 [thread overview]
Message-ID: <4F92DFF3.2080301@intel.com> (raw)
In-Reply-To: <CA+mtBx-TJAr-cu-vKYq6m2ZQzn1X1vf+_PKUZXDirnKEF67EAw@mail.gmail.com>
On 4/20/2012 11:01 PM, Tom Herbert wrote:
>> I don't recall the exact reason now, as John said I think it had to do
>> with the ethtool tests not using the same cleanup routine and leaving
>> us in a bad state. I am pretty sure there was some path in which
>> where the call was didn't work but I do not recall the exact details
>> now. Most of the reason for moving it is due to the fact that the
>> reset is now also clearing the bit, and from the driver perspective we
>> didn't need it in two places. After looking it all over again, I
>> suppose this causes a cosmetic issue for the bql "inflight" statistic
>> in sysfs since the value will be retained until the interface is
>> brought back up with this change. Is that an issue or something that
>> can be lived with since the interface isn't active anyway in this
>> case?
>>
> On the surface, it seems cleaner and probably a simpler convention to
> clear the state when the buffers are being freed. If there's a good
> reason not to do this for igb, it makes me wonder if this should be
> done the same way in other drivers...
>
> Tom
Just dug up the old thread. This was to fix a bug that byte queue limits
was causing with some of the loopback tests evoked from ethtool. The
loopback test uses a separate path to free the buffers which wasn't
calling netdev_tx_reset_queue().
We should likely just explicitly clear the state in each routine rather
than try to be clever IMO.
.John
next prev parent reply other threads:[~2012-04-21 16:27 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-13 4:03 [net-next 00/14][pull request] Intel Wired LAN Driver Updates Jeff Kirsher
2012-03-13 4:03 ` [net-next 01/14] igb: fix ethtool offline test Jeff Kirsher
2012-03-13 4:03 ` [net-next 02/14] ixgbe: remove tie between NAPI work limits and interrupt moderation Jeff Kirsher
2012-03-13 4:03 ` [net-next 03/14] ixgbe: add support for byte queue limits Jeff Kirsher
2012-03-13 4:03 ` [net-next 04/14] net: Fix issue with netdev_tx_reset_queue not resetting queue from XOFF state Jeff Kirsher
2012-04-20 21:19 ` Tom Herbert
2012-04-20 21:31 ` John Fastabend
2012-04-21 3:24 ` Alexander Duyck
2012-04-21 6:01 ` Tom Herbert
2012-04-21 16:27 ` John Fastabend [this message]
2012-04-21 20:18 ` David Miller
2012-04-23 3:21 ` John Fastabend
2012-03-13 4:03 ` [net-next 05/14] net: Add memory barriers to prevent possible race in byte queue limits Jeff Kirsher
2012-03-13 4:03 ` [net-next 06/14] ixgbe: Do no clear Tx status bits since eop_desc provides enough info Jeff Kirsher
2012-03-13 4:03 ` [net-next 07/14] ixgbe: Reorder adapter contents for better cache utilization Jeff Kirsher
2012-03-13 4:03 ` [net-next 08/14] ixgbe: Address issues with Tx WHTRESH value not being set correctly Jeff Kirsher
2012-03-13 4:03 ` [net-next 09/14] ixgbe: Correct Adaptive Interrupt Moderation so that it will change values Jeff Kirsher
2012-03-13 4:03 ` [net-next 10/14] ixgbe: Default to queue pairs when number of queues is less than CPUs Jeff Kirsher
2012-03-13 4:03 ` [net-next 11/14] ixgbe: Drop unnecessary napi_schedule_prep and spare blank line from ixgbe_intr Jeff Kirsher
2012-03-13 4:03 ` [net-next 12/14] ixgbe: Allocate rings as part of the q_vector Jeff Kirsher
2012-03-13 4:03 ` [net-next 13/14] ixgbe: Add iterator for cycling through rings on a q_vector Jeff Kirsher
2012-03-13 4:03 ` [net-next 14/14] ixgbe: Simplify logic for ethtool loopback frame creation and testing Jeff Kirsher
2012-03-13 5:55 ` [net-next 00/14][pull request] Intel Wired LAN Driver Updates David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F92DFF3.2080301@intel.com \
--to=john.r.fastabend@intel.com \
--cc=alexander.duyck@gmail.com \
--cc=alexander.h.duyck@intel.com \
--cc=davem@davemloft.net \
--cc=gospo@redhat.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=netdev@vger.kernel.org \
--cc=sassmann@redhat.com \
--cc=therbert@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.