Date: Mon, 5 Feb 2001 15:57:30 -0700 From: "Kenneth D. Merry" <ken@kdm.org> To: Mike Smith <msmith@FreeBSD.ORG> Cc: Tom Samplonius <tom@sdf.com>, freebsd-scsi@FreeBSD.ORG Subject: Re: Tags and the mly driver Message-ID: <20010205155730.A85912@panzer.kdm.org> In-Reply-To: <200102050557.f155vBs00494@mass.dis.org>; from msmith@FreeBSD.ORG on Sun, Feb 04, 2001 at 09:57:10PM -0800 References: <Pine.BSF.4.05.10102042009270.14471-100000@misery.sdf.com> <200102050557.f155vBs00494@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[ please remember to CC me ] On Sun, Feb 04, 2001 at 21:57:10 -0800, Mike Smith wrote: > > > Since we can't determine via camcontrol negotiate whether it supports > > > tagged queueing, we can look at the inquiry data. > > Well, the array supports multiple outstanding commands per logical unit > (it wouldn't make a lot of sense if it didn't), but there's no need to > have tags associated with them (since the driver/adapter protocol > contains the equivalent of the 'tag' already). > > > > If it doesn't support tagged queueing, then increasing the tags is probably > > > a bad idea. We should probably have a check in the transport layer that > > > rejects any attempt to raise the number of tags above 1 if the device > > > doesn't support tagged queueing. > > How do we go about telling the transport layer that multiple commands per > target is OK, but that we don't care about tags? There are two numbers that get passed in to cam_sim_alloc(), the maximum number of untagged commands and the maximum number of tagged commands per device. You're currently setting the number untagged commands per device to 1. Since the inquiry data from the Mylex array doesn't claim that it supports tagged queueing, the transport layer uses the number of untagged commands to determine how many transactions to send down at a time. I don't know how the board works, but one thing to keep in mind is that if you bump up the number of untagged commands, you may be able to send multiple commands to the RAID array, but you'll have to limit the number of commands you send to any other device to just one. So you'll have to do some internal queueing and checking to make sure you don't send any more than one untagged command to a device that isn't the RAID array. It might be easier to set the SID_CmdQue bit in the inquiry data, and let the transport layer handle how many commands get sent down. The only thing you'd really need to worry about as far as the tags go is the head of queue tag type -- when you get one of those, stick it at the front of the queue. :) The other tag types (simple, ordered) could just be done in FIFO order. Of course if the board doesn't support tagged queueing for devices that are accessed in passthrough mode, that might present a problem, and you might be better off using untagged commands and just making sure you don't send more than one command at a time to the non-RAID devices. > More specifically, the limit on total outstanding commands is per HBA, > not per channel or per target. The maximum number of commands per HBA is specified as an argument for cam_simq_alloc(). > > I've always assumed this is the SAF-TE device builtin the enclosure. The > > Mylex card deals with the SAF-TE device events directly, and I think this > > is an attempt by the mly driver to attach it. Again, lots of assumptions. > > Actually, the driver should probably block attempts to access the > enclosure device as well as disks listed in the array config, since the > controller is meant to handle these. The driver doesn't actually attach > to it - this is the generic CAM code. You could probably return selection timeouts for any device you didn't want CAM to talk to, if you have a way of knowing which devices those are. That would keep CAM from trying to talk to it. > I'm not sure what's up with non-disk devices going away; again, probably > a bug in the passthrough command handling. > > > I don't much care about the dpt issue as much as the mly one. The dpt > > The mly adapter *should* support up to the maximum number of commands > supprted by the adapter per logical unit (eg. if the adapter supports > 512 commands, you should be able to have that many outstanding per unit). > > The fact that it appears not to be doing this now is a bug, and I need to > fix it. Thanks for mentioning it - Ken, if you have any suggestions > based on the code in sys/dev/mly/mly_cam.c, I'd be thankful. Hopefully my comments above will help. Thanks to Justin for explaining some of it to me. Ken -- Kenneth Merry ken@kdm.org 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?20010205155730.A85912>