forcedeth: tx max work
Subsystems (2)
PATCH 10/12 forcedeth: tx max work
This patch adds a limit to how much tx work can be done in each iteration of tx processing.
drivers/net/forcedeth.c +6 -5
@@ -1859,14 +1859,15 @@ } } -static void nv_tx_done_optimized (struct net_device *dev) +static void nv_tx_done_optimized (struct net_device *dev,int limit) {struct fe_priv *np =netdev_priv (dev);u32 flags;struct ring_desc_ex * orig_get_tx = np->get_tx.ex;while ((np->get_tx.ex != np->put_tx.ex) && - !((flags =le32_to_cpu (np->get_tx.ex->flaglen)) &NV_TX_VALID )) { + !((flags =le32_to_cpu (np->get_tx.ex->flaglen)) &NV_TX_VALID ) && + (limit-- >0 )) {dprintk (KERN_DEBUG "%s: nv_tx_done_optimized: flags 0x%x.\n" , dev->name, flags);
@@ -1973,7 +1974,7 @@if (np->desc_ver ==DESC_VER_1 || np->desc_ver ==DESC_VER_2 )nv_tx_done (dev);else -nv_tx_done_optimized (dev); +nv_tx_done_optimized (dev, np->tx_ring_size);/* 3) if there are dead entries: clear everything */ if (np->get_tx_ctx != np->put_tx_ctx) {
@@ -2899,7 +2900,7 @@break ;spin_lock (&np->lock); -nv_tx_done_optimized (dev); +nv_tx_done_optimized (dev,TX_WORK_PER_LOOP );spin_unlock (&np->lock);#ifdef CONFIG_FORCEDETH_NAPI
@@ -3006,7 +3007,7 @@break ;spin_lock_irqsave (&np->lock, flags); -nv_tx_done_optimized (dev); +nv_tx_done_optimized (dev,TX_WORK_PER_LOOP );spin_unlock_irqrestore (&np->lock, flags);if (unlikely (events & (NVREG_IRQ_TX_ERR ))) {
Quoted 3 lines · Ayaz Abdulla
This patch adds a limit to how much tx work can be done in each iteration of tx processing.
Signed-off-by Ayaz Abdulla <[email protected]>
What about the "tail end" of the work, when the limit is reached?
Remember that delaying the completion of TX's too long increases latency.
It seems to me that this patch needs a timer or somesuch, to guarantee that TX completions are not delayed too long in the worst case.
Jeff
Quoted 4 lines · Jeff Garzik
Quoted 3 lines · Ayaz Abdulla
This patch adds a limit to how much tx work can be done in each iteration of tx processing.
Quoted 8 lines
Quoted 1 line
Signed-off-by Ayaz Abdulla <[email protected]>What about the "tail end" of the work, when the limit is reached?
Remember that delaying the completion of TX's too long increases latency.
It seems to me that this patch needs a timer or somesuch, to guarantee that TX completions are not delayed too long in the worst case.
Yes, you are right.
There is a timer interrupt that fires in throughput mode every 10ms (in cpu mode it fires at approx every 130us). I can use that to clean out any uncompleted TXs. Let me know if 10ms is not too late for worst case tx completion.
Quoted 5 lines
Jeff