DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices
Date: Mon, 29 Sep 2014 11:05:53 +0100	[thread overview]
Message-ID: <20140929100553.GA12072@BRICHA3-MOBL> (raw)
In-Reply-To: <20140926140855.GD3930@hmsreliant.think-freely.org>

On Fri, Sep 26, 2014 at 10:08:55AM -0400, Neil Horman wrote:
> 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

While not wanting to get too involved in the discussion, I'd just like to 
express my support for getting this new PMD merged in.

/Bruce

  reply	other threads:[~2014-09-29  9:59 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-10 20:32 [dpdk-dev] [PATCH] " John W. Linville
2014-07-11 13:11 ` Stephen Hemminger
2014-07-11 14:49   ` John W. Linville
2014-07-11 15:06     ` Richardson, Bruce
2014-07-11 15:16       ` Stephen Hemminger
2014-07-11 16:07         ` Richardson, Bruce
2014-07-11 15:29       ` Venkatesan, Venky
2014-07-11 15:33         ` John W. Linville
2014-07-11 16:29           ` Venkatesan, Venky
2014-07-11 13:26 ` Thomas Monjalon
2014-07-11 14:51   ` John W. Linville
2014-07-11 15:04     ` Thomas Monjalon
2014-07-11 15:30       ` John W. Linville
2014-07-11 16:47         ` Thomas Monjalon
2014-07-11 17:38           ` Richardson, Bruce
2014-07-11 17:41             ` John W. Linville
2014-07-12 11:48           ` Neil Horman
     [not found] ` <D0158A423229094DA7ABF71CF2FA0DA3117D3A23@shsmsx102.ccr.corp.intel.com>
2014-07-11 17:20   ` Zhou, Danny
2014-07-11 17:40     ` John W. Linville
2014-07-11 18:01       ` Zhou, Danny
2014-07-11 18:46         ` John W. Linville
2014-07-12  0:42           ` Zhou, Danny
2014-07-14 13:45             ` John W. Linville
2014-07-11 19:04       ` Zhou, Danny
2014-07-11 19:31         ` John W. Linville
2014-07-11 20:27           ` Zhou, Danny
2014-07-11 20:31             ` Shaw, Jeffrey B
2014-07-11 20:35               ` Zhou, Danny
2014-07-11 20:40                 ` John W. Linville
2014-07-11 22:34       ` Thomas Monjalon
2014-07-14 13:46         ` John W. Linville
2014-07-15 21:27           ` Thomas Monjalon
2014-07-16 12:35             ` Neil Horman
2014-07-16 13:37               ` Thomas Monjalon
2014-07-16 14:07             ` John W. Linville
2014-07-16 14:26               ` Thomas Monjalon
2014-07-16 15:59                 ` Shaw, Jeffrey B
2014-07-11 22:30 ` Thomas Monjalon
2014-07-14 17:53   ` John W. Linville
2014-07-11 22:51 ` Bruce Richardson
2014-07-14 13:48   ` John W. Linville
2014-07-14 17:35     ` John W. Linville
2014-07-14 18:24 ` [dpdk-dev] [PATCH v2] " John W. Linville
2014-07-15  0:15   ` Zhou, Danny
2014-07-15 12:17     ` Neil Horman
2014-07-15 14:01       ` John W. Linville
2014-07-15 15:40         ` Zhou, Danny
2014-07-15 19:08           ` John W. Linville
2014-07-15 20:31         ` Neil Horman
2014-07-15 20:41           ` Zhou, Danny
2014-07-15 15:34       ` Zhou, Danny
2014-09-12 18:05   ` John W. Linville
2014-09-12 18:31     ` Zhou, Danny
2014-09-12 18:54       ` John W. Linville
2014-09-12 20:35         ` Zhou, Danny
2014-09-15 15:09           ` Neil Horman
2014-09-15 15:15             ` John W. Linville
2014-09-15 15:43             ` Zhou, Danny
2014-09-15 16:22               ` Neil Horman
2014-09-15 17:48                 ` John W. Linville
2014-09-15 19:11                   ` Zhou, Danny
2014-09-16 20:16     ` Neil Horman
2014-09-26  9:28       ` Thomas Monjalon
2014-09-26 14:08         ` Neil Horman
2014-09-29 10:05           ` Bruce Richardson [this message]
2014-10-08 15:57             ` Thomas Monjalon
2014-10-08 19:14               ` Neil Horman
2014-11-13 10:03                 ` Thomas Monjalon
2014-11-13 11:14                   ` Neil Horman
2014-11-13 11:57                     ` Thomas Monjalon
2014-11-14  0:42                       ` Neil Horman
2014-11-14 14:45                         ` John W. Linville
2014-11-17 15:57                           ` [dpdk-dev] [PATCH v3] librte_pmd_af_packet: " John W. Linville
2014-11-24 16:16                             ` Thomas Monjalon
2014-11-17 11:19                       ` [dpdk-dev] [PATCH v2] librte_pmd_packet: " Neil Horman
2014-11-17 11:22                         ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140929100553.GA12072@BRICHA3-MOBL \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=nhorman@tuxdriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).