Page MenuHomeFreeBSD

nvme: Allow larger user request sizes
ClosedPublic

Authored by imp on Mar 3 2026, 8:20 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Apr 12, 8:32 PM
Unknown Object (File)
Sat, Apr 11, 2:50 AM
Unknown Object (File)
Sun, Apr 5, 3:41 PM
Unknown Object (File)
Sun, Apr 5, 1:14 PM
Unknown Object (File)
Sat, Apr 4, 12:34 AM
Unknown Object (File)
Tue, Mar 31, 7:57 PM
Unknown Object (File)
Sun, Mar 29, 12:56 PM
Unknown Object (File)
Mar 15 2026, 6:10 PM
Subscribers

Details

Summary

We have a small buffer for pages on the stack, but if the user wants to
do an I/O larger than this we currently fail w/o a way for the user to
know the max size. It's not hard to allocate an array for the uncommon
case of very large I/Os, and the performance advantage of the array is
small in that case anyway.

Sponsored by: Netflix

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

imp requested review of this revision.Mar 3 2026, 8:20 PM
This revision is now accepted and ready to land.Mar 6 2026, 5:21 PM
This revision was automatically updated to reflect the committed changes.
jhb added inline comments.
sys/dev/nvme/nvme_ctrlr.c
1367

Having the constant checked here separately from the declaration of the array seems a bit fragile. It might be nicer if this function took an extra parameter holding the count of pages instead (using nitems() in the caller) so that if you change the size of the array in the caller for some reason, this function wouldn't be out of sync.

Actually, you have that if you just check maxpages here instead of the hard-coded constant? Right now max_pages isn't used.

1521

This one needs to pass nitems(upages_small). You fixed this above, but not in this function.

sys/dev/nvme/nvme_ctrlr.c
1367

Yes. This is why the goofs elsewhere aren't as fatal as they should be.
It should be max_pages.

1521

this was fixed in a followup.