[PATCH net-next 4/4] gianfar: use netif_tx_queue_stopped instead of __netif_subqueue_stopped
Eric Dumazet
eric.dumazet at gmail.com
Mon Mar 19 10:53:11 EST 2012
Le dimanche 18 mars 2012 à 19:24 -0400, Paul Gortmaker a écrit :
> On Sun, Mar 18, 2012 at 5:55 PM, Eric Dumazet <eric.dumazet at gmail.com> wrote:
> > On Sun, 2012-03-18 at 17:39 -0400, Paul Gortmaker wrote:
> >> The __netif_subqueue_stopped() just does the following:
> >>
> >> struct netdev_queue *txq = netdev_get_tx_queue(dev, queue_index);
> >> return netif_tx_queue_stopped(txq);
> >>
> >> and since we already have the txq in scope, we can just call that
> >> directly in this case.
> >>
> >> Suggested-by: Eric Dumazet <eric.dumazet at gmail.com>
> >> Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
> >> ---
> >> drivers/net/ethernet/freescale/gianfar.c | 2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
> >> index 6e66cc3..d9428f0 100644
> >> --- a/drivers/net/ethernet/freescale/gianfar.c
> >> +++ b/drivers/net/ethernet/freescale/gianfar.c
> >> @@ -2565,7 +2565,7 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
> >> }
> >>
> >> /* If we freed a buffer, we can restart transmission, if necessary */
> >> - if (__netif_subqueue_stopped(dev, tqi) && tx_queue->num_txbdfree)
> >> + if (netif_tx_queue_stopped(txq) && tx_queue->num_txbdfree)
> >> netif_wake_subqueue(dev, tqi);
> >>
> >> /* Update dirty indicators */
> >
> > Please change netif_wake_subqueue() as well ;)
>
> I looked at this earlier when I added patch #4 but I was concerned about
> the different semantics.
>
> The netif_wake_subqueue() just returns on a netpoll_trap but the other
> netif_tx_wake_queue() actually calls netif_tx_start_queue() for the same
> netpoll_trap instance. Maybe that is OK, but I didn't want to be changing
> the behaviour of subtleties in stuff where I am clearly still learning.
>
I see... commit 7b3d3e4fc68 added a small difference here...
More information about the Linuxppc-dev
mailing list