On Wednesday 01 February 2006 14:48, Leonid Grossman wrote: > David S. Miller wrote: > > > And with Van Jacobson net channels, none of this is going to > > matter and 512 is going to be your limit whether you like it > > or not. So this short term complexity gain is doubly not justified. > > > David, can you elaborate on this upcoming implementation (timeframe, > description if any, etc)?
There are some slides on the web, but I failed to fully understand the concept just from them - maybe I'm just not clever enough @) http://www.lemis.com/grog/Documentation/vj/lca06vj.pdf Some details seem to be missing at least: - a description of TX (he hinted at eliminating hard_start_xmit somehow at one slide, but everything else was only on RX) - how the NIC selects the socket to connect to directly (e.g. with what does he replace the ETH/IP/TCP demux tables) - What his problem with softirqs was. They are fully parallelized in Linux and completely cache hot with their feeding interrupts, so I didn't quite follow why he wanted to eliminate them. - how exactly the drivers become more simple and what the generic functions he wants to replace driver code with do. I liked the concept of the cache friendlier"array queues", but as far as I can see there should be usually only one hand off between different CPUs for RX, so I'm not sure they will make that much difference. And longer term this handoff can be eliminated with hardware queue support anyways when we manage to get the NIC to send an MSI to the right CPU. Then everything will be CPU local. Hopefully there is a patch available soon to make this all clear. > I assume these net channels are per cpu? What's the relation to NAPI? > > This sounds like something we can "connect" our driver/ASIC queues to, > in order to extend the channels all the way to 10GbE PHY. I think the basic problem of that is still unsolved. The only really scalable way to do such connections seem to be RX hashing and send MSIs to different CPUs based on that. But it is still not fully clear how to get the Linux scheduler to cooperate with that so that the socket consumers end up at the right CPUs selected by the driver hash. -Andi (who prefers sourceware over slideware) - 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
