Date: Wed, 10 Nov 1999 13:59:12 -0700 (MST) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: Nick Hibma <hibma@skylink.it> Cc: scsi@FreeBSD.org Subject: Re: queues in CAM Message-ID: <199911102059.NAA77778@narnia.plutotech.com> In-Reply-To: <Pine.BSF.3.96.991110070739.6087C-100000@henny.plazza.it>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <Pine.BSF.3.96.991110070739.6087C-100000@henny.plazza.it> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911102059.NAA77778>