From owner-freebsd-geom@freebsd.org Sun Dec 13 08:30:18 2015 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA1C1A3B98C for ; Sun, 13 Dec 2015 08:30:18 +0000 (UTC) (envelope-from sagig@dev.mellanox.co.il) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49A861E86 for ; Sun, 13 Dec 2015 08:30:17 +0000 (UTC) (envelope-from sagig@dev.mellanox.co.il) Received: by wmnn186 with SMTP id n186so83547614wmn.0 for ; Sun, 13 Dec 2015 00:30:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dev-mellanox-co-il.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=L6lUa5lLscCY1V5JBUwG4KyTzNwYRM1UtLc6jmpfoA0=; b=xYYmmKP55U7RyPESC8d8LoMi2JFUex1h1LK6iOVjxzvhw3aBDYWpru/Jw8jftDlOco NZLkuWqHYPWY2Tq+2DOLvjV6ZJs0d4lOqBZRet3/np5EbZQrggL/LbCPd0GrpuFPLqqm XX9JOs1dt73OR6W35hbHXpmz1kvlN9HUTh6PsYn3wGEfvFr8DcOueI8Eov/waaFqNFl2 HKb0UbEpoCOsuexGAhv4uGE1sYXEi9CUbvdSkQtot2/He9BgQ0I/oFpAGdPcLip2TGts aljIy8W1Z88+qv2ERRrccI/OqMZCYipbs+yrh2VNwM7JQWrlSke7AXz0+c5QrFSfu5UZ R3eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=L6lUa5lLscCY1V5JBUwG4KyTzNwYRM1UtLc6jmpfoA0=; b=Wd5dleajylXTsf5i6brPxzZdZ0ZR8iCGO/IjFC9+uMi0PTUXTLSTQFgGVdkPB+CjnS HNAi7uL6h5BK26mb/CxTGjVaT3BmloFeYKTSOX4O6QqcSEiBA/bmnp6JQITe9WghZ7sM G4EtTbfbDy3ecr0rlhT9gs3h2QiCNMrETpx5Kao7+Vw98z6bBFGa2j/7ryiVOm2TCEmw TCYQyjBoZVkkcqdnEjZcOBKjH24osD1NSHeNM5y+c6ILqvpni80MghLGr5hCarM4oePv BUrDNvxjYarPhc/0yAwkuyYUvL25kKBkPL4AJnVajcM/aShIhA/ivQeO9iG9oCngQMR/ UvOA== X-Gm-Message-State: ALoCoQlymmHRCWHBskt0VwrPygAYqChWQTbUeD8wzMDuK5HA2gU8GxA16MpXSbupZ6fXHNUt+pQ2A2M7ZF8oIeC6tI6fZZ1TVw== X-Received: by 10.28.144.139 with SMTP id s133mr17398182wmd.90.1449995416432; Sun, 13 Dec 2015 00:30:16 -0800 (PST) Received: from [10.223.3.75] ([193.47.165.251]) by smtp.gmail.com with ESMTPSA id kb5sm24329523wjc.20.2015.12.13.00.30.14 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Dec 2015 00:30:15 -0800 (PST) Subject: Re: splitting iovecs to bios To: Konstantin Belousov , Max Gurtovoy References: <56696E03.8050202@mellanox.com> <20151210150210.GY82577@kib.kiev.ua> Cc: Sagi Grimberg , freebsd-scsi@freebsd.org, Hans Petter Selasky , Oren Duer , freebsd-geom@freebsd.org From: Sagi Grimberg Message-ID: <566D2C91.9050900@dev.mellanox.co.il> Date: Sun, 13 Dec 2015 10:30:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151210150210.GY82577@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2015 08:30:18 -0000 Hi Konstantin, > There might be indeed a reason, it could be that some drivers expect > blocking to be done by the userspace. The drivers could have some > restrictions on transfer sizes and atomicity of transfer, which would > be broken by the unconditional merge. I cannot give you an example > of such driver, known block-aware drivers like sa(4) only require the > bio size to be multiple of the basic block size. I'm surprised to learn that the generic access layer splits IO requests just because some block drivers cannot handle it. I'd expect that this sort of limitation would be communicated by the drivers in the form of device flag SI_NOMERGE. > OTOH, I see no issue with adding a SI_PHYSIOMERGE flag and doing the > merges for the driver in physio(), when unmapped request has consequtive > iov elements ending and starting at the page boundary. I'd say it should be the other way around, physio would always strive to append/merge iov elements but wouldn't in case the device does not support it. Moreover, some modern devices does not even require the page boundary alignment you mentioned. These devices can execute IO to/from any arbitrary scatter list of buffers.