Date: Tue, 16 Nov 2010 16:40:53 -0700 From: "Kenneth D. Merry" <ken@freebsd.org> To: Matthew Jacob <mj@feral.com> Cc: freebsd-scsi@freebsd.org Subject: Re: SMP passthrough support for CAM and mps(4) Message-ID: <20101116234053.GA78961@nargothrond.kdm.org> In-Reply-To: <4CE3109D.5090308@feral.com> References: <20101116210507.GA35011@nargothrond.kdm.org> <4CE3109D.5090308@feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 16, 2010 at 15:15:41 -0800, Matthew Jacob wrote: > > + there are other, non-SMP things included (CAM_DIR_RESV -> CAM_DIR_BOTH) That particular thing was intentional. CAM_DIR_BOTH is used when filling in SMP commands, because data is transferred in both directions. (Request and response.) > + CAM_QUIRK_NOSERIAL got replaced with CAM_QUIRK_NOVPDS, fine > > + XPT_DEV_ADVINFO ought have a comment about what it is like the other > commands. The pp below about advanced device info is hard to figure out. Will do, thanks. BTW, those two pieces are part of a set of SES improvements that will@ is doing, so there is more reason to bring them in than their limited use in camcontrol in the patch. > + The functions in smp_all.c should make clear distinctions about which > version of SAS is being supported. Will do, thanks. I based it on spl-r07, but I should make that explicit. Most of the functions should be backwards-compatibile at least, because they give the user the option to specify the long bit. I need to tweak at least the smprg case in camcontrol (Report General) to detect the long bit in the response and re-fetch with the long bit set to get the full response. > I would really like to see this come in as a fully functional PROTO_SMP > in cam_proto. Any chance of that happening? Yes, that is going to be part of a much bigger work of doing a lot of multipathing support for CAM. Our initial target architecture will be SAS (although things should work generically for FC targets as well), and I'm pretty sure we'll probably have some zoning and expander knowledge in the topology, and so SMP will have to be a part of that work. One other goal is that for any given device in the topology, you'll be able to have more than one protocol attached to it. e.g. if you have a SATA disk in a SAS topology, you may be able to talk to it using SCSI or ATA. If you have an expander, you may be able to talk it using SCSI or SMP. (In reality, the expanders I've seen so far don't support SMP on the SAS addresses that support SSP.) Right now, since cam_proto is setup as an enumeration, we can only report one protocol at a time. So we'll need to make it a bitmask at least. We'll also need the ability to detect and probe SMP targets. This round of SMP work won't preclude any of that from happening, and will make it possible to send SMP commands down from userland. (To do things like fail a disk, reset links, exercise error recovery, etc.) Thanks for the feedback! Ken -- Kenneth Merry ken@FreeBSD.ORG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101116234053.GA78961>