From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 24B255A85 for ; Fri, 8 May 2015 16:44:22 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP; 08 May 2015 07:44:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,391,1427785200"; d="scan'208";a="725998083" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by orsmga002.jf.intel.com with ESMTP; 08 May 2015 07:44:19 -0700 Received: from fmsmsx107.amr.corp.intel.com (10.18.124.205) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 8 May 2015 07:44:18 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.26]) by fmsmsx107.amr.corp.intel.com ([169.254.6.205]) with mapi id 14.03.0224.002; Fri, 8 May 2015 07:44:17 -0700 From: "Wiles, Keith" To: Luke Gorrie Thread-Topic: [dpdk-dev] Beyond DPDK 2.0 Thread-Index: AdB4KSdm1ftzhuzCQX2G2XNq9ZOWFAE5VxLQAv6mNgD//6KBAIAAdwKA//+O+YCAAHnoAIAAVvuAgACJtYCAACWaAA== Date: Fri, 8 May 2015 14:44:17 +0000 Message-ID: References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D29B55@IRSMSX102.ger.corp.intel.com> <554B85D5.6010808@cloudius-systems.com> <554B8D48.7010900@cloudius-systems.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.128.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <69F0C7A49A5F2245AD315AF00F9FD4E9@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 14:44:23 -0000 Hi Luke, On 5/7/15, 10:29 PM, "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. > > >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 think I see your point about hardware setup and handling packets from the rings as it would be nice to allow others to utilize those parts of the code. The drivers (I believe) are mostly from FreeBSD and changed to be our PMDs, which to me they are fairly generic in some cases. I will have a look at the drivers when I get back home. In the past I have written drivers using the your suggestion around we have a upper and lower layer the lower layer is all hardware specific and the upper layer is all around the network stack interface. My point is we should be able to split the two and possible provide you the lower layer APIs in a cleaner way. > > > >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?) I would suggested you are correct DPDK as platform is more how it started and is going, but it does not mean we can not move is a slightly different direction to help other access the parts which are more generic. Regards, ++Keith > > >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.) > > > > > > >