CISS_MAX_LOGICAL to 107
Submitter wanted to increase the number of logical disks supported by ciss(4)
by simply raising the CISS_MAX_LOGICAL value even higher. Instead, consult
the documentation for the raid controller (OPENCISS) and poke the controller
bits to ask it for how many logical/physical disks it can handle.
Revert svn R242089 that raised CISS_MAX_LOGICAL to 64 for all controllers.
For older controllers that don't support this mechanism, fallback to the old
value of 16 logical disks. Tested on P420, P410, P400 and 6i model ciss(4)
controllers.
This should will be MFC'd back to stable/9 stable/8 and stable/7 after the MFC
period.
PR: kern/151564
Reviewed by: scottl@freebsd.org
MFC after: 2 weeks
- Implement MSI support (MSIX support was already there)
- Use a table to drive MSI/MSIX exceptions
- Pre-calculate the command address instead of wasting cycles doing the
calculation on every i/o.
number of MSIX interrupts that are needed, and don't strictly check for 4.
Enable enough interrupt mask bits so that the controller will generate
interrupts in PERFORMANT mode. This fixes the hang-on-boot issues that
people were seeing with newer controllers.
that there are 3 different interrupt enable bits, 2 for different
families of cards, and 1 for when MSI is used. Also apply a big
hammer backstop for cards that aren't recognized. This should fix
all of the interrupt issues at boot.
code interfered with Performant mode and legacy interrupts. Also
remove a register read operation on the Simplq code that was
effectively a time-wasting no-op.
1. The FreeBSD driver was setting an interrupt coalesce delay of 1000us
for reasons that I can only speculate on. This was hurting everything
from lame sequential I/O "benchmarks" to legitimate filesystem metadata
operations that relied on serialized barrier writes. One of my
filesystem tests went from 35s to complete down to 6s.
2. Implemented the Performant transport method. Without the fix in
(1), I saw almost no difference. With it, my filesystem tests showed
another 5-10% improvement in speed. It was hard to measure CPU
utilization in any meaningful way, so it's not clear if there was a
benefit there, though there should have been since the interrupt handler
was reduced from 2 or more PCI reads down to 1.
3. Implemented MSI-X. Without any docs on this, I was just taking a
guess, and it appears to only work with the Performant method. This
could be a programming or understanding mistake on my part. While this
by itself made almost no difference to performance since the Performant
method already eliminated most of the synchronous reads over the PCI
bus, it did allow the CISS hardware to stop sharing its interrupt with
the USB hardware, which in turn allowed the driver to become decoupled
from the Giant-locked USB driver stack. This increased performance by
almost 20%. The MSI-X setup was done with 4 vectors allocated, but only
1 vector used since the performant method was told to only use 1 of 4
queues. Fiddling with this might make it work with the simpleq method,
not sure. I did not implement MSI since I have no MSI-specific hardware
in my test lab.
4. Improved the locking in the driver, trimmed some data structures.
This didn't improve test times in any measurable way, but it does look
like it gave a minor improvement to CPU usage when many
processes/threads were doing I/O in parallel. Again, this was hard to
accurately test.
that are on a CISS bus to be exported up to CAM and made available as normal
devices. This will typically add one or two buses to CAM, which will be
numbered starting at 32 to allow room for CISS proxy buses. Also, the CISS
firmware usually hides disk devices, but these can also be exposed as 'pass'
devices if you set the hw.ciss.expose_hidden_physical tunable.
Sponsored by: Tape Laboratories, Inc.
MFC After: 3 days
controllers and allows the controller to prefetch 1-2k on certain
PCI memory reads to the host. The spec says this should only be
used for IA32 based systems.
Informed of feature by: John Cagle <first.last@hp.com>
Logical volumes on these devices show up as LUNs behind another
controller (also known as proxy controller). In order to issue
firmware commands for a volume on a proxy controller, they must be
targeted at the address of the proxy controller it is attached to,
not the Host/PCI controller.
A proxy controller is defined as a device listed in the INQUIRY
PHYSICAL LUNS command who's L2 and L3 SCSI addresses are zero. The
corresponding address returned defines which "bus" the controller
lives on and we use this to create a virtual CAM bus.
A logical volume's addresses first byte defines the logical drive
number. The second byte defines the bus that it is attached to
which corresponds to the BUS of the proxy controller's found or the
Host/PCI controller.
Change event notification to be handled in its own kernel thread.
This is needed since some events may require the driver to sleep
on some operations and this cannot be done during interrupt context.
With this change, it is now possible to create and destroy logical
volumes from FreeBSD, but it requires a native application to
construct the proper firmware commands which is not publicly
available.
Special thanks to John Cagle @ HP for providing remote access to
all the hardware and beating on the storage engineers at HP to
answer my questions.
