Date: Mon, 10 Nov 2014 12:38:30 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Sibananda Sahu <sibananda.sahu@avagotech.com> Cc: freebsd-scsi@freebsd.org, Kashyap Desai <kashyap.desai@avagotech.com> Subject: Re: Query regarding Unmapped IO, PIM_UNMAPPED and bus_dmamap_load_ccb() Message-ID: <20141110103830.GH53947@kib.kiev.ua> In-Reply-To: <d6d43fbfc369ae3fb4b17d3be0c7486b@mail.gmail.com> References: <b27d51d8c4bd9b42ce90b82d1cbf9845@mail.gmail.com> <20141107142309.GR53947@kib.kiev.ua> <d6d43fbfc369ae3fb4b17d3be0c7486b@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 10, 2014 at 03:43:44PM +0530, Sibananda Sahu wrote: > Hi Konstantin, > > +++Look at the code. In particular, the definition of the struct bio in > sys/sys/bio.h. There, the buffer pointed by bio_data is passed if > BIO_UNMAPPED flag is not set, but when the flag is set, bio_ma* fields > describe an +++array of physical memory pages where the data for i/o > request are scattered. The pages are not neccessary mapped into the KVA, > which explains the terminology. > > +++The i/o stack and busdma(9) where modified to transparently handle such > requests, and you correctly described the minimal changes, required from > the driver side to process the unmapped requests. > +++The passing of a pointer to bio instead of the pointer to buffer allows > drivers to not care about mapped/not mapped requests, assuming the > suitable KPI like bus_dma_load_ccb() prepares the buffer for dma +++engine > of the controller. > > Thanks for this information. > I have checked the header for the above mentioned data and understood how > it happens. > > Further I have observed that the CAM_DATA_BIO is the case when I am > reading some data out of the disk. > But when I am writing some data to the disk I am getting the request via > CAM_DATA_VADDR. > Is the BIO meant only for READs??? BIOs are used both for reads and writes. Your VADDR request is some BIO as well, it was just 'disassembled' into the buffer request by some upper layer before reaching the driver. Your observation that you only get unmapped reads is due to your testing load, and is not something that system enforces. Both reads and writes may happen mapped or unmapped, driver cannot rely on absence of any specific requests. Test UFS-formatted volume on the disk handled by the driver, it will give you ample amount of unmapped reads and writes.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141110103830.GH53947>