Software developer의 생산성을 측정할 수 있을까?

We can’t measure Programmer Productivity… or can we?


The more fundamental problem is that measuring productivity by lines (or Function Points or other derivatives) typed doesn’t make any sense. A lot of important work in software development, the most important work, involves thinking and learning – not typing.

The best programmers spend a lot of time understanding and solving hard problems, or helping other people understand and solve hard problems, instead of typing. They find ways to simplify code and eliminate duplication. And a lot of the code that they do write won’t count anyways, as they iterate through experiments and build prototypes and throw all of it away in order to get to an optimal solution.



But velocity (how much work, measured in story points or feature points or ideal days, that the team delivers in a period of time) is really a measure of predictability, not productivity. Velocity is intended to be used by a team to measure how much work they can take on, to calibrate their estimates and plan their work forward.

Once a team’s velocity has stabilized, you can measure changes in velocity within the team as a relative measure of productivity. If the team’s velocity is decelerating, it could be an indicator of problems in the team or the project or the system. Or you can use velocity to measure the impact of process improvements, to see if training or new tools or new practices actually make the team’s work measurably faster.

Organizations and managers who equate internal velocity with external productivity start to set targets for velocity, forgetting that what actually matters is working software in production. Treating velocity as productivity leads to unproductive team behaviors that optimize this metric at the expense of actual working software.

The down side of equating delivery speed with productivity? Optimizing for cycle time/speed of delivery by itself could lead to problems over the long term, because this incents people to think short term, and to cut corners and take on technical debt.

Better Software

It’s easy to measure that you are writing good – or bad – software. Defect density. Defect escape rates (especially defects – including security vulnerabilities – that escape to production). Static analysis metrics on the code base, using tools like SonarQube.


As I pointed out in an [earlier post]( this makes operational metrics more important than developer metrics. According to recent studies, success in achieving these goals lead to improvements in business success: not just productivity, but market share and profitability.

그래서 결론은?

Stop trying to measure individual developer productivity.

It’s a waste of time.

Everyone knows who the top performers are. Point them in the right direction, and keep them happy.

Everyone knows the people who are struggling. Get them the help that they need to succeed.

Everyone knows who doesn’t fit in. Move them out.

Measuring and improving productivity at the team or (better) organization level will give you much more meaningful returns.

When it comes to productivity:

  1. Measure things that matter – things that will make a difference to the team or to the organization. Measures that are clear, important, and that aren’t easy to game.
  2. Use metrics for good, not for evil – to drive learning and improvement, not to compare output between teams or to rank people.

vim tip

잘 모르던 vim의 기능들.

Color scheme 선택

:colo 까지 입력하고 Ctrl+D를 누르면 선택 가능한 항목이 표시됨

도움말 항목을 선택

:help wor까지 입력하고 Ctrl+D를 누르면 wor로 시작하는 항목이 표시됨.

Case-sensitive searching

\c 옵션을 사용하면 현재 설정된 ignorecase와 반대로 검색

LF 변경


숫사 증감

Ctrl+A 현재 커서가 위치한 곳에 있는 숫자를 증가시킴(10진수, 16진수 지원)  
Ctrl+X 숫자 감소. 음수도 지원  

모든 라인에 abc 추가


e-mail 찾기


파일 읽기

:find filename    filename을 편집함  

:n **/*.c         현재 디렉토리 이하의 *.c 파일을 하나씩(한번에 하나씩) 읽어들임. **는 recursive. */*c는 1단계 아래만 검색.   
gf                현재 커서 위치에 있는 파일이름을 읽어들임   
Ctrl+W f          현재 커서 위치에 있는 파일이름을 새로운 창에 열어줌  
Ctrl+W gf         현재 커서 위치에 있는 파일으름을 새로운 탭에 열어줌  
Ctrl+^            이전 파일로 돌아감

Windows 창 크기

Ctrl+W           현재 창의 너비를 1칸 늘림
Ctrl+W 10        현재 창의 너비를 10칸 늘임

tabpage 사용하기

:tabnew           탭 추가
:#gt              # 번째 tabpage로 이동. tabpage은 1부터 시작  

vim -p a.c b.c    2개 파일을 tabpage로 열기  

현재 열어놓은 파일 목록 보기

: filles
: buffers  


ia – Insert mode에서만 동작
ca – command mode에서만 동작

ab mymail  
ab prjsrc /home/foobar/project/abc    
ia date0 =strftime("%Y.%m.%d-%H%M%S")  
ia time0 =strftime("%c")  

key mapping

nmap – normal mode only
imap – insert mode only
map – both mode
cmap – command mode only

자동으로 파일 타입에 따라 실행

autocmd BufRead, BufNewFile *.txt colo evening  
autocmd BufRead, BufNewFile *.c cool morning | set ts=2 sw=2



{motion} 에는 gg, G, )), ]] 등 이동 관련 키를 사용할 수 있다.

=gg     현재 줄 부터 첫번째 줄 까지 indent   
=G      현재 줄 부터 파일 마지막까지 indent  
=]]     현재 줄 부터 함수 마지막까지 indent 하고, 현재 줄에 커서가 유지됨 
=))     현재 줄 부터 함수 마지막까지 indent하고, 함수 끝으로 커서 이동

Auto completion

Ctrl+N                 현재 코드에서 대상이 되는 단어들을 보여줌          
Ctrl+X Ctrl+F          현재 디렉토리에 있는 파일목록을 보여줌  
Ctrl+X Ctrl+K Ctrl+N   사전 검색 모드 동작

DPDK 2.0

Release note from

Changelog (main changes since 1.8.0)
– enhancements:
* ABI versioning
* x32 ABI
* non-eal thread supports
* multi-pthread per core
* enable big contigmem blocks in BSD
* port hotplug
* jobstats library
* reorder library
* memcpy optimization
* acl for AVX2
* crc hash arch-independent
* uio_pci_generic support
* kni optimizations
* vhost-user support
* virtio (link, vlan, mac, port IO, perf)
* ixgbevf RSS
* i40e hash filtering
* i40e nvgre offloading
* i40e TSO
* fm10k driver
* mlx4 driver
* bonding mode 4 tests
* bonding mode 6
* Rx/Tx callbacks
* unified flow types
* remove old filtering API (flow director, flex, ethertype, syn, ntuple)
* remove static tailqs from EAL
* remove device arguments limit
* add indirect attached mbuf flag
* use default port configuration in testpmd
* tunnel offloading in testpmd
* PDF doc output
* NICs guide
– fixes for:
* build
* memory leaks
* big endian
* devargs
* kvargs
* cmdline
* timer
* lpm
* pipeline
* bonding
* vhost
* virtio
* pcap
* igb
* ixgbe
* i40e
* enic
* testpmd

Charting the path to RAN virtualization

Charting the path to RAN virtualization

C-RAN means

  • Centralized : Centralized processing resource pool supports 10-10,000 cells
  • Collaborative : Multicell joint scheduling and interference management
  • Cloud
  • Clean


  • H/W accelerator for L1 function FFT/IFFT channel encoding/decoding
  • “Recent Progress on C-RAN Centralisation and Cloudification” Chih-Lin I
  • CPRI compression
  • RAN and core within the shared NFV platform -> closer to each other and remove the sharp demarcation line that has separated the two.


  • One fiber connection provides 6Gbps
  • 9.8Gbps per carrier(FA). Doubled for bi-direction.
  • 3 carrier = 9.8G23 = 58.8Gbps
  • CPRI compression ration 50%
  • WDM(Wavelength-Division Multiplexing) : fewer finer connection compared to dark fiber which is native frontal solution that has the best performance
  • Three way for C-RAN/v-RAN adoption
    • Reduce frontal requirements by using functional split – enable some functions to be virtualised while the others remain distributed
    • Improve the efficiency of the fronthaul – pack more traffic
    • Use wireless alternative where fiber is not unavailable or too expensive

Dark-Fiber alternative

  • OTN(Optical Transport Network)
  • PON(Passive Optical Network)
  • CPRI over Ethernet(CoE)
    *outdoor small cell frontal in dense urban areas

    • higher latency than Dark-fiber
  • Wireless
    • outdoor small cell frontal
    • Suitable for short distance and relatively low capacity requirement

CPRI alternative

  • CPRI : 0.4ms latency, very low jitter
    • But not standard-based
    • ETRI’s ORI – Standardized CPRI for interoperability
  • Ethernet : should be carefully managed end-to-end to meet the CPRI’s performance

Split funtionalities

Functional split to reduce fronthaul requirement
PHY is L1 function which requires FFT/IFFT


Need 20-50x bandwidth than PHY-MAC
eICIC and CoMP can be implemented effectively, so the C-RAN can manage interference effectively.


  • Coordinated transmission can not implemented in the pooled BBU as there are L1 functions instantiated at the cell sited(PHY)
  • Macro-only network, this can be acceptable trade-off

Central scheduler based scheduling can be another option. MAC-level coordination among cells has lower latency and bandwidth requirements and ethernet can be used for this.

Functions in each layer

  • L3
    • Control RRC
  • L2
    • PDCP
    • RLC
    • Transport MAC
  • L1
    • CoMP
    • eICIC
    • Channel decoding/coding
    • Quantization/De-
    • Resource Block mapping
    • Sampling/De-
    • Modulatio/De-
    • FFT/iFFT

Cost reduction with vRAN

  • 30% in capex – mainly from equipment and installation cost
  • 54% in opex – lower site rental
  • Resource utilization
  • Mobility management
  • Robust interference management

Leveraging uneven traffic distribution


nDPI : Open-Source High-Speed Deep Packet Inspection pdf

논문을 다 읽고 나니 ntop을 만든 곳에서 만든 거라는 걸 알게 되었다.

기존에 존재하는 OpenDPI가 개발자가 상용화로 방향을 바꿔 더 이상 관리가 되지 않아 이를 개량한 것이 nDPI라고.
철저하게 open source로 개발하고, OpenDPI가 제공하지 않는 meta data extraction도 제공한단다. Open source로 개발하는 이유는 DPI 특성상 계속해서 라이브러리의 개량이 필요한데 한 두 사람이 할 수 있는 일이 아니라고 생각했기 때문이라고. 물론 상용화를 해서 그 일만 담당하는 직원이 있어도 가능하겠지만, 현실적으로 기존에 존재하는 major vendor와의 경쟁을 생각하면 그리 쉬운 일은 아닐 거다. 기존 업체가 제공하지 않는 기능을 제공하거나 정확도 혹은 성능이 좋은 제품을 제공하면서 동시에 많은 protocol을 인식해야 할 텐데 그럴려면 많은 투자가 필요한데 기능, 성능의 우수성은 차지하고 protocol 개수는 닭과 달걀의 문제가 될 수 있다. 그런 면에서 open source로 개발한 것은 좋은 판단이라고 생각되는데 nDPI를 이용한 reference system의 발굴이 더욱 중요하다.

DPI is a time-consuming activity as protocols (in particular P2P) change quite often. This means that it’s necessary to update the code from time to time and add extensions. We would encourage anyone out there to help us adding or enhancing new protocols: we will put your contributions on our SVN and make them available to everyone free of charge. In fact the main reason why we decided to go for nDPI instead of using the original library, is that the company behind OpenDPI has never replied to our offers to merge the extensions we coded onto the original source code

C로 작성되어 있고, core library와 plugin dissector로 구성되어 있다(Wireshark과 유사한 구조. Wireshark도 지속적으로 추가될 프로토콜을 지원하기 위해 이런 구조를 가지고 있다)

OpenDPI가 가졌던 non-thread safe 구조를 개선해서 많은 global 변수 등을 제거했다고.

동적으로 configuration을 변경할 수 있어 동작 중에도 protocol header만으로 판단할 수 있는 경우를 손쉽게 추가할 수 있다고(반면 OpenDPI는 모든 지원 프로토콜은 dissector를 가져야 한다고 가정해서 새로운 프로토콜을 지원하려면 무조건 라이브러리를 변경해야 했다고. 반면 nDPI는 configuration을 통해 TCP/port-X는 protocol Y와 같이 추가할 수 있다고)

nDPI는 linux kernel 혹은 user-space application으로 사용할 수 있음.

잘 알려진 UDP 기반 프로토콜 – DNS, NetFlow 그리고 SNMP등은 1개 패킷만으로 판단이 가능하지만, BitTorrent는 8개 가량의 패킷이 필요했다고

HTTPS의 경우 초반에 SSL 동작에 필요한 initial key exchange를 분석해서 판단한다고. 이때 접근하는 서버의 이름을 통해 대략적인(?) 서비스를 추정한다고.

The trend of Internet traffic is going towards encrypted content often using SSL. In order to let nDPI support encrypted connections, we have added a decoder for SSL (both client and server) certificates, thus we can figure out the protocol using the encryption certificate. This allows us to identify protocols such as Citrix Online and Apple iCloud that otherwise would be undetected.

필요한 경우 IP 기반의 검출도 수행. iTunes나 iMessages는 Apple이 소유한 IP주소의 서버로 메시지를 보내므로 이 정보를 활용


ZeroMq aka ZMQ.

Message-oriented communication

기존의 BSD socket이 Stream(TCP) 혹은 Datagram(UDP) 의 2가지 서로 다른 방식을 제공하고, 각각의 socket을 사용하기 위해서는 socket을 여는 함수인 socket()을 제외하곤 서로 다른 API를 사용해야 했다. 이와 달리 ZeroMq는 Message oriented 통신 방법이라고.

ZMQ의 특징을 기술한 말을 보면

abstract some of the low-level details of different socket types, connection handling, framing or even routing
zero-copy semantics, optimized framing and no locking data structure

TCP와 달리 application에서 buffering이나 framing을 고민할 필요가 없다고.

Feature list는 여기 참고

Stream/Datagram 방식에서 message-oriented model로 변경한 것이 어떤 의미가 있는 지 실감되지 않는데… 특징을 보면 충분히 매력적으로 보인다.


  • Transport agnostic sockets
  • In-process, IPC, multicast, TCP 등을 지원하고, 4가지 방식 사이에서 원하는 방식으로 간단하게 바꿀 수도 있고, 동시에 두 가지 이상의 방식을 사용할 수도 있는 듯
  • 덕분에 처음 한 가지 방식으로 구현한 후 필요에 따라 다른 방식으로 변경하는 것이 bind 명령어 옵션만 바꾸면 된다고.
  • Routing & Topology aware sockets
  • 하나의 socket이 2개 이상의 다른 port에 bind해서 메시지를 수신할 수도 있고, 하나의 API 호출로 서로 다른 여러 socket에 메시지를 보내는 것도 가능하다
  • Publisher/Subscriber – unidirectional from publisher to subscriber. 하나의 send 호출이 모든 subscriber에 메시지를 보냄.
  • Request/Reply – bidirectional. 하나의 server에 여러 client가 연결되어 있을 때는 자동으로 message는 load balancing되어 오직 하나의 client에만 전달 될 수 있다. (FIXME. 어떤 방식으로 load balancing selection되는 지 확인 필요)
  • Push/Pull – unidirectional and load balanced.
  • 별도의 message broker나 load balancer가 필요하지 않음.

ZMQ socket을 열면 library 내부에서 하나의 I/O thread를 생성하고, 이 thread가 connection setup, teardown, reconnect 등을 수행함.

활용 예) Mongrel 2

외부에서의 request를 처리하기 위해 request를 받은 후 Push/Pull 형태의 ZMQ 소켓을 이용하여 여러 client중 하나에게 보내 처리하게 함. 별도로 application에서 load balancer를 구현할 필요가 없어 간단함.


출처 ZeroMQ : Modern & Fast Networking Stack


예전에 같이 일하던 직원이 수년 전에 퇴사했는데 어쩌다 보니 최근 각광받고 있는 어떤 기술에 대한 국내 첫번째 책의 공동저자였다.

난 그동안 뭘 한거지? 사내 정치에 환멸을 느끼며, 불합리한 프로세스에 불만만 가지고 있었지 정작 제대로 아는 게 없다.

자괴감이 든다.

Open Source NFP

NFV Approaches Phase 2, With Help from the Linux Foundation

ETSI는 코드를 만들어내지 않지만, 이제 대략적으로 뭘 원하는 지 정리가 되었으니(아직 NFV Group Specifciation 업데이트 된 게 나와야겠지만) 실제 동작하는 코드가 필요하다고. OpenDayLight(ODL)이 그랬던 것처럼 실제로 동작하는 Reference code가 있어야 개발 속도를 높일 수 있다. 문제(?)는 ODL이 그랬던 것처럼 하나의 reference system이 만들어지면 그 reference system과는 다른 것들은 모두 죽어버린다는 것.

이번에도 Linux Foundation이 실질적인 리드를 하기 위해 7/1일에 AT&T, HP, Intel, Linux Foundation 담당자들이 모였다고 한다.Open Source NFV Plans

응답하라 2000년


Network Processor Era

Intel에서 요즘 한창 주가를 올리고 있는 SDN, NFV 관련해서 어떻게 하든 입자를 굳히려고 노력하고 있다. Intel은 2000년 초반 Digital Semiconductor라는 회사로부터 인수한 기술을 이용해서 IXP라는 Network Processor를 앞세워 네트웍 시장에 진입하려고 노력했다1. 당시에는 그 전까지 있던 Asic 기반에서 벗어나 programmable processor를 이용한 네트웍 장비를 만드는 것이 유행이었는데 당시만 해도 괜찮았던 Motolora도 C-port라고 불리는 Network Processor를 판매하고 있었다.2 C-port는 C5, C3e등의 제품이 있었는데 당시에 C를 이용해서 프로그래밍할 수 있는 장점을 가지고 있었다. 하지만 몇 년 후에 사업을 접어버렸다. PowerPC 계열의 시장 점유율 확대 실패가 원인이었던 걸로 기억한다. 기억에는 이렇게 Network Processor 시장을 정리하면서 핸드폰 사업과 나머지 네트웍 사업 그리고 Processor 사업을 분리한 듯.

아무튼 Intel IXP는 1200, 2400 계열을 거쳐 2800, 2350, 2805까지 만들고 역시 사업을 접어버렸다. 1200, 2400,280x 계열은 주로 micro-code로 코드를 작성했다. 나중에 나오고 상대적으로 낮은 성능을 보여주는 IXP2300 계열은 고객 대상 자체가 달라 microC로 작성했다. microC는 말 그대로 C 문법을 사용하는데 Network Processor상황에 맞게 일부 제약을 가진 언어였다.

인생은 쓰다

그 전까지 desktop 시장에서의 절대적인 우위를 바탕으로 새로운 시장인 Network 시장으로 시장 지배력을 확대하려던 Intel의 노력은 아무튼 2007년 IXP를 Netronome에 매각하면서 실패로 끝났다. 3

그 후에 Intel은 handheld나, HPC등 desktop 외의 시장에 들어가려고 지속적으로 노력했지만 딱히 성공한 것은 없다. nVidia와 경쟁하기 위해 manycore인 Phi processor도 만들고 있지만 시장에서의 반응은 그닥인 듯.

하지만 주로 Arm processor를 사용하는 모바일 시장의 확대로 줄어드는 desktop 시장과 달리 Intel에게 유리한 시장 변화는 바로 서버 시장이 커진다는 점이었다. 종종 외계인을 잡아서 일을 시켰다고 하는 Xeon 기반의 고성능 x86 CPU 시장은 어느새 x86 경쟁업체였던 AMD와는 비교조차 할 수 없을 정도로 독보적인 위치가 되었다. 모바일 단말기가 늘어나는 만큼 그 단말기를 이용하는 서비스를 제공하는 서버들은 대부분 Intel 서버를 이용하고 있다.

절치부심 – I’ll be back

Intel은 IXP를 이용한 network 시장 진출에 대한 아쉬움을 그대로 삭힐 수 없었는지 다시 시장 진출을 노린다. 전문이 아닌 다른 업체를 인수하기 보다는 자기가 가장 잘하고 강점을 갖는 Xeon Processor를 기반으로.
시장의 대세는 Intel CPU + Linux 조합인데, 서버 쪽은 Linux가 제공하는 네트웍 기능을 그대로 이용하고 그 위에 Java 등을 이용해 서버 앱을 만들어도 충분(?)하지만 Network 시장은 그 정도의 성능으로는 어림도 없는 곳이었다. 그래서 Intel은 Linux를 아예 걷어내거나(Bare-metal) 혹은 Linux app을 동작하지만 성능 제약의 근본적인 원인이 되는 interrupt 기반/General networking stack/Memory copy between kernel and user space를 회피한 방법을 사용한 네트웍 S/W 개발용 framework을 내놓는다. 이게 Intel DPDK(Data Plane Development Kit)이다.

시장의 변화 – 천우신조

때마침 최근 시장은 서버 + 가상화 + COTS(Commodity Off The Shelf)로 점점 진화하고 있는 상황이다. 덕분에 이 3가지 측면에서 모두 강점을 갖고 있는 Intel은 Desktop 시장의 폭발적인 성장 이래 처음으로 호기를 맞이한다. 통신 시장에서 업체가 만드는 전용 하드웨어를 기반으로 하는 제품을 사야하고, 새로운 기능이 추가되거나, 제품의 모델이 바뀔 때마다 제품의 교체 사이클을 제조업체에 의존해야 했던 통신 서비스 업체는 상용 H/W를 사용하고, (부가적인 H/W accelerator를 이용하는) S/W만으로 구현되는 장비를 갈구하게 된다. 그 결과 NFV(Network Function Virtualization)이라는 규격을 만들게 된다. NFV의 핵심은 장비를 이용한 혁신의 주도권을 장비 업체가 아니라 통신 업체가 완전히 가져가겠다는 의도이고, 아울러 상용 하드웨어를 사용하여 장비 업체에 대한 의존성을 줄여 비용도 줄이겠다는 의도에서 시작되었다. 장비 업체 입장에서는 아쉽지만 물건을 구매하는 쪽인 갑들이 모여 단결하여 시장을 의도적으로 몰아가고 있어 장비 업체로써는 저항하기가 쉽지 않다. 거기에 장비 업체에서도 선두 업체들이 시장의 변화를 인정하고, 새로운 시장을 선점하기 위해 노력하기에 2위, 3위 업체 등은 쉽게 대세를 거스를 수 없는 상황이다. 거기에 대세를 거스른 다는 것은 결국 제품을 구매하는 통신 업체의 의도를 거스르겠다는 것이므로, 더더욱 쉽지 않은 상황이다.

이렇게 통신 업체가 열심히 NFV를 미는 이유는 앞에서 말한 대로 장비 업체로부터의 주도권을 더욱 가져오겠다는 의도이다. 물론 통신업체가 돈을 지불하는 입장이므로 ‘갑’의 위치에 있는 것은 사실이지만, 어떤 면에서는 통신 업체가 요구하는 혁신적인 기능이 장비 업체의 이익과 대치되는 경우 쉽게 원하는 혁신을 얻기 어려운 점도 있을 것이다. 큰 시장 점유율을 가지는 장비 업체일 수록 그 만큼 자신의 입장을 주장하는 경우도 있을 테니.

그러나 앞에서 말한 것과 같이 장비 업체가 아닌 일반 서버 기반 위에 S/W만으로 원하는 제품을 만들 수 있다면 극단적으로 서버는 HP, Dell 등의 업체로부터 공급받고, S/W는 시장 진출을 엿보는 작은 업체로부터 공급받을 수 있는 것이다. 그것이 통신 업체가 원하는 혁신이다.

Intel로써는 이런 시장의 변화를 예측(?)하고 준비한 덕에 자사의 x86 processor를 이용하면서 고속 성능을 제공할 수 있는 DPDK를 핵심 전략으로 삼고 있다.

NFV – 새로운 기회

NFV에서는 기존 Network Function들을 VNF(Virtual NF)로 부르고, 모두 VM(Virtual Machine)에서 동작하는 것으로 정의한다. 이때 필요한 기능 중 하나가 VM과 서버 외부 혹은 VM간의 고속 switching이다. ‘고속’이란 말만 제외하면 이미 Linux 커널에 포함되어 있는 KVM에서 제공하는 vSwitch 가 존재한다. vSwitch는 Virtual Switch로 서버 내에서 S/W로 구현되는 switch다. OVS(Open VSwitch)가 많이 사용되는 커널내에서 동작하고 기본적으로 발생하는 VM – Host간 오버헤드 덕에 낮은 성능을 보인다. NFV를 통해 이미 다진 서버 시장과 네트웍 시장에서의 선점을 원하는 Intel로써는 해결해야 할 문제점이다. (그렇다고 다른 Processor가 대안을 가지고 있는 것은 아니다. 모바일 단말기에서의 절대적인 시장 점유율을 기반으로 서버 시장까지 진출하려는 ARM processor 역시 근본적으로는 동일한 제약을 갖는다)
이를 해결하기 위해 Intel은 직접 자원을 투자하여 OVS를 이용하여 성능을 높이는 작업을 진행한다. 커널내에서 동작하는 OVS의 switch 기능을 DPDK 기반으로 구현하여 고속의 스위칭 기능을 제공하는 것이다. S/W 기반이기 하지만 다양한 기능을 제공하기 위해 복잡하게 만들어진 Linux Networking stack과 달리 필요한 일만 하도록 만들어진 그 결과 많은 제약을 갖지만 높은 성능을 제공하는 DPDK-OVS가 만들어진 것이다.

앞에서 말한 VM-Host간의 통신에 성능 저하를 유발하는 여러가지를 해결하기 위해 그리고 VM-Host Kernel Switch가 아니라 VM – Host user level switch(DPDK로 구현된 DPDK-OVS 는 user-space에서 동작)간 통신으로 인해 추가로 발생하는 overhead를 줄이기 위해 IVSHMEM(Inter-VM Share Memory)를 사용한다.