[openib-general] FW: [PATCH fixed] [RFC] IB/srp: enable multiple connections to the same target

[Michael S. Tsirkin]

Quoting r. Lakshmanan, Madhu <mlakshmanan at silverstorm.com>:
> Subject: RE: FW: [PATCH fixed] [RFC] IB/srp: enable multiple connections to the same target
> 
> > > 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?

Not yet.

> > > 2. Maintain the earlier default of the initiator extension being equal
> > > to the port number.
> > 
> > Hmm. What, exactly, is the target assumption?
> 
> 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.

OK,thanks.
So we need to document this.
Could you pls post a short text describing the issue,
who is affected and what needs to be done by the user?

-- 
MST