RE: iSCSI: "Wedge" drivers

[Michael Krause <krause@cup.hp.com>]

At 05:30 PM 8/28/00 -0700, John Hufferd/San Jose/IBM wrote:

>structure.  With this is mind, it seems to me, that we can move to a
>position (perhaps over time) where the iSCSI Device Driver is able to
>perform the load balancing, and alternate path recovery, yet leave other
>functions for a higher level Wedge Driver to perform.  This tends to keep
>the upper layers, simpler and easier to write and maintain.

This is exactly the point of the previous discussion on QoS, dealing with 
fabric events (hot-plug / removal), path selection, etc.  Keep these 
problems outside of the upper layers but define the interfaces and basic 
policies within the iSCSI layer and standardize that.  This simplifies 
quite a bit of the implementation since one can choose what operations they 
support and to what extent while allowing one to transparently upgrade 
their offerings while maintaining complete backward compatibility and 
interoperability.

>If the above concept seems reasonable, then we need to keep the Multiple
>Conversations per Session.

Agreed.

>Again let me state my belief that the implementations that will ship out,
>originally, will be Single Conversations per Session, especially since it
>is easier and the default.  This will mean that some of the current Wedge
>Device Drivers will remain unchanged, and therefore, alternate path
>recovery with load balancing will be done, (or not) at this layer.
>However, over time, I think this will change -- as the various vendors have
>time to implement the Multiple Conversations per Session.  This will
>permit, in some cases, the elimination of Wedge Device Drivers, but
>probably just the simplification of the Wedge Device Drivers.

Wedge drivers may provide more value-add capabilities in the future 
especially for determining the QoS policies on dynamically changing 
workloads, cost models, and fabrics with changing routes or capabilities 
(these are also functions that could be done outside of the wedge driver in 
a standard way but leverage the standard interfaces to the iSCSI 
component).  A layered approach keeps iSCSI simple and allows vendors and 
customers to put together the functional and complexity level that best 
meets their market requirements and more easily enhance / modify using a 
phased delivery approach.

Mike