Query regarding Unmapped IO, PIM_UNMAPPED and bus_dmamap_load_ccb()

Sibananda Sahu sibananda.sahu at avagotech.com
Mon Nov 10 10:13:54 UTC 2014


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 at gmail.com]
Sent: Friday, November 07, 2014 7:53 PM
To: Sibananda Sahu
Cc: freebsd-scsi at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe at freebsd.org"


More information about the freebsd-scsi mailing list