[ofa-general][PATCH v2 1/2]mlx4: Multiple completion vectors support

Or Gerlitz ogerlitz at voltaire.com
Thu Jun 19 07:39:05 PDT 2008


Roland Dreier wrote:
> Well, both of your statements seem to be true: nothing sets the affinity for the interrupts created for multiple EQs, and there is not any simply way to guarantee that CQ vector 5 is sent to CPU 5 that I see.
I start to understand now.. so the suggested patch does not implement 
interrupt affinity for the different EQs. What's needed to have such 
affinity? should it be a feature of the HW?

I still don't follow the second part of your reply, what's the 
difference from EQ to "CQ vector", I was thinking that its just two ways 
to describe the same thing.

Looking on the change-log of the initial commit from last year, I see 
that interrupt affinity is mentioned.

Or.

> commit f4fd0b224d60044d2da5ca02f8f2b5150c1d8731
> Author: Michael S. Tsirkin <mst at dev.mellanox.co.il>
> Date:   Thu May 3 13:48:47 2007 +0300
>
>     IB: Add CQ comp_vector support
>     
>     Add a num_comp_vectors member to struct ib_device and extend
>     ib_create_cq() to pass in a comp_vector parameter -- this parallels
>     the userspace libibverbs API.  Update all hardware drivers to set
>     num_comp_vectors to 1 and have all ULPs pass 0 for the comp_vector
>     value.  Pass the value of num_comp_vectors to userspace rather than
>     hard-coding a value of 1.
>     
>     We want multiple CQ event vector support (via MSI-X or similar for
>     adapters that can generate multiple interrupts), but it's not clear
>     how many vectors we want, or how we want to deal with policy issues
>     such as how to decide which vector to use or how to set up interrupt
>     affinity.  This patch is useful for experimenting, since no core
>     changes will be necessary when updating a driver to support multiple
>     vectors, and we know that we want to make at least these changes
>     anyway.
>     
>     Signed-off-by: Michael S. Tsirkin <mst at dev.mellanox.co.il>
>     Signed-off-by: Roland Dreier <rolandd at cisco.com>
>   





More information about the general mailing list