Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753067Ab1ESE02 (ORCPT ); Thu, 19 May 2011 00:26:28 -0400 Received: from mail.linux-iscsi.org ([67.23.28.174]:57328 "EHLO linux-iscsi.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750831Ab1ESE01 (ORCPT ); Thu, 19 May 2011 00:26:27 -0400 Subject: Re: [RFC] ib_srpt: initial .40-rc1 drivers/infiniband/ulp/srpt merge From: "Nicholas A. Bellinger" To: Roland Dreier Cc: Bart Van Assche , Jason Gunthorpe , linux-kernel , linux-scsi , linux-rmda , Vu Pham , David Dillow , James Bottomley In-Reply-To: References: <1305682604-21383-1-git-send-email-nab@linux-iscsi.org> <20110518170556.GB2595@obsidianresearch.com> Content-Type: text/plain Date: Wed, 18 May 2011 21:18:14 -0700 Message-Id: <1305778694.2856.533.camel@haakon2.linux-iscsi.org> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2656 Lines: 59 On Wed, 2011-05-18 at 12:17 -0700, Roland Dreier wrote: > On Wed, May 18, 2011 at 11:02 AM, Bart Van Assche wrote: > > Thanks for the feedback. I'm still wondering though about the > > usefulness of disabling / enabling SRPT per HCA port. For the use > > cases I know about SRP communication over all target ports will be > > enabled as soon as target configuration has finished and more > > fine-grained access configuration will occur by allowing/disallowing > > certain initiators to log in. > > I definitely think that allowing the flexibility to configure ports individually > is required. It's easy to imagine a case with a separate front-end and > back-end networks on the two HCA ports (this would be a pretty normal > ethernet config), where only one port should be a target port. > > It may not be how people do things now but it should at least be possible. > Hey guys, Apologies for the slightly delay response here.. Just to clarify on Bart's point above. The srpt_port->port_wwn patch in question does current ensure that sport->enabled has been set via an configfs attribute at: /sys/kernel/config/target/srpt/$IB_PORT_GUID/tpgt_1/enable and will reject all SRP login attempts to an individual struct srpt_port until the attribute has been explictly triggered. This allows ib_srpt to follow what is expected by rtsadmin-v2 + lio-utils, and used to generate /etc/target/srpt_start.sh used to save persistent fabric configuration. Currently other fabrics like iscsi-target and tcm_qla2xxx expect to be able to reject fabric login requests before the full set of WWPN endpoints, LUNs, NodeACLs + MappedLUNs have been recreated during an typical init.d/target start operation. I think it makes sense to do the same for the SRPT control plane on an individual HCA port GUID basis as long as there are no underlying fabric issues, and that Roland is happy. In terms of supporting more than one type of /sys/kernel/config/target/srpt/$WWPN/$TPGT/ layout, I would really like to avoid this for mainline code unless there is a really good reason.. Also, I think ib_srpt needs to properly support 'demo-mode' operation in /var/target/fabric/ib_srpt.spec as this is very useful for testing and development purposes. I go ahead and get this added to upstream LIO v4.1 in the next days and respin for mainline with Hch's review + Bart's changes. Thanks folks, --nab -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/