On Wed, Jan 6, 2010 at 10:40 PM, Roland Dreier wrote:
>
> > Is that regular kernel coding practice, to run away with the work
> > someone else did and to claim authorship ? As far as I know this is
> > considered as impolite.
>
> I don't see "with proper credit for Bart" as claiming authorship.
> It was only recently that I had the time to analyze this issue in
> depth and that I added SRP_CRED_REQ support in SCST (checked in that
> support about one week ago). Before SRP_CRED_REQ support was added in
> SCST, the SRP initiator could not log the "Unhandled SRP opcode"
> message becau
> With this not being a regression, I see that it went into your
> for-next branch and as such I assume will be available by 2.6.34. Are
> you fine with the patch going into the -stable series?
Actually I was planning on sending it for 2.6.33, since it's so small
and obvious and we're reasonab
On Wed, Jan 6, 2010 at 10:37 PM, Roland Dreier wrote:
>
> > When the SRP initiator is communicating with an SRP target under load it
> can
> > happen that the SRP initiator locks up. The communication pattern that
> causes
> > the lockup is as follows:
> > * SRP initiator sends (req_lim - 2)
Roland Dreier wrote:
> thanks, applied.
With this not being a regression, I see that it went into your for-next branch
and as such I assume will be available by 2.6.34. Are you fine with the patch
going into the -stable series?
Or.
--
To unsubscribe from this list: send the line "unsubscribe l
On Wed, 2010-01-06 at 17:16 -0700, Chris Worley wrote:
> 1) I'm seeing small block random writes (32KB and smaller) get better
> performance over SRP than they do as a local drive. I'm guessing this
> is async behavior: once the written data is on the wire, it's deemed
> complete, and setting a sy
In shifting through a great deal of benchmark data collected from two
identical machines (including the attached drive array), I see the
following SRP anomalies:
1) I'm seeing small block random writes (32KB and smaller) get better
performance over SRP than they do as a local drive. I'm guessing
On Wed, 2010-01-06 at 13:48 -0800, Roland Dreier wrote:
> Looks pretty good; a few minor comments:
>
> > +static int srp_response_common(struct srp_target_port *target, s32
> req_delta,
> > + void *rsp, int len);
>
> Didn't check -- can we reorder things to avoid this f
> Is there a good function to dump SCSI sense data? If so, then it makes
> sense to dump it, yeah. Better yet, inject it into the SCSI mid-layer.
A quick look doesn't find any sense-dumping function. Probably not
worth worrying about it until someone starts seeing async errors anyway.
> Only
Looks pretty good; a few minor comments:
> +static int srp_response_common(struct srp_target_port *target, s32
> req_delta,
> + void *rsp, int len);
Didn't check -- can we reorder things to avoid this forward declaration?
> +shost_printk(KERN_ERR, target->scsi_
> Is that regular kernel coding practice, to run away with the work
> someone else did and to claim authorship ? As far as I know this is
> considered as impolite.
I don't see "with proper credit for Bart" as claiming authorship. And
yes, I think proposing a better way of doing things is defi
> I agree that we should add support for SRP_CRED_REQ, but I'm not
> thrilled with the mix of changes in the patch, as well as the general
> aesthetics of the result. How about something like the following series
> -- posted as a follow up to this message -- with proper credit for Bart?
> I'l
> When the SRP initiator is communicating with an SRP target under load it can
> happen that the SRP initiator locks up. The communication pattern that causes
> the lockup is as follows:
> * SRP initiator sends (req_lim - 2) SRP_CMD requests to the target.
> * The REQUEST LIMIT DELTA field of
I'm at a loss to figure out what's going wrong and hoping you can help.
OFED 1.5.rc6, RHEL5.4 initiator, Solaris target
Initially, srp_daemon could discover the target and establish a session
(we're using run_srp_daemon). Pulled the cable from one of the 2 target
ports and all remained well. R
Thanks, applied.
I think I added this error in the first place as part of the
[ Fix up cma_check_linklocal() for !IPV6 case. - Roland ]
"work" I did on the original commit d14714df.
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to m
thanks, applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
thanks, applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 14:41 Tue 01 Dec , Hal Rosenstock wrote:
>
> Optimized SLtoVLMappingTable programming reduces the number of MADs
> needed from O(n**2) to O(n). See IBA 1.2.1 vol 1 p. 843 14.2.5.8
> SLtoVLMappingTable.
>
> Signed-off-by: Hal Rosenstock
Rebased and Applied. Thanks.
Sasha
--
To unsubscrib
Make sure compiler won't do weird things with limits. E.g. fetching
them twice may return 2 different values after writable limits are
implemented.
I.e. either use rlimit helpers added in
3e10e716abf3c71bdb5d86b8f507f9e72236c9cd
or ACCESS_ONCE if not applicable.
Signed-off-by: Jiri Slaby
Acked-b
Sean, you're right. These conditionals are not required as RoCEE and
IB have the same node transport type. All that needs to be done is
remove them. I'll fix that.
On Tue, Jan 05, 2010 at 03:00:09PM -0800, Sean Hefty wrote:
> >@@ -2941,21 +2960,24 @@ static void ib_mad_init_device(struct ib_device
20 matches
Mail list logo
