From: David Miller <davem@davemloft.net>
To: Vineet.Gupta1@synopsys.com
Cc: netdev@vger.kernel.org, Alexey.Brodkin@synopsys.com,
romieu@fr.zoreil.com, linux-kernel@vger.kernel.org,
arc-linux-dev@synopsys.com
Subject: Re: [PATCH] ethernet/arc/arc_emac: optimize the Tx/Tx-reclaim paths a bit
Date: Fri, 06 Sep 2013 01:03:03 -0400 (EDT) [thread overview]
Message-ID: <20130906.010303.1964966449906114324.davem@davemloft.net> (raw)
In-Reply-To: <C2D7FE5348E1B147BCA15975FBA23075141D3B@IN01WEMBXA.internal.synopsys.com>
From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Date: Fri, 6 Sep 2013 04:24:39 +0000
> On 09/05/2013 11:54 PM, David Miller wrote:
>> You should keep the check in the transmit queueing code as a BUG check,
>> almost every driver has code of the form (using NIU as an example):
...
>> Otherwise queue management bugs are incredibly hard to diagnose.
>>
>> I'm not applying this patch.
>
> The check is already there for current BD. What I removed was checking for next BD
> too (please see below). IMHO this is useless since it will be done in next
> iteration anyways. In my tests, the next check never got hit, so it was waste of
> cycles.
>
> static int arc_emac_tx(struct sk_buff *skb, struct net_device *ndev)
> {
> if (unlikely((le32_to_cpu(*info) & OWN_MASK) == FOR_EMAC)) {
> netif_stop_queue(ndev);
> return NETDEV_TX_BUSY;
> }
>
> ...
> *txbd_curr = (*txbd_curr + 1) % TX_BD_NUM;
>
> - /* Get "info" of the next BD */
> - info = &priv->txbd[*txbd_curr].info;
> -
> - /* Check if if Tx BD ring is full - next BD is still owned by EMAC */
> - if (unlikely((le32_to_cpu(*info) & OWN_MASK) == FOR_EMAC))
> - netif_stop_queue(ndev);
>
> OTOH, I do see a slight stats update issue - if the queue is stopped (but pkt not
> dropped) we are failing to increment tx_errors. But that would be a separate patch.
It is exactly the correct thing to do. The driver should _NEVER_
return NETDEV_TX_BUSY under normal circumstances. The queue should
always be stopped by the ->ndo_start_xmit() method when it fills the
queue.
Again, when ->ndo_start_xmit() is invoked, it should never see the
queue full. When that happens it is a bug.
You are deleting exactly the correct part of this function, what it is
doing right now is precisely the correct way to manage netif queue
state.
The only valid change you can make here is to make the:
if (unlikely((le32_to_cpu(*info) & OWN_MASK) == FOR_EMAC)) {
netif_stop_queue(ndev);
return NETDEV_TX_BUSY;
}
print out an error message and increment tx_errors.
prev parent reply other threads:[~2013-09-06 5:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-04 13:03 Vineet Gupta
2013-09-05 18:24 ` David Miller
2013-09-06 4:24 ` Vineet Gupta
2013-09-06 5:03 ` David Miller [this message]
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=20130906.010303.1964966449906114324.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=Alexey.Brodkin@synopsys.com \
--cc=Vineet.Gupta1@synopsys.com \
--cc=arc-linux-dev@synopsys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=romieu@fr.zoreil.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®