3

When we doing network programming, no matter you use multi-process, multi-thread or select/poll(epoll), there is only one process/thread to deal with accept the connection on same port. And if you want to take advantage of multi-cores, you need to create worker processes/threads. But what about the bound is dealing with network connections? Is there a way to take advantage of multi-core when dealing with network connections?

I found some materials. And seems this is hard to complete. Three-way hand shaking will be implicit done by the kernel. And in smp structure operating system will be divided into several critical zones. The same critical zone can't be run on more than one core at the same time.

Joe
  • 42,600
  • 24
  • 134
  • 225
easy
  • 31
  • 2

2 Answers2

1

All modern operating systems that run on PC hardware already have their network stacks heavily optimized for multi-core CPUs. For example, the packet handling code that pushes data to and from the network card is going to be independent of the TCP/IP stack code so a hardware interrupt can run to completion without disturbing the TCP code.

For most real-world applications though, the bulk of the work is between the packets. Data that comes in has to be processed and data that goes out has to be generated. That's up to application code, and that code can take advantage of multiple cores either by using multiple threads or multiple processes. How you do that best is very application and operating system specific. Windows, for example, has I/O completion ports which combine job discovery with multi-threaded job dispatch. Linux has epoll.

David Schwartz
  • 166,415
  • 16
  • 184
  • 259
  • Can hardware interrupt happen on multi-cpus? What I mean is if some packets come from network and cause a hardware interrupt , at that time cpu should save its status and execute a interrupt handle. At almost the same time, let's just say the execution hasn't finished, another packet comes and should there be an other hardware interrupt? If there will be another interrupt, will it be handled by other cpus parallel ? – easy Sep 15 '11 at 06:55
  • You wouldn't want it handled by another CPU. That CPU already has the code to handle the network card hot in its cache and can handle the packet far more efficiently than interrupting a core that's doing useful work and forcing code it's still using to be evicted from cache. Don't confuse getting started quickly with getting finished quickly! – David Schwartz Sep 15 '11 at 06:56
  • I know your point, but what I mean is can OS use multi-cpu to deal net traffic at the same time. Let's say, if I have a 4 core cpu, my application is very simple, it did nothing ,only wait for tcp traffic, so my cpus will idle all the time. And under that condition, will the OS use multi-cpu to handle the network traffic parallel? – easy Sep 15 '11 at 07:03
  • Absolutely. While one core is running your code handling the packet that was just processed by the TCP code, another core will be running the network interrupt code to receive a packet, meanwhile a third core will be running the TCP code to generate the next packet to be sent. – David Schwartz Sep 15 '11 at 07:14
  • What about the 4th core? Can the 4th core and the 2nd core both running the network interrupt code to receive packets? Thanks for your patient . – easy Sep 15 '11 at 07:23
  • Probably not, if only because the network card can't do two things at once anyway. But most likely your code will be able to take advantage of at least two cores. Operating system designers and coders are really smart people -- you can trust them to get this right on any major, modern operating system. (People benchmark, say, Linux against Windows or FreeBSD against Linux on comparable hardware. Any major discrepancies would be looked at quickly.) – David Schwartz Sep 15 '11 at 07:43
0

With just the network traffic, that's almost soley done by the network card (i.e. not the computer's CPU). Communication with the network card is usually single-threaded (queued by the OS so you can send/receive on multiple threads) because a NIC can only push/pop stuff off it's stack one-at-a-time.

It's up to your process to do what it needs in response to received data. That can be done on one thread and you can spawn other threads upon receive of data on that master thread and divide work up that way. If you have a language that supports asynchronous communications, I would try to get it to do most of the work to use multiple threads.

MSN
  • 49,698
  • 7
  • 70
  • 100
Peter Ritchie
  • 33,368
  • 9
  • 74
  • 96