From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by dpdk.org (Postfix) with ESMTP id 596C55A85 for ; Fri, 8 May 2015 18:17:34 +0200 (CEST) Received: by pdbnk13 with SMTP id nk13so89211933pdb.0 for ; Fri, 08 May 2015 09:17:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=pZspWi2+TG+zzRvUIFYCpamKgXVroUjPZn5emO+7Py0=; b=Kj/chB6fu+efCGbJdFW4diCg1MT3/9HzgWuwUNkokQlch2aO4pqyVi5tVmiUb+Urv1 FMNvz8TUzL5QF/AYi8GfS7HjXBzNbPzoaZhbt7cYo6ayqlTnL/ih19IKCnRrrubTubZH wO0hgMmBbIs+eC9ywD3CScn9OcSlRM09jH2ipRFJfMbeqR6QvLy8UpwDpnnzOP4tXR01 ef9uAdy4x4DCRRcySTaj3r0vcdwgYDbwJ9jfgcQ8f1xqFIRWMLPnhy7aU37MyvezoaUO USpl6Ru7HX85DWIFA3ummDGD+KkjpppsJ2/ygw5Hs3FPurB8EMRuo9EnAI2wazQPW9Om dmGg== X-Gm-Message-State: ALoCoQlnHAm9AIhuB+k9JbElOUVXtJc1t2p5p/oofh2Sr1v+0TqjaCktk99WWmFlJwIr6amYSwhK X-Received: by 10.66.249.168 with SMTP id yv8mr7810517pac.49.1431101792009; Fri, 08 May 2015 09:16:32 -0700 (PDT) Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by mx.google.com with ESMTPSA id pp6sm5644401pbb.17.2015.05.08.09.16.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 May 2015 09:16:31 -0700 (PDT) Date: Fri, 8 May 2015 09:16:35 -0700 From: Stephen Hemminger To: "Wiles, Keith" Message-ID: <20150508091635.03872bce@urahara> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 16:17:34 -0000 On Fri, 8 May 2015 14:44:17 +0000 "Wiles, Keith" wrote: > 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. The point is this is BSD code, you can do with it what you will. But the DPDK community doesn't have to care about changes breaking your proprietary application. That is the problem with the whole concept of making DPDK drivers a separate component. It makes them immutable and unmaintainable. Developers don't want to be responsible for code that is used outside its original scope.