> -#define HCA_CAP_MR_PGSIZE_4K 1
> -#define HCA_CAP_MR_PGSIZE_64K 2
> -#define HCA_CAP_MR_PGSIZE_1M 4
> -#define HCA_CAP_MR_PGSIZE_16M 8
> +#define HCA_CAP_MR_PGSIZE_4K 0x8000
> +#define HCA_CAP_MR_PGSIZE_64K 0x4000
> +#define HCA_CAP_MR_PGSIZE_1M 0x2000
> +#define HCA_CAP_
What happens if someone runs the new driver with older firmware? Or
what if someone upgrades the firmware without updating the driver?
- R.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied 1 and 2.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
I don't understand this patch. says this about
ib_create_qp():
* @qp_init_attr: A list of initial attributes required to create the
* QP. If QP creation succeeds, then the attributes are updated to
* the actual capabilities of the created QP.
So it seems the current code is actually cor
> Haven't got any ack for this updated patch yet. Anyway, since it contains
> another bug as shown below, please ignore this patch. We'll send a patch
> set that includes the proper version of this patch later.
Yes, sorry, I'm a bit behind applying patches.
Anyway, OK I'll wait for a fixed pa
> remap_4k_pfn is defined in terms of remap_pfn_range if the base page
> size if 4k, so you don't need this #ifdef afaics.
Good point. I'll wait for an updated patch.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/lis
> Was going to recreate this patch, but then I saw that you
> probably have incorporated it (manually) in your latest git.
> Just want to make sure I'm seeing it right.
Yes, I ended up doing it by hand. Thanks.
___
Linuxppc-dev mailing list
Linuxppc-
thanks, I applied this by hand since it was so trivial.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
the patch looks fine except your mailer seems to have mangled
it... can you resend so I can apply it?
thanks...
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied. I fixed this up myself to work with commit 20c2df83,
which got rid of the destructor argument to kmem_cache_create() -- you
probably want to check my tree to make sure it's OK.
Also the same as I said before about checkpatch.pl's warning:
WARNING: externs should be avoided in .c
thanks, applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied.
BTW, does your SRQ-capable hardware support generating the "last WQE
reached" event? There's not any reliable way to avoid problems when
destroying QPs attached to an SRQ without it, and the IB spec requires
CAs that support SRQs to generate it (o11-5.2.5 in chapter 11 of vol 1).
I applied this, but I agree with checkpatch.pl:
> WARNING: externs should be avoided in .c files
> #227: FILE: drivers/infiniband/hw/ehca/ehca_mrmw.c:67:
> +extern int ehca_mr_largepage;
>
> WARNING: externs should be avoided in .c files
> #949: FILE: drivers/infiniband/hw/ehca/hcp_if.c:753
> Here's some anecdotal evidence :)
> http://lists.openfabrics.org/pipermail/general/2007-May/035758.html
Right, but then we went on to say that we probably want to use
multiple vectors to separate out multiple HCA ports rather than
send/sreceive on the same port. And the current IPoIB implemen
> > Why the module parameter? Is there any reason a user would want to
> > turn this off? Or conversely, why is it off by default?
>
> We're pretty confident this new feature works, but as with all new and
> possibly experimental features, there are chances it might explode your
> machin
> No, I've no figures to provide here. The background of this dist_eqs
> option is actually to allow us testing across all event queues
> without to change the testcases resp consumers to use certain
> event queue number. Thus, I should comment it as EXPERIMENTAL?
Seems like it's just developm
> Add support for MR pages larger than 4K on eHCA2. This reduces firmware
> memory consumption. If enabled via the mr_largepage module parameter, the MR
> page size will be determined based on the MR length and the hardware
> capabilities - if the MR is >= 16M, 16M pages are used, for example.
> @@ -161,8 +161,11 @@ static inline int ehca2ib_return_code(u64 ehca_rc)
applied, but as a further cleanup it seems that ehca2ib_return_code()
should be moved into a .c file and moved out of line -- I think it
would probably shrink the compiled code quite a bit, and as far as I
can see it is nev
> The eHCA driver can now handle multiple event queues (read: interrupt
> sources) instead of one. The number of available EQs is selected via the
> nr_eqs module parameter.
> CQs are either assigned to the EQs based on the comp_vector index or, if the
> dist_eqs module parameter is supplied,
> Note that patch 7 will introduce a few lines over 80 chars that will be
> unindented in patch 8 - I hope that's okay with you.
That's fine -- the 80 column rule is one thing I don't worry about too
much; absurdly long lines are bad, but if a line is, say, 84 chars and
breaking it makes the cod
thanks, I applied these for 2.6.23 and fixed a bunch of minor things
that scripts/checkpatch.pl complained about (since I was in a mood to
do mindless things). In the future please run that yourself and clean
up the obvious things. I generally don't worry about the 80 column
stuff, but it will ca
> +DEFINE_SPINLOCK(hcall_lock);
This can be static. (I fixed it up when I applied the patch)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Out of curiousity, does this mean that a GRH will be sent on all UD
messages (for non-LL QPs)?
What decides if a QP is LL or not?
- R.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
101 - 123 of 123 matches
Mail list logo
