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
>
Hi Yan,
it appears that you're using quite an old firmware. Could you upgrade
the firmware to the latest version and check again the failure to
create a QP with the max depth. FW and burning tools can be downloaded
from www.mellanox.com.
Another possible reason for the failures you were seeing is
What about something along the lines of the following? This is 2 incomplete
patches squashed together, lacking any serious documentation. I believe this
will support existing apps and driver libraries, as either binary or
re-compiling unmodified source code.
A driver library calls ibv_registe
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
Adapt new APIs. we plan to remove old one later and plan to
change current->cpus_allowed implementation.
No functional change.
Signed-off-by: KOSAKI Motohiro
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc: linux-rdma@vger.kernel.org
Cc: Mike Marciniszyn
Cc: Ralph Campbell
---
drive
Adapt new api. we plan to remove old one later. Almost change are
trivial. but there is one real fix. following code is unsafe.
int ncpus = num_online_cpus()
for (i = 0; i < ncpus; i++) {
..
}
because 1) we don't guarantee last bit of online cpus is equal
t
On Wed, May 18, 2011 at 10:30 AM, Hefty, Sean wrote:
>> As long as the version number in the ibv_context is increasing and not
>> branching then I think it is OK. 0 = what we have now. 1 = + XRC, 2 =
>> +XRC+ummunotify, etc. Drivers 0 out the function pointers they do not
>> support.
>
> I was thi
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 06:13:54PM +, Hefty, Sean wrote:
> You need it in the normal send case as well, either outside of the
> union, or part of a new struct within the union.
Works for me..
union {
[..]
struct {
uint64_t reserved1[3];
uint32_t reserved2;
uint32_t remote_q
> The size is 3*64 + 1*32 so there is a 32 bit pad, thus we can rewrite
> it as:
>
> union {
> struct {
> uint64_tremote_addr;
> uint32_trkey;
> uint32_txrc_remote_qpn;
>
On Wed, May 18, 2011 at 05:30:30PM +, Hefty, Sean wrote:
> > As long as the version number in the ibv_context is increasing and not
> > branching then I think it is OK. 0 = what we have now. 1 = + XRC, 2 =
> > +XRC+ummunotify, etc. Drivers 0 out the function pointers they do not
> > support.
>
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
> As long as the version number in the ibv_context is increasing and not
> branching then I think it is OK. 0 = what we have now. 1 = + XRC, 2 =
> +XRC+ummunotify, etc. Drivers 0 out the function pointers they do not
> support.
I was thinking more along this line, but I can see how using a named e
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 09:44:01AM -0700, Roland Dreier wrote:
> and have support for named extensions, I think that would be even
> better. ie we could define a bunch of new XRC related stuff and
> then have some interface to the driver where we ask for the "XRC"
> extension (by name with a stri
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
On Mon, May 16, 2011 at 2:13 PM, Hefty, Sean wrote:
> libibverbs
> --
> We define a new device capability flag IBV_DEVICE_EXT_OPS, indicating that
> the library supports extended operations. If set, the provider library
> returns an extended structure from ibv_open_device():
>
>
> Great that you are taking this on! I will review this next week.
Hopefully I'll have some early patches sometime next week. See below for my
current thoughts based on how the implementation is progressing. My thoughts
change hourly.
> > From an architecture viewpoint, XRC adds 4 new XRC sp
Sean,
Great that you are taking this on! I will review this next week.
-Jack
On Tuesday 17 May 2011 00:13, Hefty, Sean wrote:
> I've been working on a set of XRC patches aimed at upstream inclusion to the
> kernel, libibverbs, and librdmacm. I'm using existing patches as the major
> starting
> +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.
On 5/17/2011 11:09 PM, i...@celticblues.com wrote:
That is correct. I did make those necessary corrections.
E
I've seen the problem back then (when you originally posted it) and had no good
answer.
If you can me the changes you already made on the code, I would be happy to
help.
Ido
Qu
22 matches
Mail list logo
