Date: Mon, 10 Nov 2014 15:43:44 +0530 From: Sibananda Sahu <sibananda.sahu@avagotech.com> To: Konstantin Belousov <kostikbel@gmail.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: <d6d43fbfc369ae3fb4b17d3be0c7486b@mail.gmail.com> In-Reply-To: <20141107142309.GR53947@kib.kiev.ua> References: <b27d51d8c4bd9b42ce90b82d1cbf9845@mail.gmail.com> <20141107142309.GR53947@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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??? Can you please put some light on this and please correct me if I have observed it wrong. Thanks, Sibananda Sahu -----Original Message----- From: Konstantin Belousov [mailto:kostikbel@gmail.com] Sent: Friday, November 07, 2014 7:53 PM To: Sibananda Sahu Cc: freebsd-scsi@freebsd.org Subject: Re: Query regarding Unmapped IO, PIM_UNMAPPED and bus_dmamap_load_ccb() On Fri, Nov 07, 2014 at 05:07:59AM +0530, Sibananda Sahu wrote: > Hi All, > > > > I have raised this query regarding the following mail: > > https://lists.freebsd.org/pipermail/freebsd-scsi/2014-July/006407.html > > > > Where Alexander Motin talks of Unmapped I/O. > > As per his direction I have declared the below statement in my driver code: > > > > ccb->cpi.hba_misc = PIM_NOBUSRESET | PIM_UNMAPPED; > > > > Before enabling PIM_UNMAPPED I was getting the (ccb->ccb_h.flags & > CAM_DATA_MASK) as CAM_DATA_VADDR and handling accordingly. > > But after enabling PIM_UNMAPPED in cpi.hba_misc I am getting the > (ccb->ccb_h.flags & CAM_DATA_MASK) as CAM_DATA_BIO and handling the > data that comes with bus_dma_load_ccb(). Right. 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. Thanks for this information. I have checked the header for the above mentioned data and understood how it happens. 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. > > > > I just did the same thing according to the mps(4) driver as referred > by Alexander Motin. > > > > So I just wanted to know what exactly happening when I am enabling the > PIM_UNMAPPED in the cpi.hba_misc field. > > And what the CAM_DATA_BIO really means in the CAM_DATA_MASK. > > > > > > It would be great idea if somebody explains what exactly happening or > at least give me some references where can I have a look and move forward. > > > > > > Thanks, > > Sibananda Sahu > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d6d43fbfc369ae3fb4b17d3be0c7486b>