SMP passthrough support for CAM and mps(4)

[Kenneth D. Merry]

On Tue, Nov 16, 2010 at 16:01:25 -0800, Matthew Jacob wrote:
> On 11/16/2010 3:40 PM, Kenneth D. Merry wrote:
> >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.)
> 
> Yes, but non-SMP commands can also now be bidirectional (viz OSD).

Yeah, to support those we'll have to adjust struct ccb_scsiio to allow it.
The way it is right now, you can't do bidirectional transfers, unless you
do something like put a S/G list in and designate one buffer as the output
and another as the input.  (Which is actually what LSI does for SMP
passthrough.)

When we do that, we'll have to go through and overhaul drivers to support
bidirectional transfers, or throw an error if they don't support
CAM_DIR_BOTH.  (Maybe it'll require some bit to be set from drivers that do
support it so the transport layer can flag the problem before the CCB goes
down.)

> >>+ 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.
> ..
> >>+ 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.
> 
> Ah. You might as well, at this point, go the extra mile and do SAS2 if 
> you can. It's possible to tell from a REPORT GENERAL whether the device 
> is SAS1 or SAS2, and if you do SAS2 you can get lists of phys instead of 
> iterating over each.

You mean the discover list command?  Yes, that would be handy.  I should go
ahead and do that...  But then again, using the plain discover command
works on old and new devices.  The smpphylist command in camcontrol is just
trying to match up phys on an expander with the device attached to them, if
any.

> ....
> >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.)
> >
> 
> Hmm. An expander is an SMP device only. It *may* have an SES portal to 
> it, but SMP is in the SAS/SSP domain, not SMP.

SMP is not in the SMP domain?

> Another thing to keep in mind is that STP and SATA are in fact 
> different. You tend to forget this when you use LSI HBAs which do the 
> SATL work for you. The WWN of the STP (assigned by the expander) is 
> different from a WWN for a SATA drive (wds 108..111 of modern SATA 
> drives). This also gets horribly ugly when SAS/SATA dongles are used.

Hmm, yeah.  Looks like we'll have some things to figure out when we get
around to implementing this stuff. :)

Ken
-- 
Kenneth Merry
ken at FreeBSD.ORG