From: Florian Fainelli <f.fainelli@xxxxxxxxx> Date: Mon, 21 Apr 2014 12:55:12 -0700 > 2014-04-21 12:17 GMT-07:00 David Miller <davem@xxxxxxxxxxxxx>: >> From: Florian Fainelli <f.fainelli@xxxxxxxxx> >> Date: Mon, 21 Apr 2014 08:45:22 -0700 >> >>> Configuring the ethtool tx-frames property, which translates into N >>> packets before a TX interrupt is the simplest configuration scheme >>> because it requires no locking neither at the softare nor hardware >>> level, and is completely indepedent from the link speed. Since ethtool >>> does not allow per-tx queue coalescing parameters, we apply the same >>> setting to any transmit queue. >>> >>> We can no longer enable the BDONE/PDONE interrupts as those would fire >>> for each packet/buffer received, which would defeat the MBDONE interrupt >>> purpose. The MBDONE interrupt is guaranteed to correspond to a >>> PDONE/BDONE interrupt when the threshold is set to 1. >>> >>> Signed-off-by: Florian Fainelli <f.fainelli@xxxxxxxxx> >> >> Does the MBDONE scheme have a timeout? >> >> For example if you ask for a MBDONE setting where N=4, if only 2 packets >> arrive will you get an interrupt or will it wait for 2 more to arrive >> no matter what? > > There is no configurable timeout for the transmit DMA engine (receive > does have one), but we do get a ring empty interrupt as soon as the > transmit path has completed the packets, so the MBDONE interrupt cause > always makes us run the TX reclaim logic. This latency may be too large for TCP. In particular things like TCP Small Queues need timely feedback for transmitted packets. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html