• M
    qed*: Handle-based L2-queues. · 3da7a37a
    Mintz, Yuval 提交于
    The driver needs to maintain several FW/HW-indices for each one of
    its queues. Currently, that mapping is done by the QED where it uses
    an rx/tx array of so-called hw-cids, populating them whenever a new
    queue is opened and clearing them upon destruction of said queues.
    
    This maintenance is far from ideal - there's no real reason why
    QED needs to maintain such a data-structure. It becomes even worse
    when considering the fact that the PF's queues and its child VFs' queues
    are all mapped into the same data-structure.
    As a by-product, the set of parameters an interface needs to supply for
    queue APIs is non-trivial, and some of the variables in the API
    structures have different meaning depending on their exact place
    in the configuration flow.
    
    This patch re-organizes the way L2 queues are configured and maintained.
    In short:
      - Required parameters for queue init are now well-defined.
      - Qed would allocate a queue-cid based on parameters.
        Upon initialization success, it would return a handle to caller.
      - Queue-handle would be maintained by entity requesting queue-init,
        not necessarily qed.
      - All further queue-APIs [update, destroy] would use the opaque
        handle as reference for the queue instead of various indices.
    
    The possible owners of such handles:
      - PF queues [qede] - complete handles based on provided configuration.
      - VF queues [qede] - fw-context-less handles, containing only relative
        information; Only the PF-side would need the absolute indices
        for configuration, so they're omitted here.
      - VF queues [qed, PF-side] - complete handles based on VF initialization.
    Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
    Signed-off-by: NDavid S. Miller <davem@davemloft.net>
    3da7a37a
qed_eth_if.h 7.1 KB