[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 confusion. 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 ISCSI_UEVENT_CREATE_BOUND_SESSION in "pass ep to session 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 firstname.lastname@example.org To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---