On 3/3/2016 4:59 PM, Stephen Hemminger wrote: > 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. > I will do when staging is ready/defined.
Also will start working on upstreaming modules. Thanks, ferruh