From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 9BE9F90F7; Mon, 14 Aug 2017 12:58:25 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP; 14 Aug 2017 03:58:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,372,1498546800"; d="scan'208";a="137161603" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.24]) by orsmga005.jf.intel.com with SMTP; 14 Aug 2017 03:58:22 -0700 Received: by (sSMTP sendmail emulation); Mon, 14 Aug 2017 11:58:21 +0100 Date: Mon, 14 Aug 2017 11:58:21 +0100 From: Bruce Richardson To: Neil Horman Cc: dev@dpdk.org, techboard@dpdk.org Message-ID: <20170814105821.GB8112@bricha3-MOBL3.ger.corp.intel.com> References: <20170809202132.GA13981@hmswarspite.think-freely.org> <20170811202923.GA71096@bricha3-MOBL3.ger.corp.intel.com> <20170812181944.GA23421@neilslaptop.think-freely.org> <20170814093215.GA12020@bricha3-MOBL3.ger.corp.intel.com> <20170814105040.GA12676@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170814105040.GA12676@hmswarspite.think-freely.org> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.8.3 (2017-05-23) Subject: Re: [dpdk-dev] Announcement of SSE requirement change in dpdk X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 10:58:26 -0000 On Mon, Aug 14, 2017 at 06:50:40AM -0400, Neil Horman wrote: > On Mon, Aug 14, 2017 at 10:32:15AM +0100, Bruce Richardson wrote: > > On Sat, Aug 12, 2017 at 02:19:45PM -0400, Neil Horman wrote: > > > On Fri, Aug 11, 2017 at 09:29:24PM +0100, Bruce Richardson wrote: > > > > On Wed, Aug 09, 2017 at 04:21:32PM -0400, Neil Horman wrote: > > > > > Can anyone point out to me when and where the change to require SSE4.2 was > > > > > dicussed? The first I saw of it was when the commit to the release notes went > > > > > in on August 3, and I can find no prior mention of it, save for the patches that > > > > > went in separately in the prior weeks. > > > > > > > > > > Neil > > > > > > > > > There was no real widespread discussion of it, if that's what you are > > > > looking for. I made the proposal via patch, and it was reviewed and > > > > acked by a number of folks, with nobody raising any objections at the > > > I had a feeling that was the case, and yes, that does concern me somewhat. In > > > this particular case I think its ok, because I can't really imagine anyone using > > > older atom processors, but I think it could become problematic in the future If > > > that support line moves too far into territory in which theres downstream > > > support issues (with things like OVS or other tree-external applications) > > > > > > > time. Possibly it was a change that should have been more widely > > > > publicised ahead of time, but I'm not sure what form that publicization > > > > should have taken, since all tech discussion happens on the dev mailing > > > > list anyway. > > > > Not that I'm planning any similar changes, but for the future, what do > > > > you think the process for changes like this should be - and what changes > > > > would classify for it? If we have a process problem, let's try and fix > > > > it. > > > > > > > > > > I don't rightly know, to be honest. DPDK is a little unique in this situation, > > > since user libraries are built to just access the lowest common denominator of a > > > given arch. And in many ways, so is the kernel. I'm open to suggestions, but I > > > think so some sort of plan would be a good idea. These are just off the top of > > > my head, and likely have drawbacks, but just to get some conversation started: > > > > > > 1) Use extendend ISA instructions opportunistically > > > By this I mean to say, we could implement an alternatives system, > > > simmilar to what we have in the kernel, which can do dynamic instruction > > > replacement based on a run time test. For example, you can write two versions > > > of a function, one which impements its method with sse4 and another version > > > which does the same thing using core isa instructions). If sse4 is available at > > > runtime, the sse4 variant is mapped in, else the other version is. > > > This is something we sort of talked about before, and while theres been > > > general support in its philosophy, its the sort of thing that takes alot of > > > work, and it is only used in those cases where you know you can use the > > > acceleration. > > > > > > 2) Limit where you introduce hardware deprecation > > > Perhaps hardware deprecation can be announced in the same way ABI > > > deprecation is, and then introduced at a later date (I would make an opening > > > argument for the next LTS release). Using the LTS release as a deprecation > > > point is nice because it lets downstream consumers standardize on a release > > > without having to worry about hardware support going away. > > > > > > Just my $0.02. food for thought > > > Neil > > > > > I think the ABI deprecation policy suggestion is a good one, where if we > > want to drop support for some HW that was otherwise supported, we should > > announce it at least one release in advance to make sure everyone is > > aware of it. > > > > Ok, I can agree with that. Are we also agreed on limiting hardware deprecation > to LTS release points? > Neil > To be clear, you think any hardware deprecation should be done as part of the LTS release, rather than just after one? I would have thought the latter, so as to keep legacy HW support around for as long as possible, but I won't have a problem either way. If you think it's a good policy to have a fixed point at which any HW deprecations happen, I don't have an objection to that, but I'm curious as to whether others think it may be too restrictive. It's not something we've had a lot of up till now to know how big a deal such a restriction might be. +techboard: I suggest the tech board take an agenda item to ratify and assign owner to document a HW deprecation policy, based on this thread, at it's next meeting. /Bruce