Re: Ang: Re: [Stgt-devel] Re: [Iscsitarget-devel] stgt a new version of iscsi target?

[James Bottomley <James.Bottomley@SteelEye.com>]

On Thu, 2005-12-08 at 21:46 +0300, Vladislav Bolkhovitin wrote:
>   - Scst has some performance advantages over stgt, at least, on 
> hardware targets, because it allows internal handling in SIRQ context as 
> well as doesn't need user space program, so it eliminates additional 
> context switches (at least 3 per command for WRITEs and 2 per command 
> for reads plus switches to user space daemon, probably, 2 per command). 
> 5 context switches per command looks too much for me, especially 
> considering how little work is done on each context. It means ~15000 
> CS/sec on regular 200Mb/sec link with 64K block size. Additionally, 
> kernel only commands execution allows direct access to page cache, which 
> is GREAT performance improvement, because in architecture with user 
> space daemon the data should be copied several times between kernel and 
> user space. Or, do I miimpss anything?

I do have to say that I consider operation in interrupt context (or even
kernel context) to be a disadvantage.  Compared with the response times
that most arrays have to SCSI commands, the kernel context switch time
isn't that significant.

Additionally, it's perfectly possible for all of this to be done zero
copy on the data.  A user space target mmaps the data on its storage
device and then does a SG_IO type scatter gather user virtual region
pass to the underlying target infrastructure.  We already have this
demonstrated in the SG_IO path, someone just needs to come up with the
correct implementation for a target path.

The great advantage of doing SCSI state machines in user space is that
you can prototype anything you want, and user space has much better
state machine implementation (and debugging) tools available than the
kernel does.

James