From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 03F025A85 for ; Fri, 8 May 2015 15:31:54 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YqiNQ-0001r3-Rm; Fri, 08 May 2015 09:31:49 -0400 Date: Fri, 8 May 2015 09:31:34 -0400 From: Neil Horman To: Hobywan Kenoby Message-ID: <20150508133134.GB9765@hmsreliant.think-freely.org> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D29B55@IRSMSX102.ger.corp.intel.com> <554B85D5.6010808@cloudius-systems.com> <554B8D48.7010900@cloudius-systems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Beyond DPDK 2.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 13:31:54 -0000 On Fri, May 08, 2015 at 12:26:39PM +0200, Hobywan Kenoby wrote: > > > Sounds like you want something like libc, but DPDK is a system like a user > > space OS more then it is a collection of functions that are independent > > like strlen, strcpy, memcpy, printf or ... Some parts of DPDK are > > independent and can be used as you suggest, but the real performance > > sections are tied together. > > > > >> Regards, > > >> ++Keith > > This is indeed quite a statement. DPDK is not just a > bunch of NIC drivers, but "a user space OS" (DPDK 1.0 had a baremetal > boot: why did it disappeared?). > > > > Why Linux or Windows do not integrate DPDK concepts to > catch up performance wise? Is it something so deep like the "Big > Kernel Lock" that took so many years to get rid of? > Some optimizations are being looked at in the kernel (more deeply ingrained use of accelerators/offloads like cam management/flow steering, checksum & encap offloads, tx batching, etc) Those are features which the kernel can opportunistically take advantage of in a hardware agnostic fashion. Some optimizations simply aren't worth the effort to take into a general purpose OS that seeks to support multiple arches. Many of the DPDK optimizations utilize instruction families like AVX or SSE, which, while potentially useful in some situations have equal potential to be catastrophic to non network-i/o bound workloads. > > > My assumption is that all current kernels have been > built with one implicit hypothesis: the memory is much faster than cpu. This is Thats not entirely true. Or more to the point, its not true in any way thats relevant to a comparison between DPDK and the Linux network stack. Linux is as careful with its cache management as DPDK is (arguably more so, as it has to juggle multiple workloads instead of the single purpose workload that DPDK is designed for). The difference is that Linux often has to ignore some performance improvements because it has the additional responsibiilty of providing secruity and isolation to multiple processes on multiple architectures. > the opposite today. DPDK internal structure has been adapted to the new > paradigm where the TLBs, the memory bandwidth are the scarce resources to manage. So I > guess Linux and Windows will not be able to integrate DPDK concepts for > performance anytime soon, if ever... > This is the case with every bit of software. Memory bandwidth is always a scarce resoruce to manage. The difference is that general purpose operating systems consider protection/layering/isolation to be of equal or greater importance than performance. Tradeoffs have to be made. Linux in general strives to isolate hardware from applications both functionally and physically so as to ensure that there is minimal risk in one process adversely affecting the other. The tradeoff is that the Linux device model can't just do anything it wants to improve performance. Converserly, DPDK is all about performance. Up until recently (and likely still somewhat in the future), you have to rebuild your application every time you move to a new version of DPDK, because the API fluctuated with every release to eek out additional performance. The DPDK can optimize using vectorized x86 instructions and other cpu specific features througout because it is in the position to only worry about a very narrow field of architectures. > > > Reading the list carefully, I expect disk block PMDs > (and block framework?) to come next. > > > > Beyond DPDK 2.0: is it time to accept the fact that > DPDK community is actually paving the way to the next generation lightweight, > high performance, para-virtualized OS? Is it a DPDK task? Another project ? > Should we rename DPDK to PVDK? > > > > - HK > >