2016-05-11 16:36:16 +03:00
/* QLogic qed NIC Driver
* Copyright ( c ) 2015 QLogic Corporation
*
* This software is available under the terms of the GNU General Public License
* ( GPL ) Version 2 , available from the file COPYING in the main directory of
* this source tree .
*/
# ifndef _QED_L2_H
# define _QED_L2_H
# include <linux/types.h>
# include <linux/io.h>
# include <linux/kernel.h>
# include <linux/slab.h>
# include <linux/qed/qed_eth_if.h>
# include "qed.h"
# include "qed_hw.h"
# include "qed_sp.h"
2016-05-11 16:36:18 +03:00
struct qed_sge_tpa_params {
u8 max_buffers_per_cqe ;
u8 update_tpa_en_flg ;
u8 tpa_ipv4_en_flg ;
u8 tpa_ipv6_en_flg ;
u8 tpa_ipv4_tunn_en_flg ;
u8 tpa_ipv6_tunn_en_flg ;
u8 update_tpa_param_flg ;
u8 tpa_pkt_split_flg ;
u8 tpa_hdr_data_split_flg ;
u8 tpa_gro_consistent_flg ;
u8 tpa_max_aggs_num ;
u16 tpa_max_size ;
u16 tpa_min_size_to_start ;
u16 tpa_min_size_to_cont ;
} ;
2016-05-11 16:36:16 +03:00
enum qed_filter_opcode {
QED_FILTER_ADD ,
QED_FILTER_REMOVE ,
QED_FILTER_MOVE ,
QED_FILTER_REPLACE , /* Delete all MACs and add new one instead */
QED_FILTER_FLUSH , /* Removes all filters */
} ;
enum qed_filter_ucast_type {
QED_FILTER_MAC ,
QED_FILTER_VLAN ,
QED_FILTER_MAC_VLAN ,
QED_FILTER_INNER_MAC ,
QED_FILTER_INNER_VLAN ,
QED_FILTER_INNER_PAIR ,
QED_FILTER_INNER_MAC_VNI_PAIR ,
QED_FILTER_MAC_VNI_PAIR ,
QED_FILTER_VNI ,
} ;
struct qed_filter_ucast {
enum qed_filter_opcode opcode ;
enum qed_filter_ucast_type type ;
u8 is_rx_filter ;
u8 is_tx_filter ;
u8 vport_to_add_to ;
u8 vport_to_remove_from ;
unsigned char mac [ ETH_ALEN ] ;
u8 assert_on_error ;
u16 vlan ;
u32 vni ;
} ;
struct qed_filter_mcast {
/* MOVE is not supported for multicast */
enum qed_filter_opcode opcode ;
u8 vport_to_add_to ;
u8 vport_to_remove_from ;
u8 num_mc_addrs ;
# define QED_MAX_MC_ADDRS 64
unsigned char mac [ QED_MAX_MC_ADDRS ] [ ETH_ALEN ] ;
} ;
qed*: Handle-based L2-queues.
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: Yuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-29 16:47:06 +02:00
/**
* @ brief qed_eth_rx_queue_stop - This ramrod closes an Rx queue
*
* @ param p_hwfn
* @ param p_rxq Handler of queue to close
* @ param eq_completion_only If True completion will be on
* EQe , if False completion will be
* on EQe if p_hwfn opaque
* different from the RXQ opaque
* otherwise on CQe .
* @ param cqe_completion If True completion will be
* receive on CQe .
* @ return int
*/
int
qed_eth_rx_queue_stop ( struct qed_hwfn * p_hwfn ,
void * p_rxq ,
bool eq_completion_only , bool cqe_completion ) ;
2016-05-11 16:36:16 +03:00
qed*: Handle-based L2-queues.
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: Yuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-29 16:47:06 +02:00
/**
* @ brief qed_eth_tx_queue_stop - closes a Tx queue
*
* @ param p_hwfn
* @ param p_txq - handle to Tx queue needed to be closed
*
* @ return int
*/
int qed_eth_tx_queue_stop ( struct qed_hwfn * p_hwfn , void * p_txq ) ;
2016-05-11 16:36:16 +03:00
enum qed_tpa_mode {
QED_TPA_MODE_NONE ,
QED_TPA_MODE_UNUSED ,
QED_TPA_MODE_GRO ,
QED_TPA_MODE_MAX
} ;
struct qed_sp_vport_start_params {
enum qed_tpa_mode tpa_mode ;
bool remove_inner_vlan ;
2016-05-11 16:36:25 +03:00
bool tx_switching ;
2016-05-11 16:36:20 +03:00
bool only_untagged ;
2016-05-11 16:36:16 +03:00
bool drop_ttl0 ;
u8 max_buffers_per_cqe ;
u32 concrete_fid ;
u16 opaque_fid ;
u8 vport_id ;
u16 mtu ;
2016-08-22 13:25:10 +03:00
bool check_mac ;
bool check_ethtype ;
2016-05-11 16:36:16 +03:00
} ;
int qed_sp_eth_vport_start ( struct qed_hwfn * p_hwfn ,
struct qed_sp_vport_start_params * p_params ) ;
struct qed_rss_params {
u8 update_rss_config ;
u8 rss_enable ;
u8 rss_eng_id ;
u8 update_rss_capabilities ;
u8 update_rss_ind_table ;
u8 update_rss_key ;
u8 rss_caps ;
u8 rss_table_size_log ;
u16 rss_ind_table [ QED_RSS_IND_TABLE_SIZE ] ;
u32 rss_key [ QED_RSS_KEY_SIZE ] ;
} ;
struct qed_filter_accept_flags {
u8 update_rx_mode_config ;
u8 update_tx_mode_config ;
u8 rx_accept_filter ;
u8 tx_accept_filter ;
# define QED_ACCEPT_NONE 0x01
# define QED_ACCEPT_UCAST_MATCHED 0x02
# define QED_ACCEPT_UCAST_UNMATCHED 0x04
# define QED_ACCEPT_MCAST_MATCHED 0x08
# define QED_ACCEPT_MCAST_UNMATCHED 0x10
# define QED_ACCEPT_BCAST 0x20
} ;
struct qed_sp_vport_update_params {
u16 opaque_fid ;
u8 vport_id ;
u8 update_vport_active_rx_flg ;
u8 vport_active_rx_flg ;
u8 update_vport_active_tx_flg ;
u8 vport_active_tx_flg ;
2016-05-11 16:36:18 +03:00
u8 update_inner_vlan_removal_flg ;
u8 inner_vlan_removal_flg ;
2016-05-11 16:36:20 +03:00
u8 silent_vlan_removal_flg ;
u8 update_default_vlan_enable_flg ;
u8 default_vlan_enable_flg ;
u8 update_default_vlan_flg ;
u16 default_vlan ;
2016-05-11 16:36:18 +03:00
u8 update_tx_switching_flg ;
u8 tx_switching_flg ;
2016-05-11 16:36:16 +03:00
u8 update_approx_mcast_flg ;
2016-05-11 16:36:23 +03:00
u8 update_anti_spoofing_en_flg ;
u8 anti_spoofing_en ;
2016-05-11 16:36:16 +03:00
u8 update_accept_any_vlan_flg ;
u8 accept_any_vlan ;
unsigned long bins [ 8 ] ;
struct qed_rss_params * rss_params ;
struct qed_filter_accept_flags accept_flags ;
2016-05-11 16:36:18 +03:00
struct qed_sge_tpa_params * sge_tpa_params ;
2016-05-11 16:36:16 +03:00
} ;
int qed_sp_vport_update ( struct qed_hwfn * p_hwfn ,
struct qed_sp_vport_update_params * p_params ,
enum spq_mode comp_mode ,
struct qed_spq_comp_cb * p_comp_data ) ;
/**
* @ brief qed_sp_vport_stop -
*
* This ramrod closes a VPort after all its RX and TX queues are terminated .
* An Assert is generated if any queues are left open .
*
* @ param p_hwfn
* @ param opaque_fid
* @ param vport_id VPort ID
*
* @ return int
*/
int qed_sp_vport_stop ( struct qed_hwfn * p_hwfn , u16 opaque_fid , u8 vport_id ) ;
int qed_sp_eth_filter_ucast ( struct qed_hwfn * p_hwfn ,
u16 opaque_fid ,
struct qed_filter_ucast * p_filter_cmd ,
enum spq_mode comp_mode ,
struct qed_spq_comp_cb * p_comp_data ) ;
2016-05-11 16:36:18 +03:00
/**
* @ brief qed_sp_rx_eth_queues_update -
*
* This ramrod updates an RX queue . It is used for setting the active state
* of the queue and updating the TPA and SGE parameters .
*
* @ note At the moment - only used by non - linux VFs .
*
* @ param p_hwfn
qed*: Handle-based L2-queues.
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: Yuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-29 16:47:06 +02:00
* @ param pp_rxq_handlers An array of queue handlers to be updated .
* @ param num_rxqs number of queues to update .
2016-05-11 16:36:18 +03:00
* @ param complete_cqe_flg Post completion to the CQE Ring if set
* @ param complete_event_flg Post completion to the Event Ring if set
qed*: Handle-based L2-queues.
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: Yuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-29 16:47:06 +02:00
* @ param comp_mode
* @ param p_comp_data
2016-05-11 16:36:18 +03:00
*
* @ return int
*/
int
qed_sp_eth_rx_queues_update ( struct qed_hwfn * p_hwfn ,
qed*: Handle-based L2-queues.
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: Yuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-29 16:47:06 +02:00
void * * pp_rxq_handlers ,
2016-05-11 16:36:18 +03:00
u8 num_rxqs ,
u8 complete_cqe_flg ,
u8 complete_event_flg ,
enum spq_mode comp_mode ,
struct qed_spq_comp_cb * p_comp_data ) ;
2016-08-16 10:51:03 -04:00
void qed_get_vport_stats ( struct qed_dev * cdev , struct qed_eth_stats * stats ) ;
qed*: Handle-based L2-queues.
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: Yuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-29 16:47:06 +02:00
void qed_reset_vport_stats ( struct qed_dev * cdev ) ;
struct qed_queue_cid {
/* 'Relative' is a relative term ;-). Usually the indices [not counting
* SBs ] would be PF - relative , but there are some cases where that isn ' t
* the case - specifically for a PF configuring its VF indices it ' s
* possible some fields [ E . g . , stats - id ] in ' rel ' would already be abs .
*/
struct qed_queue_start_common_params rel ;
struct qed_queue_start_common_params abs ;
u32 cid ;
u16 opaque_fid ;
/* VFs queues are mapped differently, so we need to know the
* relative queue associated with them [ 0 - based ] .
* Notice this is relevant on the * PF * queue - cid of its VF ' s queues ,
* and not on the VF itself .
*/
bool is_vf ;
u8 vf_qid ;
/* Legacy VFs might have Rx producer located elsewhere */
bool b_legacy_vf ;
} ;
2016-05-11 16:36:16 +03:00
qed*: Handle-based L2-queues.
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: Yuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-29 16:47:06 +02:00
void qed_eth_queue_cid_release ( struct qed_hwfn * p_hwfn ,
struct qed_queue_cid * p_cid ) ;
struct qed_queue_cid * _qed_eth_queue_to_cid ( struct qed_hwfn * p_hwfn ,
u16 opaque_fid ,
u32 cid ,
u8 vf_qid ,
struct qed_queue_start_common_params
* p_params ) ;
int
qed_sp_eth_vport_start ( struct qed_hwfn * p_hwfn ,
struct qed_sp_vport_start_params * p_params ) ;
/**
* @ brief - Starts an Rx queue , when queue_cid is already prepared
*
* @ param p_hwfn
* @ param p_cid
* @ param bd_max_bytes
* @ param bd_chain_phys_addr
* @ param cqe_pbl_addr
* @ param cqe_pbl_size
*
* @ return int
*/
int
qed_eth_rxq_start_ramrod ( struct qed_hwfn * p_hwfn ,
struct qed_queue_cid * p_cid ,
u16 bd_max_bytes ,
dma_addr_t bd_chain_phys_addr ,
dma_addr_t cqe_pbl_addr , u16 cqe_pbl_size ) ;
/**
* @ brief - Starts a Tx queue , where queue_cid is already prepared
*
* @ param p_hwfn
* @ param p_cid
* @ param pbl_addr
* @ param pbl_size
* @ param p_pq_params - parameters for choosing the PQ for this Tx queue
*
* @ return int
*/
int
qed_eth_txq_start_ramrod ( struct qed_hwfn * p_hwfn ,
struct qed_queue_cid * p_cid ,
dma_addr_t pbl_addr , u16 pbl_size , u16 pq_id ) ;
2016-05-11 16:36:16 +03:00
u8 qed_mcast_bin_from_mac ( u8 * mac ) ;
# endif /* _QED_L2_H */