From owner-freebsd-scsi@freebsd.org Sun Dec 13 08:30:18 2015 Return-Path: Delivered-To: freebsd-scsi@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 AA445A3B98F for ; Sun, 13 Dec 2015 08:30:18 +0000 (UTC) (envelope-from sagig@dev.mellanox.co.il) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 49A161E85 for ; Sun, 13 Dec 2015 08:30:18 +0000 (UTC) (envelope-from sagig@dev.mellanox.co.il) Received: by mail-wm0-x22e.google.com with SMTP id p66so24258675wmp.1 for ; Sun, 13 Dec 2015 00:30:17 -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=SBlJjjgd27FwbtjwxXVYisnGUxylpf3ep771fQHAM+BTy8JYZEAwKOPGLV+ijYep2m 6OSgNk8UcH1mi/kn/1udjxIv/dPxJrkV2UB5EUn4h7NKZBUr2IJI/v4DpTZ9EWbUkZ2r zdeKP7zisnTYd1zy4I5oksmjj1xbNHyejaEL7h5LtwT38Bsqo/AHAXd8hl6lHG/abDDM PxEevgKM9aKQD7/aXCCEljwnYmSVzF/0W1UNe1vq+My/krG/CJaGYTGk3pojgMxG7ubY 1UlOSFWuIpeFhLrUCpQmGKJHOrIypS+BCSLPjiE95ECPVtXBXCCEdUS5W4PYFzqbNiCQ hWRg== X-Gm-Message-State: ALoCoQkgsEDxJntelP5zOA6VxgUHADPG78CmSJspLFB6wDeSi0psCBUaJgSsLpvdkrkix4XsBDqk2qSQAVdn717bPnO2AEBdeQ== 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-scsi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SCSI subsystem 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.