[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080626.021658.126239340.davem@davemloft.net>
Date: Thu, 26 Jun 2008 02:16:58 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: jesse.brandeburg@...el.com
Cc: andy@...yhouse.net, jeffrey.t.kirsher@...el.com,
bruce.w.allan@...el.com, john.ronciak@...el.com,
netdev@...r.kernel.org
Subject: Re: [PATCH] igb: completely disable interrupts during netpoll
From: "Brandeburg, Jesse" <jesse.brandeburg@...el.com>
Date: Thu, 26 Jun 2008 00:23:59 -0700
> I think the deadlocks occur (only when using netpoll) because the tx
> cleanup (igb_clean_tx_irq) is being called simultaneously from two
> routines, which generally is guaranteed not to happen in regular
> everyday napi mode because of the bh_disable before calling dev->poll.
Thanks for the info, it's clear what the IGB driver bug is.
It's that the TX reclaim is not happening in the ->poll() handler. If
you did that, all of this would work out correctly and you wouldn't
need to disable the IRQ with disable_irq() to prevent deadlocks.
Instead IGB what does is do TX reclaim inside of it's hw interrupt
handler.
And that is actually making much more work than if you did it properly
from a NAPI ->poll() context. When igb_unmap_and_free_tx_resource()
runs from the HW interrupt it is going to queue these packet frees up
into the mid-layer's per-cpu TX free queue, and that will schedule yet
another software interrupt to actually run the kfree_skb()'s on all of
these liberated TX frames.
I moved the napi context out of the generic net device, use it! :-)
And then you can call dev_kfree_skb() directly from
igb_unmap_and_free_tx_resource() instead of dev_kfree_skb_any().
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists