Re: [dpdk-dev] Announcement of SSE requirement change in dpdk

[Neil Horman <nhorman@tuxdriver.com>]

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

> /Bruce
>