On Thu, May 19, 2011 at 8:41 PM, Jason Gunthorpe
wrote:
> This is why in the IB verbs architecture nearly everything is tied to
> a *device*, not a port.
LIO has a feature called "access control lists" that allows to define
which initiators are allowed to log in to a target. For a single-rail
HCA
On Thu, 2011-05-19 at 12:40 +0200, Bart Van Assche wrote:
> On Thu, May 19, 2011 at 6:18 AM, Nicholas A. Bellinger
> wrote:
> > 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/s
On Thu, May 19, 2011 at 08:34:08PM +0200, Bart Van Assche wrote:
> My reply applies to your original statement where you were referring
> to APM with different destination ports. What you write above is about
> APM with identical destination ports and hence does not apply to my
> reply.
The subnet
On Thu, May 19, 2011 at 7:44 PM, Jason Gunthorpe
wrote:
> On Thu, May 19, 2011 at 07:29:21PM +0200, Bart Van Assche wrote:
> > Regarding APM: the Linux kernel already has multipath support and
> > duplicate functionality is in general not welcomed. So you will have
> > to come up with a very good
On Thu, May 19, 2011 at 07:29:21PM +0200, Bart Van Assche wrote:
> Regarding APM: the Linux kernel already has multipath support and
> duplicate functionality is in general not welcomed. So you will have
> to come up with a very good reason before APM support in ib_srp or
> ib_srpt would be conside
On Wed, May 18, 2011 at 7:05 PM, Jason Gunthorpe
wrote:
> Many installations run dual rail IB with a desire
> for both ports to be active and handling traffic at once. Not sure how
> this translates to SRPT, but a good goal would be for a SRPT target to
> be available on both HCA ports and support
On Thu, May 19, 2011 at 12:40:02PM +0200, Bart Van Assche wrote:
> I'm still wondering whether it was a good idea to switch from ib
> style names to port GIDs. Not only will that make it hard for users to
> match the ib names already assigned to InfiniBand HCAs with target
> port names but this al
On Thu, May 19, 2011 at 6:18 AM, Nicholas A. Bellinger
wrote:
> 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 attemp
On Wed, 2011-05-18 at 03:47 -0400, Christoph Hellwig wrote:
> > +ccflags-y := -Idrivers/target
>
> Why do you need the ccflags? Everything needed should be under
> include/target, and if not that needs to be fixed.
>
> > +#include
> > +#include
> > +#include
> > +#include
>
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 a
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 configuratio
On Wed, May 18, 2011 at 7:05 PM, Jason Gunthorpe
wrote:
> On Wed, May 18, 2011 at 06:59:36PM +0200, Bart Van Assche wrote:
>
>> As far as I know InfiniBand HCAs have either one or two ports. If
>> there are two ports present, at most one is active at any time.
>
> This is not true, many installati
On Wed, May 18, 2011 at 06:59:36PM +0200, Bart Van Assche wrote:
> As far as I know InfiniBand HCAs have either one or two ports. If
> there are two ports present, at most one is active at any time.
This is not true, many installations run dual rail IB with a desire
for both ports to be active an
On Wed, May 18, 2011 at 3:36 AM, Nicholas A. Bellinger
wrote:
> ib_srpt: Convert se_wwn endpoint reference to struct srpt_port->port_wwn
> http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=commitdiff;h=4e544a210acb227df1bb4ca5086e65bdf4e648ea
Why has that change been implemented ?
> We really need to stop spreading that include. Care to submit a patch
> for .40 to move the TASK_ATTR_* defines to scsi/scsi.h?
Sounds simple enough even for me to do. I'll send one in a little bit...
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body o
> +ccflags-y:= -Idrivers/target
Why do you need the ccflags? Everything needed should be under
include/target, and if not that needs to be fixed.
> +#include
> +#include
> +#include
> +#include
> +#include /* TASK_ATTR_* */
We really need to stop spreading that include.
16 matches
Mail list logo
