lkml.org 
[lkml]   [1999]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Fixing the SCSI layer
Date
From


On Sun, 5 Sep 1999 tad-m2n@omoikane.co.jp wrote:

> Alan wrote:
> > The code is too heavy weight. I See performance limits with the Sym=
bios
> > FC card too. In paticular the commands/second is very very limited.

As I wrote in some other mail, I doubt it is our old SCSI code that lim=
its
the commands/second throughtput. Some latency from device (including th=
e
=46C card) may well be the cause.

> In addtion to the performance, I feel that not-command-oriented layer=
is=20
> required, in order to:
>=20
> - implement FC/net layer on the top of mid-layer.
> (this may include target mode driver)

Hmmm. We can imagine any kind of control when the host acts as a target=
=2E
Layers + full control =3D slow, in my opinion.
Perhaps something like the CAM3 "host target mode" should be enough.

> - have better sg driver (ex, abort handling, etc)

What do you want to abort ? Once a command has been passed to the lowe=
r
layer, it must complete with or without error, or time out.
The abort of a command can get hard to perform cleanly, depending on th=
e
actual state of the command you want to abort.=20

> I think that current command-oriented layer is not sufficient for con=
trol=20
> all SCSI functionality.

What is a SCSI functionnality for you ? If you want all possible, you m=
ust
deal directly with the hardware. If you want common fuctionnalities, yo=
u
must interface device drivers that deal with common device models. If y=
ou
want to have a handle on the commands sent to a device, you must use
"passthru" services and deal with the device model (and features) by
yourself.

> As described in section 'Future Derections' of enhanced sg's manual,
> I would also like to invest CAM driver in FreeBSD.

I suggest you to invest CAM3 specifications first. The FreeBSD CAM is a
derivative and is very different from official CAM1/3 on some points. I=
t
has also some design/implementation errors in my opinion.=20
=46or example, the SIM queuing (CAM3 10.4.2-10.4.3) implementation in
=46reeBSD can only have race conditions on error recovery (queue freeze=
), in
my opinion.=20
But obviously FreeBSD CAM seems to be a far better SCSI stack that the
current Linux SCSI code and looking into it is certainly very interesti=
ng.

> I am not thinking too much, but I imagine below is one of choice.
>=20
> step1 : implement CAM layer.

You mean CAM3. In my opinion, 1 year full time minimum + bunches of SIM=
s
(low level drivers) to adapt or rewrite.

> step2 : make a 'wrapper' of low driver to the CAM layer.

Not a good idea, in my opinion. My suggestion is to allow both the CAM
stack and the old SCSI stack to be configured in the kernel, allowing
low-level drivers (SIMs) to be converted when time will allow.=20

> this wrapped driver is limited in functionality.
> step3 : implement CAM specific low and high layer and
> implemnt net and sg target mode layer.
> It is safer that new sd/sg layer uses different device file=
s,
> in order to leave current interfaces.
>=20
> Does someone have this kind of curiousity?

I have had any kind of curiousity about SCSI.

> I would like to see if my thought is acceptable by linux hackers.
> If there is already such a plan, I hope to help it.

I don't have such a plan due to lack of time.

G=E9rard.


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



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

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.044 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site