svn commit: r308869 - head/sbin/nvmecontrol

[Warner Losh]

On Mon, Nov 21, 2016 at 1:16 PM, John Baldwin <jhb at freebsd.org> wrote:
> 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.

Yea, this is fine.

>> > 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.

No doubt. arm64 wouldn't be super hard, assuming that all the BUSDMA
stuff got done correctly and there's no weird alignment issues with
the crazy structures that nvme defines...

Warner