On Thu, 3 Mar 2016 10:11:57 +0000 Ferruh Yigit <ferruh.yigit at intel.com> wrote:
> On 3/2/2016 10:18 PM, Jay Rolette wrote: > > > > On Tue, Mar 1, 2016 at 8:02 PM, Stephen Hemminger > > <stephen at networkplumber.org <mailto:stephen at networkplumber.org>> > > wrote: > > > > On Mon, 29 Feb 2016 08:33:25 -0600 > > Jay Rolette <rolette at infiniteio.com <mailto:rolette at > > infiniteio.com>> > > wrote: > > > > > On Mon, Feb 29, 2016 at 5:06 AM, Thomas Monjalon > > <thomas.monjalon at 6wind.com <mailto:thomas.monjalon at 6wind.com>> > > > wrote: > > > > > > > Hi, > > > > I totally agree with Avi's comments. > > > > This topic is really important for the future of DPDK. > > > > So I think we must give some time to continue the discussion > > > > and have netdev involved in the choices done. > > > > As a consequence, these series should not be merged in the > > release 16.04. > > > > Thanks for continuing the work. > > > > > > > > > > I know you guys are very interested in getting rid of the out-of-tree > > > drivers, but please do not block incremental improvements to DPDK > > in the > > > meantime. Ferruh's patch improves the usability of KNI. Don't > > throw out > > > good and useful enhancements just because it isn't where you want > > to be in > > > the end. > > > > > > I'd like to see these be merged. > > > > > > Jay > > > > The code is really not ready. I am okay with cooperative development > > but the current code needs to go into a staging type tree. > > No compatibility, no ABI guarantees, more of an RFC. > > Don't want vendors building products with it then screaming when it > > gets rebuilt/reworked/scrapped. > > > > > > That's fair. To be clear, it wasn't my intent for code that wasn't baked > > yet to be merged. > > > > The main point of my comment was that I think it is important not to > > halt incremental improvements to existing capabilities (KNI in this > > case) just because there are philosophical or directional changes that > > the community would like to make longer-term. > > > > Bird in the hand vs. two in the bush... > > > > There are two different statements, first, code being not ready, I agree > a fair point (although there is no argument to that statement, it makes > hard to discuss this, I will put aside this), this implies when code is > ready it can go in to repo. > > But not having kernel module, independent from their state against what > they are trying to replace is something else. And this won't help on KNI > related problems. > > Thanks, > ferruh > Why not re-submit patches but put in lib/librte_eal/staging or similar path and make sure that it does not get build by normal build process.