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 0F9DD7DF0 for ; Fri, 26 Sep 2014 16:02:44 +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 1XXWCe-0007CI-63; Fri, 26 Sep 2014 10:09:04 -0400 Date: Fri, 26 Sep 2014 10:08:55 -0400 From: Neil Horman To: Thomas Monjalon Message-ID: <20140926140855.GD3930@hmsreliant.think-freely.org> References: <1405024369-30058-1-git-send-email-linville@tuxdriver.com> <20140912180523.GB7145@tuxdriver.com> <20140916201601.GF3792@hmsreliant.think-freely.org> <1743453.I5IRxog55M@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1743453.I5IRxog55M@xps13> 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] [PATCH v2] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices 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, 26 Sep 2014 14:02:44 -0000 On Fri, Sep 26, 2014 at 11:28:05AM +0200, Thomas Monjalon wrote: > 2014-09-16 16:16, Neil Horman: > > On Fri, Sep 12, 2014 at 02:05:23PM -0400, John W. Linville wrote: > > > Ping? Are there objections to this patch from mid-July? > > > > Thomas, Where are you on this? It seems like if you don't have any objections > > to this patch, it should go in, in ilght of the lack of further commentary. > > 1) It doesn't appear as a top priority. Thats your responsibility. Patches can't languish and rot on a list forever just because others aren't willing to test it. If theres further testing that you feel it needs, ask. But from my read, its been tested for functionality and performance (though high performance is never expected from a AF_PACKET PMD). Given that any one PMD will not affect the performance of another in isolation, I'm not sure what more you're waiting for here. > 2) It's competing with pcap PMD and bifurcated PMD to come > (http://dpdk.org/ml/archives/dev/2014-September/005379.html) Regarding the pcap PMD, so? Its an alternate implementation that provides different features with different limitations. The fact that they are simmilar is irrelevant. If simmilarity was the test, then we wouldn't bother with the bifurcated driver either, because the pcap pmd already exists. Regarding the bifurcated driver, you can't hold existing patches on the promise of another pmd thats comming at an indeterminate time in the future. Theres no reason not to take this now and deprecate it in the future if there is sufficient overlap with the bifurcated driver, though to my point above, they still address different needs with different limitations, so I don't see doing so as necessecary. > 3) There is no test associated with this PMD. That would have been a great comment to make a few months back, though whats wrong with testpmd here? That seems to be the same test that every other pmd uses. What exactly are you looking for? > If one of this item becomes wrong, it should go in. > > Currently, 2 projects are being initiated for validation (dcts) and > documentation. Keeping new things outside of the DPDK core makes it > clear that they have not to be supported by dcts and doc yet. > So, it is better to have an external PMD, like memnic, acting as a > staging area. > So, this brings up an excellent point - Validation and support. Commonly open source projects don't provide support at the upstream HEAD. Those items are applied and inforced by distributors. Theres no need to ensure that the upstream head is always the most performance and stable point of the tree. Its that need that keeps the development pace slow, and creates frustrations like this one, where a patch sits unaddressed for long periods of time. Commonly the workflow for most open source projects is for there to be a window of time where visual review and basic functional testing are sufficient for acceptance into the head of the tree. After the development window closes there is a stabilization period where testing/validation is done to ensure that no regressions have been encountered, optionally with a -next branch temporarily being created to accept patches for upcomming future releases. If regressions are found, its a simple matter in git to bisect back to the offending patch, allow the contributing developer an opportunity to fix the issue, or to drop the patch. Using a workflow like this we can have a reasonable balance of needs (good patch turn around time, as well as reasonable testing). We've discussed this when I posted the PMD_REGISTER_DRIVER patch months ago, and I thought you were going to move in the direction of this workflow. What happened? > During this time, keeping this PMD separately will allow you to update it > with a maintainer account in dpdk.org. I just need your SSH public key. > We've discussed this too, keeping PMDs maintained separately is a very bad idea. Doing so means developers have to constantly be aware of changes to the core tree and try to keep up individually. Integrating them all means that API changes can be easily propogated to all PMD's when needed without making work for many people. Its exactly the reason we encourage driver writers to open source drivers in Linux, because not doing so closes developers off from the free maintenence they get when optimizations are made to API's. And if you follow the development model above, you don't need to worry about implied support, as that correctly becomes a distributor issue. Neil