From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 10 10:38:41 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75FEF31E for ; Mon, 10 Nov 2014 10:38:41 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DBD93E7C for ; Mon, 10 Nov 2014 10:38:40 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sAAAcVJD003073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2014 12:38:31 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sAAAcVJD003073 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sAAAcUB0003072; Mon, 10 Nov 2014 12:38:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 10 Nov 2014 12:38:30 +0200 From: Konstantin Belousov To: Sibananda Sahu Subject: Re: Query regarding Unmapped IO, PIM_UNMAPPED and bus_dmamap_load_ccb() Message-ID: <20141110103830.GH53947@kib.kiev.ua> References: <20141107142309.GR53947@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-scsi@freebsd.org, Kashyap Desai X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 10:38:41 -0000 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.