From owner-freebsd-arch@FreeBSD.ORG  Fri Dec 21 12:02:42 2012
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
 by hub.freebsd.org (Postfix) with ESMTP id A20DADA5;
 Fri, 21 Dec 2012 12:02:42 +0000 (UTC)
 (envelope-from kostikbel@gmail.com)
Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1])
 by mx1.freebsd.org (Postfix) with ESMTP id 086A98FC12;
 Fri, 21 Dec 2012 12:02:41 +0000 (UTC)
Received: from tom.home (kostik@localhost [127.0.0.1])
 by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBLC2bkU018521;
 Fri, 21 Dec 2012 14:02:37 +0200 (EET)
 (envelope-from kostikbel@gmail.com)
DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua qBLC2bkU018521
Received: (from kostik@localhost)
 by tom.home (8.14.5/8.14.5/Submit) id qBLC2btY018520;
 Fri, 21 Dec 2012 14:02:37 +0200 (EET)
 (envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com
 using -f
Date: Fri, 21 Dec 2012 14:02:37 +0200
From: Konstantin Belousov <kostikbel@gmail.com>
To: Ivan Voras <ivoras@freebsd.org>
Subject: Re: Unmapped I/O
Message-ID: <20121221120237.GF53644@kib.kiev.ua>
References: <20121219135451.GU71906@kib.kiev.ua> <kauqfc$rau$1@ger.gmane.org>
 <20121220201523.GD53644@kib.kiev.ua>
 <CAF-QHFXdeG0ZHOp1L5TQ25t4maruz3=pmFEco0x8mMqcR-Mr=w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="vA66WO2vHvL/CRSR"
Content-Disposition: inline
In-Reply-To: <CAF-QHFXdeG0ZHOp1L5TQ25t4maruz3=pmFEco0x8mMqcR-Mr=w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
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
 version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home
Cc: freebsd-arch@freebsd.org
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Dec 2012 12:02:42 -0000


--vA66WO2vHvL/CRSR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 21, 2012 at 12:52:35PM +0100, Ivan Voras wrote:
> On 20 December 2012 21:15, Konstantin Belousov <kostikbel@gmail.com> wrot=
e:
>=20
> > Nothing is changed for existing GEOM classes, and it does not mean anyt=
hing
> > for GEOM developers, unless she wants to change the GEOM class to handle
> > unmapped BIOs.
>=20
> Understood, but the intention of my question was: do you recommend
> GEOM classes should take the effort and implement unmapped BIOs
> whenever possible?
Depends. RAID 0 and RAID 1 can process unmapped BIOs without changes,
I am sure. For the class like RAID5, you would need a hardware
for it to be able to operate on the unmapped BIOs without requiring
the remap. There is indeed Intel IOAT, which I believe can do this.

On the other hand, for encrypting classes like GELI it probably does not
make much sense to care, for the case of encryption done in software or
using AES-NI.

>=20
> Your change in g_part.c is trivial - this is because g_part doesn't
> actually touch the BIO data, only pass it on?
Right.

--vA66WO2vHvL/CRSR
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iEYEARECAAYFAlDUT90ACgkQC3+MBN1Mb4hcEgCgtmlwbM98Vjqkt4CWaLTPXbir
dBQAoOQsdKvnio2jfME76vKDGdlLOKtq
=JPBn
-----END PGP SIGNATURE-----

--vA66WO2vHvL/CRSR--