[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1324058911.25554.82.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Date: Fri, 16 Dec 2011 19:08:31 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: Christoph Lameter <cl@...ux.com>
Cc: igorm@....rs, netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH 00/10 net-next] Introduce per interface ipv4 statistics
Le vendredi 16 décembre 2011 à 11:29 -0600, Christoph Lameter a écrit :
> I have some latency critical processes here and I wish I could get
> networking in general off the processor where the latency sensitive stuff
> is running should that process decide to do some calls that cause network
> I/O.
>
> Traditional networking is a slow process these days.
Most of the slow process is in the process scheduler actually and cache
line misses in large TCP structures, but also in many layers (Qdisc...),
not counting icache footprint.
We slowly improve things, but its always a tradeoff (did I said code
bloat ?)
If you have dedicated network thread(s) in your application, bound to
the right cpu(s), then all network stack can be run on the cpus you
decide [ Also needs using correct irq affinities for the NIC interrupts]
This means your latency critical threads should delegate their network
IO (like disk IO) to other threads, _and_ avoid being blocked in
scheduler land.
Given the nature of socket api, I am not sure adding a layer to
transparently delegate network IO to a pool of dedicated cpus would be a
win.
--
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