SMP passthrough support for CAM and mps(4)

[Kenneth D. Merry]

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 at FreeBSD.ORG