svn commit: r308869 - head/sbin/nvmecontrol

[John Baldwin]

On Monday, November 21, 2016 12:50:35 PM Warner Losh wrote:
> On Mon, Nov 21, 2016 at 11:07 AM, John Baldwin <jhb at freebsd.org> wrote:
> > On Saturday, November 19, 2016 09:46:13 PM Warner Losh wrote:
> >> Author: imp
> >> Date: Sat Nov 19 21:46:13 2016
> >> New Revision: 308869
> >> URL: https://svnweb.freebsd.org/changeset/base/308869
> >>
> >> Log:
> >>   i386 turns out to not have __uint128_t. So confusingly use 64-bit math
> >>   instead. Since we're little endian, we can get away with it. Also,
> >>   since the counters in quesitons would require billions of iops for
> >>   tens of billions of seconds to overflow, and since such data rates are
> >>   unlikely for people using i386 for a while, that's OK. The fastest
> >>   cards today can't do even a million IOPs.
> >>
> >>   Noticed by: dim@
> >>   Sponsored by: Netflix, Inc
> >
> > It probably has it if you compile with -march=<foo> where <foo> is new
> > enough to have SSE.
> 
> Yea, but this solution was good enough... There's also a lot of issues
> with 128bit ints in different versions of gcc and I didn't want to
> play the whack-a-mole game, so I punted.

Yes.  We don't require SSE for i386, so we're stuck handling the non-SSE
case currently.

> > Is nvme inherently x86-only?
> 
> No. However, the implementation was done by Intel, only tested on x86
> and has known issues with endian-ness. So we build only on x86.

Something of a shame as you can probably shove one of these boards in
arm64 servers.

-- 
John Baldwin