[openib-general] FW: [PATCH fixed] [RFC] IB/srp: enable multiple connections to the same target
Lakshmanan, Madhu
mlakshmanan at silverstorm.com
Mon Oct 9 10:04:51 PDT 2006
> > I tested the patches, which are included in OFED 1.1 RC7, against
> > Silverstorm SRP targets. The patch breaks backward compatibility for
> > fabrics that use Silverstorm targets, due to the following:
> >
> > It defaults the new parameter "initiator_ext" to 0. Silverstorm SRP
> > targets, when configured for working with OFED stacks, are usually
set
> > to expect an initiator extension of 1, to overcome the earlier
> > limitation of OFED stacks setting initiator extension to the port
> > number.
>
> Sounds like a target bug - why does it expect *anything* specific
> in the initiator extension?
The Silverstorm SRP targets can be configured to accept connections from
specific hosts (identified by GUID) and / or specific initiator
extensions.
This allows for a scenario where a group of hosts can gain access to the
same back-end storage device, by using the same initiator extension
across all the hosts, with the host GUID being ignored / wildcarded on
the SRP target. It also facilitates a level of access control to
back-end storage devices and permits the grouping of hosts into logical
groups.
In order to interoperate successfully with the OFED 1.0 stack, such SRP
targets were configured to expect the initiator extension reported by
the OFED 1.0 SRP implementation, i.e. an initiator extension of 1. Note
that
for this particular configuration the host GUID is wildcarded, and the
only
unique identifier is the initiator extension.
> > 1. Release note the above requirement of adding the
"initiator_ext=<n>"
> > string to the add target echo string, for all Silverstorm targets.
>
> I don't think we'll be touching OFED 1.1 anymore. So maybe this is
> the best choice for kernel.org, too.
>
Are the release notes / docs frozen as well?
> > 2. Maintain the earlier default of the initiator extension being
equal
> > to the port number.
>
> Hmm. What, exactly, is the target assumption?
>
> --
> MST
The target doesn't assume or default anything. It is how it is
configured. The current patch breaks existing Silverstorm SRP target
configurations, unless either:
1. The user specifies the "initiator_ext=<n>" when adding a target,
which is not to be found anywhere in the release notes, or
2. The configuration on the SRP target is modified to reflect the
changes in OFED 1.1 where the initiator extension is passed to the
target as 0, if the user doesn't specify it, which again is not
specified in the release notes.
Madhu
More information about the general
mailing list