Re: Dedicated core(s) for network stack?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

Thank you, I'll take a look at that. No academical research - I'm jjust curious :-) The cache interaction is of course big concern, but the general architecture described in the papers sidestep this by leaving the actual data copy for application core(s) - for both TX and RX. Please read the papers first. And of course this was meant for SMPs, I guess that for NUMA machines the interaction with memory subsystem might hamper scalability of such approach. For uniprocessors and smaller machines the traditional stack would most likely still be a better choice. 

Alex

> ------------ Původní zpráva ------------
> Od: Matthew Faulkner <matthew.faulkner@xxxxxxxxx>
> Předmět: Re: Dedicated core(s) for network stack?
> Datum: 05.9.2010 23:25:35
> ----------------------------------------
> Ales,
> 
> (Pimping my own work here)
> 
> Not sure if you're doing this for academic work or not, either way
> they might be interesting for you to read over.  I basically concluded
> excatly what Stephen just said at the end of his end. Dedicated
> network processor is bad because of higher cache miss rates. The two
> papers that might be of interest to you are:
> 
> 
> Evaluating the Performance of Network Protocol Processing on Multi-core Systems
> Architectural implications of performing network protocol processing
> closer to the application (maybe slightly less interesting)
> 
> If you're even more interested my PhD might be worth a read. It covers
> the background on these topics in some detail.  The can be found at
> 
> http://matthew-faulkner.org/dump/thesis.pdf
> 
> Hope this information is helpful
> 
> Cheers.
> 
> Dr. Matt Faulkner
> 
> 
> 
> On 5 September 2010 21:22, Stephen Hemminger <shemminger@xxxxxxxxxx> wrote:
> > On Sun, 05 Sep 2010 15:08:52 +0200 (CEST)
> > ales-76@xxxxxxxxx wrote:
> >
> >> Hello,
> >>
> >> Recently I've read some nice articles:
> >>
> >> Shalev L. et al., IsoStack - Highly Efficient Network Processing on Dedicated
> Cores > http://www.usenix.org/event/atc10/tech/full_papers/Shalev.pdf
> >> Regnier G. et al., ETA: Experience with an Intel Xeon Processor as a Packet
> Processing Engine >
> http://www.hoti.org/archive/Hoti11_program/papers/hoti11_11_regnier_g.pdf
> >> Regnier G. et al., TCP Onloading for Data Center Servers >
> ftp://download.intel.com/technology/comms/perfnet/download/tcp_ieee_article.pdf
> >>
> >> Very interesting reading, I guess that many kernel people are familiar with
> these papers. Anyway my question is:
> >>
> >> Any considerations (or even ongoing project) for implementing similar TCP/IP
> stack architecture under Linux?
> >
> > No explicit project but it is an interesting idea.
> >
> >> It looks to me like very brigth idea, especially when number of cores on-chip
> increases every year and the trend is clear. The benchmark seems to indicate
> that isolating a core (or more) solely for network processing is a big win in
> terms of performance. I am curious what is the opinion of kernel developers on
> this.
> >
> > There is a myth that "network processing" is a some sort of monolithic entity
> > with a single use case.  For a typical server/client, there interactions of
> > scheduler local processes and caching. If the processing is on a dedicated
> > core, it guarantees a cache miss when the data is processed by the
> > application.
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-net" in
> > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux 802.1Q VLAN]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Git]     [Bugtraq]     [Yosemite News and Information]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux PCI]     [Linux Admin]     [Samba]

  Powered by Linux