lkml.org 
[lkml]   [2011]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [GIT PULL] isci merge candidate
From
On Fri, May 13, 2011 at 3:16 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2011-05-17 02:41    [W:0.057 / U:34.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site