[EMAIL PROTECTED] wrote on Thu, 22 May 2008 16:58 -0500:
> Oh yeah, so let me know what you think would be easier for you? I 
> thought just passing in "-I iser" during discovery would be nice and 
> save a step. If it is worse then let me know. In the end we will have 
> bnx2i, iser, chelsio and tcp, and we will want a quick way to figure out 
> what the user wants to do.

I added "-I iser" to discovery (or "-I default") and things work
again.  Thanks for the multiple suggestions.  My usage model is to
do one-at-a-time login into targets for which I know exactly what
addresses, names, and transport types should be used.

Functionally, it does save a step, but I'm a bit bothered by
having to choose the transport type at discovery time.  It's not
obvious to new iser users that discovery always uses the TCP
transport.  Forcing the use of "-I iser" there might add to their

A bit weird to have to run re-discovery to switch the transport
type, when you know you'll find exactly the same discovered targets,
too.  In theory I might like to connect up an iser and a tcp to the
same target, at the same time, although possibly to different LUNs.

> I was thinking that when the discovery command is run we could look over 
> /sys/class/iscsi_host to see if bnx2i or chelsio had loaded and created 
> a scsi/iscsi host for some hba. If it had then it would be safe to 
> assume that the user wanted to use the offload engines and so we would 
> set the transport to one those modules automatically.
> This does not work for tcp or iser where we allocate a host per session. 
> For iser maybe if there is a infinniband card then maybe we should 
> assume that the user would want to bind to that and we could just do it 
> automaitcally for them?
> For tcp, if no special hardware is found then we could do the default 
> behavior where we just use tcp.

I generally don't like it when anything happens automatically.  :)
For the IB case, we run discovery using TCP on IPoIB, and sometimes
want to run data over IPoIB too.  Trying to use iser if an IB card
is present is not always the right thing to do.  So please always
default to TCP.

For the iscsi offload case, I'm guessing these devices also allow
you to run normal non-offloaded IP over them too, in which case I'd
apply a similar argument.  Although I see your point about users
just wanting to use their hardware directly, without needing to
specify what type it is.

You could always do the automagic in the init script, rather than in
iscsiadm, and us hands-on types can continue to use our own custom
init scripts.

[in another mail]
> Oh yeah the userspace tools from 869.2 should work with
> 2.6.26-rc3.

This is important, thanks.  Userspace git head fails with stock
2.6.26-rc3 due to the introduction of
creation".  Guess I should pull in your git kernel tree too.

                -- Pete

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi

Reply via email to