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 4230F2C29 for ; Sat, 12 Aug 2017 20:20:02 +0200 (CEST) Received: from [2606:a000:111b:4246:c188:d3ee:2a20:ab18] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1dgb0j-0000Bu-VK; Sat, 12 Aug 2017 14:19:58 -0400 Date: Sat, 12 Aug 2017 14:19:45 -0400 From: Neil Horman To: Bruce Richardson Cc: dev@dpdk.org Message-ID: <20170812181944.GA23421@neilslaptop.think-freely.org> References: <20170809202132.GA13981@hmswarspite.think-freely.org> <20170811202923.GA71096@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170811202923.GA71096@bricha3-MOBL3.ger.corp.intel.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Score: -2.9 (--) X-Spam-Status: No 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: Sat, 12 Aug 2017 18:20:03 -0000 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 > Regards, > /Bruce. >