From owner-freebsd-hackers Fri Mar 9 14:58: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by hub.freebsd.org (Postfix) with ESMTP id 990A737B718; Fri, 9 Mar 2001 14:58:03 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from nas1-207.cgy.club-internet.fr (nas1-207.cgy.club-internet.fr [195.36.197.207]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA28386; Fri, 9 Mar 2001 23:57:59 +0100 (MET) Date: Fri, 9 Mar 2001 21:47:45 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Mike Smith Cc: Joe Albowicz , freebsd-hackers@FreeBSD.ORG Subject: Re: aic7xxx driver & SCBs In-Reply-To: <200103092210.f29MALs09079@mass.dis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 9 Mar 2001, Mike Smith wrote: > Joe; it looks like you have some funny ideas about something that's not= =20 > actually very relevant. I assume that you have already gone and bought= =20 > Monster Cable(tm) SCSI cables, and that you have the special=20 > oxygen-free-copper SCSI controller PCBs, because none of this is going to= =20 > mean anything unless you have. Pardon and sorry, Mike. It is rather your reply that looks funny to me. The number of SCBs in (both) the Linux and FreeBSD aic7xxx driver(s) is very relevant in my opinion given that it is just the maximum of SCSI command contexts the driver can handle (i.e. maximum number of outstanding IOs). > > I'd like to ask if anyone can share any knowledge about how/if the numb= er > > of SCBs affects performace for scsi drives. >=20 > If you don't have enough SCBs, you can't deliver enough commands to your= =20 > drive(s) to keep them busy. Being busy does not imply doing a good job. You can get a device full busy using only 2 simultaneous IOs for this device. Using more can allow the device to perform optimizations based on actual head positions and possibly coalesce data transfers when possible, for example. > > Also I would like to be able to configure the number of SCBs that the s= csi > > driver uses. With Linux this parameter for the aic7xxx driver can be > > configured via "make menuconfig" step of the kernel build process. Is > > there a similiar way to configure this varible for BSD? Or do I have t= o > > start hacking on the driver code? >=20 > You can't do that. Firstly, there isn't a "SCSI driver", secondly there > are several different sorts of objects that map to what you, coming from > the Linux world, would call an SCB, and thirdly, the CAM subsystem > components have a much better idea than you do how many of these that are > needed, and will allocate them as necessary. You should have been more accurate here, in my opinion. Vague explanations= =20 are worse than no explanations at all, in my opinion. The CAM subsystem does not govern the number of SCBs. It only cares about= =20 limiting the number of simultaneous commands, firstly to the value told=20 by SIM and secondly based on device quirks or conditions as QUEUE FULL=20 status returns. The noticeable difference here with Linux is that, under Linux, the device queue depth is tailored by SIM at device discovery time and will not be dynamically adjusted on QUEUE FULL status by the generic SCSI layer. Given that CAM will reduce the device queue depth on QUEUE FULL status and has appropriate quirks tables, SIMs can just announce to CAM large queue depths at initialisation and then rely on CAM for reducing the queue depth if and as needed. Doing the same under Linux can harm unless the SIM is smart enough for doing what CAM is doing under FreeBSD. In brief, SIMs (low level SCSI drivers) under FreeBSD just use to announce to CAM the largest possible queue depths, and so, having some configuration parameter for that seems useless. Btw, your reply let me think that you want to discourage people to hack=20 our source code or to try to understand how it works. Colour me very surprised. :-) G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message