Re: [Scst-devel] [SPF:fail] Re: FC initiator performance tanks once target mode is enabled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Nicholas,

On Sat, 2013-12-14 at 10:51 -0600, Dr. Greg Wettstein wrote:
> On Dec 12, 11:45am, "Nicholas A. Bellinger" wrote:
> > > What I would prefer myself is to have a single set of target drivers
> > > that works for both LIO and SCST. That would not only make both projects
> > > easier to maintain but also would expose all target drivers to wider
> > > testing. However, since the interface between target core and target
> > > drivers is very different for LIO and for SCST reaching this goal would
> > > be a challenging project by itself.
> 
> > After spending 18+ months on qla2xxx target code, and getting it
> > into a state that it could withstand public scrutiny for mainline
> > acceptance, I have no interest in making changes to mainline driver
> > code for supporting someone else's out-of-tree stuff.
> 
> I believe, to be fair, that if it took 18 months to get the qla2x00t
> code ported into the kernel that it would have taken even longer to
> get fibre-channel support for the in-kernel target stack if the
> process would have started from scratch.  The kernel implementation
> stands very heavily on engineering work which Vlad, ID7 and others put
> into the target code.
> 
> Secondary to implementing the sqatgt driver I have been through every
> line of both Vlad's code and your derivative work.  It is a straight
> forward exercise to follow both pieces of work side by side.
> 
> So despite all the hostility and rancor which surrounds the two major
> Linux SCSI target implementations, lets concede that the in-kernel
> fibre-channel driver benefited a great deal from the efforts of the
> SCST community.  This coming from someone who arranged for a small
> amount of financial support for some of the code which is currently
> residing in the in-kernel Qlogic target driver.
> 
> > We don't add interfaces into mainline drive code to support
> > out-of-tree projects, because quite frankly, it gives less incentive
> > for the out-of-tree holdouts to use, improve and contribute to
> > mainline target code.
> 
> But the kernel does provide services to external users through a
> binary API supplied by exported symbols.  Your work on the Qlogic
> fibre-channel target driver includes all but one small function needed
> to allow SCST to use the in kernel driver.
> 
> To Nicholas' credit, the engineering work done on the qla2x00t driver,
> as a component of porting it into the kernel, provides almost all of
> the resources needed for a straight forward integration of SCST.
> Having anticipated this debate we focused on designing the sqatgt
> interface driver so it would integrate cleanly with the architectural
> model selected for the kernel.
> 
> Bart, if you could review the in-kernel Qlogic driver you will find
> the the tcm_qla2xxx.c module interfaces the Qlogic driver with the
> in-kernel SCSI target engine.  Similar functionality is provided by
> the scst_qla2xxx.c in the sqatgt driver for SCST.  So there is a
> reasonably straight forward and standardized approach for getting both
> projects on a common driver infrastructure, which as you note benefits
> everyone.
> 
> The only missing piece of the puzzle is an exported function to
> enumerate the target interfaces which are available.  Since there are
> exported functions to enable/disable interfaces, handle session
> management and a variety of other functions it doesn't seem
> unreasonable to provide a method of enumerating which interfaces are
> available for target mode.
> 
> So Nicholas in the spirit of everyone working for the common good of
> the storage community I'm hoping you will support our proposal of the
> following patch to Andrew Vasquez and the Qlogic maintainers:
> 
> ---------------------------------------------------------------------------
> +void
> +qlt_get_target_list(void (*callback)(struct scsi_qla_host *))
> +{
> +       struct qla_tgt *tgt;
> +
> +        mutex_lock(&qla_tgt_mutex);
> +        list_for_each_entry(tgt, &qla_tgt_glist, tgt_list_entry) {
> +               (*callback)(tgt->vha);
> +       }
> +        mutex_unlock(&qla_tgt_mutex);
> +
> +       return;
> +}
> +EXPORT_SYMBOL(qlt_get_target_list);
> ---------------------------------------------------------------------------
> 
> Which provides the only missing piece needed for SCST to live happily
> on as a modular extension to the kernel.  With this in place we can
> all focus on more pressing issues, such as why Steve Magnani can't get
> two ports on the same ISP chip to run in different modes.

I have code from QLogic that appears to resolve the issue with which I
started this thread, namely crummy initiator performance when the same
physical port is configured for dual initiator and target mode. QLogic's
code appears to be a fusion of the mainline qla2xxx driver and SCST,
which makes it taxonomically close to Greg's sqatgt proposal.

Once I figure out which portions of QLogic's code resolve the issue I
would be happy to post them as patches to mainline. But I can't justify
the effort to do that if Greg's proposal is DOA, since I wouldn't be
able to make use of the resulting patched code.

As an engineer with a problem to solve and a deadline, I don't much care
whether the name of the solution is LIO or SCST. But it is a necessity
of my project that the target implementation reside in userland. AFAIK
LIO does not support this, nor plan to. 

I agree with core kernel maintainers that encouraging out-of-tree binary
drivers (a la NVidia) is a Bad Thing, but that's not what's being
requested here. Please don't throw the baby out with the bathwater.

Regards,
------------------------------------------------------------------------
 Steven J. Magnani               "I claim this network for MARS!
 www.digidescorp.com              Earthling, return my space modulator!"

 #include <standard.disclaimer>

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux