From owner-freebsd-scsi Wed Nov 10 13: 9:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 31B9014D90 for ; Wed, 10 Nov 1999 13:09:29 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id NAA77778; Wed, 10 Nov 1999 13:59:12 -0700 (MST) Date: Wed, 10 Nov 1999 13:59:12 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199911102059.NAA77778@narnia.plutotech.com> To: Nick Hibma Cc: scsi@FreeBSD.org Subject: Re: queues in CAM X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > I'm trying to understand the queueing thing in CAM. The following code > fragment (which is found in all the SIMs) > > > devq = cam_simq_alloc(MO /*maximum openings*/); > sc->sim = cam_sim_alloc(umass_cam_action, umass_cam_poll, > "umass", sc, > device_get_unit(sc->sc_dev), > MDO /*max_dev_openings*/, > MTDO /*max_tagged_dev_openings*/, > devq); > > confuses me. Are the MDO and MTDO values related to per device queues? > And is the MO value related to a per SIM queue? Yes and yes. Some controllers, although they can accept a rather large number of transactions, cannot queue that many to just a single device. MDO exports the controller's ability to queue untagged transactions to a single device. MTDO does the same thing for tagged transactions. > > The values in for example the dpt_scsi.c driver indicate that if 1 > device has 255 tagged commands outstanding, it blocks the SIM from > accepting more requests. Or are requests transferred from the SIM queue > to the device queue as soon as the SIM accepts them? MO is a controller global limit. MDO and MTDO are device specific limits with only one or the other in effect (you can't mix tagged and untagged transactions). So, if only a single device is active on the bus, and the controller can support queuing all of its transactions to a single device, then yes, a single device can take them all. Of course, CAM uses a round-robin, per-priority level scheduler, so as soon as another device becomes active on the bus it will take transaction resources away from the hog very quickly. See http://www.FreeBSD.org/~gibbs/cam.html > In my case (dev/usb/umass.c, new version) should it be the following? > > MO=1, MDO=1, MTDO=0 Some controllers queue up additional untagged transactions so that the RTT for commands is reduced. This would be the only reason to bump the MDO number. Since you have a 1-1 mapping of devices to SIMs, MO should be equal to MDO. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message