Date: Fri, 9 Mar 2001 21:47:45 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Mike Smith <msmith@FreeBSD.ORG> Cc: Joe Albowicz <joe@CS.UCLA.EDU>, freebsd-hackers@FreeBSD.ORG Subject: Re: aic7xxx driver & SCBs Message-ID: <Pine.LNX.4.10.10103092108400.1731-100000@linux.local> In-Reply-To: <200103092210.f29MALs09079@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10103092108400.1731-100000>