Date: Tue, 31 Mar 2015 03:49:12 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: "Kenneth D. Merry" <ken@FreeBSD.ORG> Cc: current@freebsd.org, scsi@freebsd.org Subject: Re: async pass(4) patches available Message-ID: <20150331004912.GM2379@kib.kiev.ua> In-Reply-To: <20150330222358.GA46342@mithlond.kdm.org> References: <20150330222358.GA46342@mithlond.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 30, 2015 at 04:23:58PM -0600, Kenneth D. Merry wrote: > Kernel memory for data transferred via the queued interface is > allocated from the zone allocator in MAXPHYS sized chunks, and user > data is copied in and out. This is likely faster than the > vmapbuf()/vunmapbuf() method used by the CAMIOCOMMAND ioctl in > configurations with many processors (there are more TLB shootdowns > caused by the mapping/unmapping operation) but may not be as fast > as running with unmapped I/O. cam_periph_mapmem() uses vmapbuf() with an indicator to always map the user pages mostly because I do not know CAM code and wanted to make the least intrusive changes there. It is not inherently impossible to pass unmapped pages down from cam_periph_mapmem(), but might require some more plumbing for driver to indicate that it is acceptable. > > The new memory handling model for user requests also allows > applications to send CCBs with request sizes that are larger than > MAXPHYS. The pass(4) driver now limits queued requests to the I/O > size listed by the SIM driver in the maxio field in the Path > Inquiry (XPT_PATH_INQ) CCB. > > There are some things things would be good to add: > > 1. Come up with a way to do unmapped I/O on multiple buffers. > Currently the unmapped I/O interface operates on a struct bio, > which includes only one address and length. It would be nice > to be able to send an unmapped scatter/gather list down to > busdma. This would allow eliminating the copy we currently do > for data. Only because nothing more was needed. The struct bio does not use address/length pair when unmapped, it passes the list of physical pages, see bio_ma array pointer. It is indeed taylored to be a pointer to struct buf' b_pages, but it does not have to be. The busdma unmapped non-specific interface is bus_dmamap_load_ma(), which again takes array of pages to load. If you want some additional helper, suitable for your goals, please provide the desired interface definition.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150331004912.GM2379>