[Stgt-devel] User-mode iSER
Thu Aug 3 05:46:38 CEST 2006
On Thu, 2006-08-03 at 07:33 +0900, FUJITA Tomonori wrote:
> From: Tom Tucker <tom at opengridcomputing.com>
> Subject: Re: [Stgt-devel] User-mode iSER
> Date: Wed, 02 Aug 2006 10:58:40 -0500
> > On Wed, 2006-08-02 at 07:21 +0900, FUJITA Tomonori wrote:
> > [...snip...]
> > > >
> > > > Also, won't a user-mode approach support virtual target devices more
> > > > easily?
> > >
> > > There's no difference. Note that we try to push a small portion of the
> > > iSCSI tcp driver into kernel (iSCSI protocol processing). Both
> > > approaches perform SCSI protocol processing, I/O in user space.
> > > I think that you can easily implement any kind of vitalization, device
> > > vitalization (like virtual tape library) and backing vitalization
> > > (snapshot, encryption, compression, etc) in user space with both
> > > approaches.
> > Yes, I think this is true, in the current design, the target device I/O
> > is done in user space, so adding a new device type to trunk/usr is just
> > as easy. The event that initiates this I/O though comes from the kernel
> > over a netlink socket.
> We don't use netlink because it turned out that we cannot pass
> user-space pointers via netlik due to its philosophy.
> The pathch to replace netlink is at:
> The reason why we cannot netlink is at:
Ah...my bad. I just updated and see that many things have changed. It's
> > Moving this all to user-space "might" make this perform better and
> > simplify the architecture.
> > Do you think this is true or does it create as many problems as it
> > solves?
> I'm not sure. That might be true if we think about only target drivers
> that can be implemented in user-space (iSCSI tcp for generic NICs,
> iSER), but we also need to support target drivers that needs in-kernel
> Anyway, as I said in the first mail, we don't know where iSCSI tcp for
> generic NICs and iSER drivers live. So just wait for few days.
Sure. Thanks for the update.
More information about the stgt