I don't think such infrastructure is needed for simple test code like this. 128 is more than enough.
On Fri, May 27, 2016 at 1:51 PM, Ngie Cooper (yaneurabeya) <yaneurab...@gmail.com> wrote: > >> On May 27, 2016, at 13:34, Conrad Meyer <c...@freebsd.org> wrote: >> >> On Fri, May 27, 2016 at 1:12 PM, Garrett Cooper <n...@freebsd.org> wrote: >>> Author: ngie >>> Date: Fri May 27 20:12:32 2016 >>> New Revision: 300868 >>> URL: https://svnweb.freebsd.org/changeset/base/300868 >>> >>> Log: >>> Remove note about bogus chain-len maximum >>> >>> There's no current limit on chain-len with Broadwell DE chips; it isn't >>> enforced in software, and there doesn't appear to be a hardware limitation >>> either on the Intel Xeon D-1527 (Broadwell-DE) chip. >> >> Hi Ngie, >> >> The note isn't bogus, it's just not what you think it is—the limit is >> in the ioat_test code, not a limit of the hardware. >> >> Before this commit which documented it (r289733), the limit *was* 4. >> However, in the same commit I bumped the limit up to 128 >> (IOAT_MAX_BUFS / 2). (I suspect I wrote the documentation first, >> before deciding to raise the limit.) >> >> So the current limit is 128, and should be documented. > > Ah… that makes sense. Would it be a better idea to make this limit into a > readonly sysctl in ioat_test(4), along with the other limits? If so, I’ll put > that out for CR. > Thanks, > -Ngie _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
