Hi Jamal, J Hadi Salim <[EMAIL PROTECTED]> wrote on 07/03/2007 06:56:20 PM:
> On Mon, 2007-02-07 at 17:21 -0700, Michael Chan wrote: > > [Matt, please include the count in the fix per previous email] > long answer: > My goal with storing these values and computing them was to do certain > things that dont require holding the netif_tx_lock within a batch as > well. Evaluating the packet metadata and formating the packet to be > ready for stashing into DMA was one thing i could do outside of holding > the lock easily - and running that in loop of 100 packets amortizes the > instruction cache and allows me (when i get to it) to hold the lock for > a lot less computation. Do you see any contention for tx_lock which can justify having a prep handler? As I understood, no other CPU can be in the xmit code at the same time since RUNNING bit is held. Hence getting this lock early or late should not matter for the xmit side (and you are also holding dev->queue_lock while running prep so no new skbs can also be added to the dev during this time). And I couldn't find any driver that uses the same tx_lock on rx, so where is the saving by doing prep ? - KK - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
