|To:||"David S. Miller" <davem@xxxxxxxxxxxxx>|
|Subject:||Re: [RFC] TCP congestion schedulers|
|From:||Baruch Even <baruch@xxxxxxxxx>|
|Date:||Mon, 21 Mar 2005 22:30:03 +0000|
|Cc:||John Heffner <jheffner@xxxxxxx>, ak@xxxxxx, shemminger@xxxxxxxx, netdev@xxxxxxxxxxx|
|References:||<421CF5E5.1060606@xxxxxxxxx> <20050223135732.39e62c6c.davem@xxxxxxxxxxxxx> <421D1E66.5090301@xxxxxxxx> <421D30FA.1060900@xxxxxxxxx> <20050225120814.5fa77b13@xxxxxxxxxxxxxxxxx> <20050309210442.3e9786a6.davem@xxxxxxxxxxxxx> <4230288F.1030202@xxxxxxxxx> <20050310182629.1eab09ec.davem@xxxxxxxxxxxxx> <20050311120054.4bbf675a@xxxxxxxxxxxxxxxxx> <20050311201011.360c00da.davem@xxxxxxxxxxxxx> <20050314151726.532af90d@xxxxxxxxxxxxxxxxx> <m13bur5qyo.fsf@xxxxxx> <Pine.LNX.4.58.0503211605300.6729@xxxxxxxxxxxxxx> <20050321135154.0bbeae85.davem@xxxxxxxxxxxxx>|
|User-agent:||Debian Thunderbird 1.0 (X11/20050116)|
David S. Miller wrote:
On Mon, 21 Mar 2005 16:25:56 -0500 (EST) John Heffner <jheffner@xxxxxxx> wrote:Would you really expect a single extra indirect call per ack to have a significant performance impact? This is surprising to me. Where does the cost come from? Replacing instruction cache lines?Maybe not for ACK processing (that's very thick already) but perhaps for a lighter fast path definitely so.
According to my tests (wrapping tcp_ack with rdtsc's) it takes about 3000 clocks to do tcp_ack() even for fast path, slow path is not much slower in most cases and anyway most of the time is spent either handling SACKs or remove packets from the transmit queue (clean_rtx).
I doubt if the extra calls by function are going to be that much of an issue.
Now, if I knew how to improve performance of the clean_rtx case that would give a boost to ack performance.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: dummy as IMQ replacement, Andy Furniss|
|Next by Date:||Re: slab corruption in skb allocs, Andrew Morton|
|Previous by Thread:||Re: [RFC] TCP congestion schedulers, David S. Miller|
|Next by Thread:||Re: [RFC] TCP congestion schedulers, Rick Jones|
|Indexes:||[Date] [Thread] [Top] [All Lists]|