From owner-freebsd-current@FreeBSD.ORG Sun Jul 4 11:20:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEBA71065670; Sun, 4 Jul 2010 11:20:47 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (unknown [IPv6:2001:380:e06:127::53]) by mx1.freebsd.org (Postfix) with ESMTP id 867DD8FC13; Sun, 4 Jul 2010 11:20:47 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id CA9EF78C53; Sun, 4 Jul 2010 20:20:43 +0900 (JST) Received: from artemis (unknown [192.168.2.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTP id AF6A078C3B; Sun, 4 Jul 2010 20:20:43 +0900 (JST) Message-ID: <10CB692CA3FE4A8992B250B7F35B243B@ad.peach.ne.jp> From: "Daisuke Aoyama" To: "Alexander Motin" , "FreeBSD-Current" References: <6BC2B2FBAFFA4C26A46977F121B707E1@ad.peach.ne.jp> <4C2F4B67.3060201@FreeBSD.org> In-Reply-To: <4C2F4B67.3060201@FreeBSD.org> Date: Sun, 4 Jul 2010 20:20:15 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: Subject: Re: [Need Help]isboot (iSCSI boot driver) version 0.2.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 11:20:47 -0000 Hi, >> Notes/Known Issues/Limitations: >> FreeBSD can't use transfer length > 64KB. > > Since 8.0 FreeBSD can use any transfer lengths. 64K is a safety limit > for CAM SIMs that do not report maximum transfer size. If your driver > supports bigger transactions (and even if not), you should fill maxio > field in XPT_PATH_INQ response. I set maxio=1024*1024 in version 0.2.2. As a result, the request (each ccb) have 256 blocks (128KB). I don't know why it is 128KB. >> It seems CAM tag is used only 2 of 64 tags. >> I don't know a reason, but MAXPHYS limit? > > How many concurrent requests you are submitting? If you are testing it > with sequential read from file system - make sure you have sysctl > vfs.read_max set high enough. MAXPHYS does not affects number of > concurrent requests, only size of each one. I used vfs.read_max=32 and run only one dd. Now vfs.read_max=2048. I tried to run dd 4 times at background, then I got 4 x 30MB/s (read) and 4 x 21MB/s (write). Write is still slower than read, but it is enough. I can see 1 or 2 tags when reading, around 10 tags when writing. I guess that reading tag exists only for a short time. (or my execution order is not good) Thank you. Daisuke Aoyama