From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by dpdk.org (Postfix) with ESMTP id 58E835A45 for ; Fri, 8 May 2015 07:29:40 +0200 (CEST) Received: by widdi4 with SMTP id di4so14976577wid.0 for ; Thu, 07 May 2015 22:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=EiqwVQyRhDQzKLfHUYBGn8mN3+gBc17rgyXH8I8OCCE=; b=Ivn0DuWLOR3qxMQQ5D7+u3bT3DOZuHJNfvAuSIhpl/DbGPG7AFYzacl4+8fc7o+Vca 6EfUKbfk+5QGE+VCX4GbPad4H5FFosler3WMoWMjurtYxNEJicZthSYumHd4DBRlWuIp TcE1/RtXkazKHoO9t7Pa9iFY/7saXy0aD8mKnNwj7fbxohu+bXMjBxNgqerwGkN1WSQL jZrwvgtFKBmUGzW+ZSo/UCBUlxQVvQuO7KG8tGk3gX23uTKGu1xnFuVUoHDoYjKEh8IX AAqwmn4APgVwdKGW6urjPfxJU+/DPvQFKTDQaznXh9l4OxXDUhX0llbe4YGT8yhuQql0 K2AA== MIME-Version: 1.0 X-Received: by 10.180.100.227 with SMTP id fb3mr2851160wib.90.1431062980149; Thu, 07 May 2015 22:29:40 -0700 (PDT) Sender: lukego@gmail.com Received: by 10.27.134.198 with HTTP; Thu, 7 May 2015 22:29:39 -0700 (PDT) In-Reply-To: References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D29B55@IRSMSX102.ger.corp.intel.com> <554B85D5.6010808@cloudius-systems.com> <554B8D48.7010900@cloudius-systems.com> Date: Fri, 8 May 2015 07:29:39 +0200 X-Google-Sender-Auth: LvmYB-Vu9OUyCLLbAF967aqj95k Message-ID: From: Luke Gorrie To: "Wiles, Keith" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 05:29:40 -0000 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 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.)