星期二 十月 30, 2007

Shanghai Tech Day

Last week I went to Shanghai tech day. This is my first time to be in Shanghai, and my impression about Shanghai is that it is a very...very modern city. It contains all the modern symbols as a big city: skyscrapers, fashion girls, terrible traffic, and subway rush hour.

Here's some photos I got from Shanghai. The landscape of the Bund, the Oriental Pearl, and the subway.

 When I write in English, I tend to overlook the main point about the topic. Yes, this should be a blog about Sun tech day, not street photography in Shanghai. So, my presentation in Shanghai Tech day is about "OpenSolaris networking for developers", it is a slice put together by Nicolas targeting at software developers.

In this forty minutes presentation, I covered topics like SCTP/SDP/Crossbow/Kernel socket/Clearview/Nemo...that's a lot of topics. And guess which one got most attention? Not crossbow, because there were already enough speakers covered this project. Well, the answer is kernel socket. It seems to me software developers are very interested in seeing this project, they want to know what they can do with this project, as they are already familiar with socket applications. I admit this is a little bit surprise to me, maybe I should put more slices in the Beijing tech day this week.
 

星期一 七月 02, 2007

Presentation at Chinese Academy of Science

Last week I gave a presentation to a group of college students from Chinese Academy of Science (CAS). The presentation was part of OpenSolaris programming contest held in China. And my presentation was about Solaris network programming and the FireEngine architecture in Solaris 10. Most of the students have little experience with Solaris, but I believe many of them know a lot about Linux and Windows.

The presentation lasted about two hours, and it surely became the longest one I ever had. During the presentation, I gave a demo on STREAMS using the upmod from Sasha's blog. By using truss(1), DTrace(1M), and mdb(1), I showed to the students how to push and pop a module from a stream, how to extract data from a mblk, and how flow control works.

 The students were attracted by the demo. There were many questions after the demo and the presentation was over. Since most of them heard about STREAMS for the first time, (even if STREAMS is described from some of the famous UNIX book such as APUE and UNP, they simply ignored the part because they don't have SVR derived UNIX environment), most of the questions were about STREAMS and how FireEngine addressed the drawbacks of STREAMS.

Hope the presentation helps more Chinese students be comfortable with using Solaris. After all, UNIX is not widely used as desktop in China.

星期一 五月 28, 2007

The Packet Event Framework Open Sourced

A quick question would be "How soon?". Well, right after I got an account from Sun Download Center, plus the time to upload the big BFU archives and source codes tarballs. So it's really soon unless there are too much traffic on the internet such that my cable connection becomes as slow as a 56Kbps modem. Then you will see the files listed here, and of course you need to follow some instructions here to download and install it on your favorite OpenSolaris distributions, and you need to run a modified version of Iperf or Ping-Pong to see the benchmark results. What is more, if you want to dive a little more deeper, read the man pages here and try to find and understand them in the source codes.

I have been working on PEF for a while, and finally we archived this first milestone. It took us a long time to reach this point, and it is still a long way to go. Among all the obstacles we have encountered, performance issues are the most nasty ones. Even now there are several performance curves glued on my cubic, and they constant reminds me what we have archived, where we were and where we need to go.

So what's next? We will focus on the API part to allow third party modules to integrate into PEF. In fact, we are seeking for input from both inside Sun and outside to help design these APIs. If you have some thoughts about PEF and enthusiasm in networking architectures, feel free to drop me a note here or send me an email at eric dot yu dot sun dot com.

星期一 六月 05, 2006

A Short Overview to PEF(Packet Event Framework)

The FireEngine networking stack is widely known as a cutting-edge technology shipped in Solaris 10, a technical white paper is available in opensolaris community. Actually it is still moving forward and the Packet Event Framework is one of those innovations.

PEF Event List

PEF expands the FireEngine packet classification architecture, it allows different protocol processing functions to link together as a sequence of events, each connection has its own event list and each event in this list is executed by the framework. With this optimized event list, we can see improvement in the following area:
  • Code locality: While looking at the current TCP/IP stack, we can find some very large functions that runs the whole TCP state machine, for example tcp_rput_data(). This leads to poor code locality because every packet has to walk through these long functions, so we can split such functions into fine grain PEF events and alter the event list on the fly.
  • Networking observability: It's quite easy to insert a certain event into PEF event list to trace the packet passing thought the stack, the insertion and removal of such observing events is quite light weighted.
  • STREAMS interaction: FireEngine switches the Solaris networking stack from a message passing-based(STREAMS style) interface to a function call-based(BSD style) interface, PEF makes a further move, it removes the putnext() in TCP RX code path and wraps strrupt() into a PEF event.
Now, having enough knowledge about PEF event, let's move to a real life event list in the current project. In the current networking stack we have following following protocol processing functions in TCP RX code path: ip_tcp_input(), tcp_rput_data() and strrput(), which is hiding behind a putnext(), PEF wraps these three functions into a coarse grained event list, that is, per layer per event.

Network stack parallelism on CMT

CMT introduces multi-core and multiple hardware threads per CPU core, it can significantly increase system throughput by parallel processing, however, it brings impact to the current FireEngine networking stack especially on single connection throughput, that's because the current stack uses a per-CPU synchronization mechanism called vertical perimeter(aka, squeue), the vertical perimeter ensures data locality by processing the same connection in the same CPU whenever possible, so the utilization of parallel processing is limited.

PEF explores the parallelism of network stack on CMT. The events in PEF event list is executed one by one within an arbitrary vertical perimeter, thus we can achieve different parallel models by different means. One of the ideas is to dedicate some network tasks(such as TCP protocol processing) to a given CPU core or hardware thread by assigning the proper vertical perimeter to the PEF
event. For example, if we have four events in a PEF event list, and each of the event has a vertical perimeter binding to different CPU cores, then the function inside this event will be executed on different CPU cores in a pipeline fashion.

About

yu

Search

Categories
Archives
« 四月 2014
星期日星期一星期二星期三星期四星期五星期六
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
今天