From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id AFDE55A4F for ; Fri, 8 May 2015 11:06:51 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 08 May 2015 02:06:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,389,1427785200"; d="scan'208";a="725862294" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.43]) by orsmga002.jf.intel.com with SMTP; 08 May 2015 02:06:46 -0700 Received: by (sSMTP sendmail emulation); Fri, 08 May 2015 10:06:45 +0025 Date: Fri, 8 May 2015 10:06:45 +0100 From: Bruce Richardson To: Luke Gorrie Message-ID: <20150508090645.GA7376@bricha3-MOBL3> 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: Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) 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 09:06:52 -0000 On Fri, May 08, 2015 at 07:29:39AM +0200, Luke Gorrie wrote: > On 8 May 2015 at 06:16, Wiles, Keith wrote: > > > The PMDs or drivers would not be useful without DPDK MBUFS IMO > > > > Surprisingly perhaps, I would find them very useful. > > To me there are two parts to a driver: the hardware setup and the > transmit/receive. > > The hardware setup is complex and generic. You have to read a thousand-page > data sheet and then write code to initialize the hardware, setup queues, > enable promisc/multicast, enable features you want like vmdq or flow > director, and so on. You need to accumulate workarounds for hard-to-test > problems like cards being discovered with unsuitable values in their > EEPROM. There is not much intellectual value in this code being written > more than once. For the Intel NIC drivers, the hardware setup part used in DPDK is based off the other Intel drivers for other OS's. The code you are interested in should therefore be contained within the subfolders off each individual PMD. As you point out below, the mbuf specific part is only present in the files in the top-level PMD folder with the DPDK-specific RX/TX and queue setup routines. Regards, /Bruce > > I would like to see this hardware setup code shared between many projects. > That code does not depend on a specific mbuf struct. Sharing could be done > with an embeddable PMD library, with a bifurcated driver in the kernel, > with the SR-IOV PF/VF model, or surely other ways too. These all have > limited applicability today. > > The transmit/receive part, on the other hand, seems very > application-dependent. This part depends on the specific mbuf struct and > the way you are developing your application around it. You will need to > write code to suit your design for using scatter/gather, allowed sizes of > individual buffers, the granularity at which you are keeping track of > checksum validity, how you use TSO/LRO, how you use interrupts, how you > batch work together, and so on. This is easy or hard depending on how > simple or complex the application is. > > I am not so interested in sharing this code. I think that different > applications will legitimately have different designs - including mbuf > structs - and they all need code that suits their own design. I think there > is a lot of value in people being creative in these areas and trying > different things. > > So while Avi might only mean that he wants to allocate the bytes for his > mbufs himself, on our side we want to design our own mbuf struct. The cost > of that today is to write our own device drivers from scratch but for now > that seems justified. Going forward if there were a simpler mechanism that > reduced our workload and gave us access to more hardware - libixgbe, > libi40e, etc - that would be extremely interesting to us. > > I suppose that another background question is whether the DPDK community > are chiefly concerned with advancing DPDK as a platform and a brand or are > broadly keen to develop and share code that is useful in diverse networking > projects. (Is this whole discussion off-topic for dpdk-devel?) > > This is one of the many reasons why I would love to use parts of DPDK but > do not want to use all of it. (We also allocate our HugeTLBs differently, > etc, because we have different priorities.)