Date: Wed, 07 Feb 2001 20:11:17 -0800 From: Mike Smith <msmith@freebsd.org> To: "Kenneth D. Merry" <ken@kdm.org> Cc: Tom Samplonius <tom@sdf.com>, freebsd-scsi@FreeBSD.ORG Subject: Re: Tags and the mly driver Message-ID: <200102080411.f184BH907296@mass.dis.org> In-Reply-To: Your message of "Mon, 05 Feb 2001 15:57:30 MST." <20010205155730.A85912@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
cam_sim_alloc(mly_cam_action,
mly_cam_poll,
"mly",
sc,
device_get_unit(sc->mly_dev),
max untagged -> 1,
max tagged -> sc->mly_controllerinfo->maximum_parallel_commands,
devq)
> You're currently setting the number untagged commands per device to 1.
Gotcha.
> 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.
Ah, ok. Since I create a separate sim for each channel, and since the
array devices are on virtual channels separate from the passthrough
devices, it should be relatively straightforward to adjust this
accordingly so that the untagged command limit is raised for the array
devices.
> 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.
It does, but they're kept segregated.
> > > 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.
This is how I currently handle the disks that are part of the array.
> Hopefully my comments above will help. Thanks to Justin for explaining
> some of it to me.
Very much so, I think.
Regards,
Mike
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
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?200102080411.f184BH907296>