Re: [GIT PULL] isci merge candidate

[Dan Williams]

On Fri, May 13, 2011 at 3:16 PM, Benjamin Herrenschmidt
<benh@xxxxxxxxxxxxxxxxxxx> wrote:
>
>> It's a SAS (serial-attached-scsi) driver so it ties in to libsas rather
>> than libata (libsas itself ties in to libata for tunnelling SATA
>> protocol over SAS).  The size is attributable to the fact that all
>> protocol handling for non-fast path i/o is handled by software.  There
>> are still cleanups that can be made, but likely not on the on the same
>> order of what we have already done.
>
> How much of that non-fast-path could/should be in generic code vs. in
> the driver specific code ? IE. If somebody comes up with another "dumb"

I prefer the word "thin" :-), where "fat" refers to controllers that
hide this logic in offload cpu's, firmware, and or custom asics.

> SAS adapter tomorrow that doesn't do all that magic in an offload CPU,
> is any of that code re-usable ?

At a minimum It would require a more verbose interface to
libsas/libata (or new libframe?) to allow us to deliver raw
unsolicited frames into common protocol handlers.  The concern would
be wrangling different sets of protocol states and exception
conditions that individual vendors would choose to/not to offload.  To
date no other libsas based controller has taken this approach.

--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/