2015-10-26 17:02:26 +08:00
|
|
|
/* QLogic qed NIC Driver
|
2017-01-01 19:57:00 +08:00
|
|
|
* Copyright (c) 2015-2017 QLogic Corporation
|
2015-10-26 17:02:26 +08:00
|
|
|
*
|
2017-01-01 19:57:00 +08:00
|
|
|
* This software is available to you under a choice of one of two
|
|
|
|
|
* licenses. You may choose to be licensed 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, or the
|
|
|
|
|
* OpenIB.org BSD license below:
|
|
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or
|
|
|
|
|
* without modification, are permitted provided that the following
|
|
|
|
|
* conditions are met:
|
|
|
|
|
*
|
|
|
|
|
* - Redistributions of source code must retain the above
|
|
|
|
|
* copyright notice, this list of conditions and the following
|
|
|
|
|
* disclaimer.
|
|
|
|
|
*
|
|
|
|
|
* - Redistributions in binary form must reproduce the above
|
|
|
|
|
* copyright notice, this list of conditions and the following
|
|
|
|
|
* disclaimer in the documentation and /or other materials
|
|
|
|
|
* provided with the distribution.
|
|
|
|
|
*
|
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
|
|
|
|
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
|
|
|
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
|
|
|
|
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
|
|
|
|
|
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
|
|
|
|
|
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
|
|
|
|
|
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
|
|
|
* SOFTWARE.
|
2015-10-26 17:02:26 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _QED_ETH_IF_H
|
|
|
|
|
#define _QED_ETH_IF_H
|
|
|
|
|
|
|
|
|
|
#include <linux/list.h>
|
|
|
|
|
#include <linux/if_link.h>
|
|
|
|
|
#include <linux/qed/eth_common.h>
|
|
|
|
|
#include <linux/qed/qed_if.h>
|
2016-05-11 21:36:15 +08:00
|
|
|
#include <linux/qed/qed_iov_if.h>
|
2015-10-26 17:02:26 +08: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 22:47:06 +08:00
|
|
|
struct qed_queue_start_common_params {
|
|
|
|
|
/* Should always be relative to entity sending this. */
|
|
|
|
|
u8 vport_id;
|
|
|
|
|
u16 queue_id;
|
|
|
|
|
|
|
|
|
|
/* Relative, but relevant only for PFs */
|
|
|
|
|
u8 stats_id;
|
|
|
|
|
|
|
|
|
|
/* These are always absolute */
|
|
|
|
|
u16 sb;
|
|
|
|
|
u8 sb_idx;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct qed_rxq_start_ret_params {
|
|
|
|
|
void __iomem *p_prod;
|
|
|
|
|
void *p_handle;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct qed_txq_start_ret_params {
|
|
|
|
|
void __iomem *p_doorbell;
|
|
|
|
|
void *p_handle;
|
|
|
|
|
};
|
|
|
|
|
|
2015-10-26 17:02:26 +08:00
|
|
|
struct qed_dev_eth_info {
|
|
|
|
|
struct qed_dev_info common;
|
|
|
|
|
|
|
|
|
|
u8 num_queues;
|
|
|
|
|
u8 num_tc;
|
|
|
|
|
|
|
|
|
|
u8 port_mac[ETH_ALEN];
|
2016-10-31 13:14:27 +08:00
|
|
|
u16 num_vlan_filters;
|
2016-10-14 17:19:20 +08:00
|
|
|
u16 num_mac_filters;
|
2016-08-22 18:25:11 +08:00
|
|
|
|
|
|
|
|
/* Legacy VF - this affects the datapath, so qede has to know */
|
|
|
|
|
bool is_legacy;
|
2015-10-26 17:02:26 +08:00
|
|
|
};
|
|
|
|
|
|
2015-10-26 17:02:28 +08:00
|
|
|
struct qed_update_vport_rss_params {
|
2017-01-01 19:57:07 +08:00
|
|
|
void *rss_ind_table[128];
|
2015-10-26 17:02:28 +08:00
|
|
|
u32 rss_key[10];
|
2016-04-10 17:43:00 +08:00
|
|
|
u8 rss_caps;
|
2015-10-26 17:02:28 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct qed_update_vport_params {
|
|
|
|
|
u8 vport_id;
|
|
|
|
|
u8 update_vport_active_flg;
|
|
|
|
|
u8 vport_active_flg;
|
2016-05-11 21:36:25 +08:00
|
|
|
u8 update_tx_switching_flg;
|
|
|
|
|
u8 tx_switching_flg;
|
2016-02-18 23:00:39 +08:00
|
|
|
u8 update_accept_any_vlan_flg;
|
|
|
|
|
u8 accept_any_vlan;
|
2015-10-26 17:02:28 +08:00
|
|
|
u8 update_rss_flg;
|
|
|
|
|
struct qed_update_vport_rss_params rss_params;
|
|
|
|
|
};
|
|
|
|
|
|
2016-03-05 01:35:05 +08:00
|
|
|
struct qed_start_vport_params {
|
|
|
|
|
bool remove_inner_vlan;
|
|
|
|
|
bool gro_enable;
|
|
|
|
|
bool drop_ttl0;
|
|
|
|
|
u8 vport_id;
|
|
|
|
|
u16 mtu;
|
2016-06-19 20:18:13 +08:00
|
|
|
bool clear_stats;
|
2016-03-05 01:35:05 +08:00
|
|
|
};
|
|
|
|
|
|
2015-10-26 17:02:28 +08:00
|
|
|
enum qed_filter_rx_mode_type {
|
|
|
|
|
QED_FILTER_RX_MODE_TYPE_REGULAR,
|
|
|
|
|
QED_FILTER_RX_MODE_TYPE_MULTI_PROMISC,
|
|
|
|
|
QED_FILTER_RX_MODE_TYPE_PROMISC,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum qed_filter_xcast_params_type {
|
|
|
|
|
QED_FILTER_XCAST_TYPE_ADD,
|
|
|
|
|
QED_FILTER_XCAST_TYPE_DEL,
|
|
|
|
|
QED_FILTER_XCAST_TYPE_REPLACE,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct qed_filter_ucast_params {
|
|
|
|
|
enum qed_filter_xcast_params_type type;
|
|
|
|
|
u8 vlan_valid;
|
|
|
|
|
u16 vlan;
|
|
|
|
|
u8 mac_valid;
|
|
|
|
|
unsigned char mac[ETH_ALEN];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct qed_filter_mcast_params {
|
|
|
|
|
enum qed_filter_xcast_params_type type;
|
|
|
|
|
u8 num;
|
|
|
|
|
unsigned char mac[64][ETH_ALEN];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
union qed_filter_type_params {
|
|
|
|
|
enum qed_filter_rx_mode_type accept_flags;
|
|
|
|
|
struct qed_filter_ucast_params ucast;
|
|
|
|
|
struct qed_filter_mcast_params mcast;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum qed_filter_type {
|
|
|
|
|
QED_FILTER_TYPE_UCAST,
|
|
|
|
|
QED_FILTER_TYPE_MCAST,
|
|
|
|
|
QED_FILTER_TYPE_RX_MODE,
|
|
|
|
|
QED_MAX_FILTER_TYPES,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct qed_filter_params {
|
|
|
|
|
enum qed_filter_type type;
|
|
|
|
|
union qed_filter_type_params filter;
|
|
|
|
|
};
|
|
|
|
|
|
2016-04-14 13:38:29 +08:00
|
|
|
struct qed_tunn_params {
|
|
|
|
|
u16 vxlan_port;
|
|
|
|
|
u8 update_vxlan_port;
|
|
|
|
|
u16 geneve_port;
|
|
|
|
|
u8 update_geneve_port;
|
|
|
|
|
};
|
|
|
|
|
|
2015-10-26 17:02:28 +08:00
|
|
|
struct qed_eth_cb_ops {
|
|
|
|
|
struct qed_common_cb_ops common;
|
2016-10-14 17:19:17 +08:00
|
|
|
void (*force_mac) (void *dev, u8 *mac, bool forced);
|
2015-10-26 17:02:28 +08:00
|
|
|
};
|
|
|
|
|
|
2016-06-08 18:22:11 +08:00
|
|
|
#ifdef CONFIG_DCB
|
|
|
|
|
/* Prototype declaration of qed_eth_dcbnl_ops should match with the declaration
|
|
|
|
|
* of dcbnl_rtnl_ops structure.
|
|
|
|
|
*/
|
|
|
|
|
struct qed_eth_dcbnl_ops {
|
|
|
|
|
/* IEEE 802.1Qaz std */
|
|
|
|
|
int (*ieee_getpfc)(struct qed_dev *cdev, struct ieee_pfc *pfc);
|
|
|
|
|
int (*ieee_setpfc)(struct qed_dev *cdev, struct ieee_pfc *pfc);
|
|
|
|
|
int (*ieee_getets)(struct qed_dev *cdev, struct ieee_ets *ets);
|
|
|
|
|
int (*ieee_setets)(struct qed_dev *cdev, struct ieee_ets *ets);
|
|
|
|
|
int (*ieee_peer_getets)(struct qed_dev *cdev, struct ieee_ets *ets);
|
|
|
|
|
int (*ieee_peer_getpfc)(struct qed_dev *cdev, struct ieee_pfc *pfc);
|
|
|
|
|
int (*ieee_getapp)(struct qed_dev *cdev, struct dcb_app *app);
|
|
|
|
|
int (*ieee_setapp)(struct qed_dev *cdev, struct dcb_app *app);
|
|
|
|
|
|
|
|
|
|
/* CEE std */
|
|
|
|
|
u8 (*getstate)(struct qed_dev *cdev);
|
|
|
|
|
u8 (*setstate)(struct qed_dev *cdev, u8 state);
|
|
|
|
|
void (*getpgtccfgtx)(struct qed_dev *cdev, int prio, u8 *prio_type,
|
|
|
|
|
u8 *pgid, u8 *bw_pct, u8 *up_map);
|
|
|
|
|
void (*getpgbwgcfgtx)(struct qed_dev *cdev, int pgid, u8 *bw_pct);
|
|
|
|
|
void (*getpgtccfgrx)(struct qed_dev *cdev, int prio, u8 *prio_type,
|
|
|
|
|
u8 *pgid, u8 *bw_pct, u8 *up_map);
|
|
|
|
|
void (*getpgbwgcfgrx)(struct qed_dev *cdev, int pgid, u8 *bw_pct);
|
|
|
|
|
void (*getpfccfg)(struct qed_dev *cdev, int prio, u8 *setting);
|
|
|
|
|
void (*setpfccfg)(struct qed_dev *cdev, int prio, u8 setting);
|
|
|
|
|
u8 (*getcap)(struct qed_dev *cdev, int capid, u8 *cap);
|
|
|
|
|
int (*getnumtcs)(struct qed_dev *cdev, int tcid, u8 *num);
|
|
|
|
|
u8 (*getpfcstate)(struct qed_dev *cdev);
|
|
|
|
|
int (*getapp)(struct qed_dev *cdev, u8 idtype, u16 id);
|
|
|
|
|
u8 (*getfeatcfg)(struct qed_dev *cdev, int featid, u8 *flags);
|
|
|
|
|
|
|
|
|
|
/* DCBX configuration */
|
|
|
|
|
u8 (*getdcbx)(struct qed_dev *cdev);
|
|
|
|
|
void (*setpgtccfgtx)(struct qed_dev *cdev, int prio,
|
|
|
|
|
u8 pri_type, u8 pgid, u8 bw_pct, u8 up_map);
|
|
|
|
|
void (*setpgtccfgrx)(struct qed_dev *cdev, int prio,
|
|
|
|
|
u8 pri_type, u8 pgid, u8 bw_pct, u8 up_map);
|
|
|
|
|
void (*setpgbwgcfgtx)(struct qed_dev *cdev, int pgid, u8 bw_pct);
|
|
|
|
|
void (*setpgbwgcfgrx)(struct qed_dev *cdev, int pgid, u8 bw_pct);
|
|
|
|
|
u8 (*setall)(struct qed_dev *cdev);
|
|
|
|
|
int (*setnumtcs)(struct qed_dev *cdev, int tcid, u8 num);
|
|
|
|
|
void (*setpfcstate)(struct qed_dev *cdev, u8 state);
|
|
|
|
|
int (*setapp)(struct qed_dev *cdev, u8 idtype, u16 idval, u8 up);
|
|
|
|
|
u8 (*setdcbx)(struct qed_dev *cdev, u8 state);
|
|
|
|
|
u8 (*setfeatcfg)(struct qed_dev *cdev, int featid, u8 flags);
|
|
|
|
|
|
|
|
|
|
/* Peer apps */
|
|
|
|
|
int (*peer_getappinfo)(struct qed_dev *cdev,
|
|
|
|
|
struct dcb_peer_app_info *info,
|
|
|
|
|
u16 *app_count);
|
|
|
|
|
int (*peer_getapptable)(struct qed_dev *cdev, struct dcb_app *table);
|
|
|
|
|
|
|
|
|
|
/* CEE peer */
|
|
|
|
|
int (*cee_peer_getpfc)(struct qed_dev *cdev, struct cee_pfc *pfc);
|
|
|
|
|
int (*cee_peer_getpg)(struct qed_dev *cdev, struct cee_pg *pg);
|
|
|
|
|
};
|
|
|
|
|
#endif
|
|
|
|
|
|
2015-10-26 17:02:26 +08:00
|
|
|
struct qed_eth_ops {
|
|
|
|
|
const struct qed_common_ops *common;
|
2016-05-11 21:36:15 +08:00
|
|
|
#ifdef CONFIG_QED_SRIOV
|
|
|
|
|
const struct qed_iov_hv_ops *iov;
|
|
|
|
|
#endif
|
2016-06-08 18:22:11 +08:00
|
|
|
#ifdef CONFIG_DCB
|
|
|
|
|
const struct qed_eth_dcbnl_ops *dcb;
|
|
|
|
|
#endif
|
2015-10-26 17:02:26 +08:00
|
|
|
|
|
|
|
|
int (*fill_dev_info)(struct qed_dev *cdev,
|
|
|
|
|
struct qed_dev_eth_info *info);
|
|
|
|
|
|
2015-10-26 17:02:31 +08:00
|
|
|
void (*register_ops)(struct qed_dev *cdev,
|
|
|
|
|
struct qed_eth_cb_ops *ops,
|
|
|
|
|
void *cookie);
|
|
|
|
|
|
2016-05-11 21:36:21 +08:00
|
|
|
bool(*check_mac) (struct qed_dev *cdev, u8 *mac);
|
|
|
|
|
|
2015-10-26 17:02:28 +08:00
|
|
|
int (*vport_start)(struct qed_dev *cdev,
|
2016-03-05 01:35:05 +08:00
|
|
|
struct qed_start_vport_params *params);
|
2015-10-26 17:02:28 +08:00
|
|
|
|
|
|
|
|
int (*vport_stop)(struct qed_dev *cdev,
|
|
|
|
|
u8 vport_id);
|
|
|
|
|
|
|
|
|
|
int (*vport_update)(struct qed_dev *cdev,
|
|
|
|
|
struct qed_update_vport_params *params);
|
|
|
|
|
|
|
|
|
|
int (*q_rx_start)(struct qed_dev *cdev,
|
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 22:47:06 +08:00
|
|
|
u8 rss_num,
|
2015-10-26 17:02:28 +08:00
|
|
|
struct qed_queue_start_common_params *params,
|
|
|
|
|
u16 bd_max_bytes,
|
|
|
|
|
dma_addr_t bd_chain_phys_addr,
|
|
|
|
|
dma_addr_t cqe_pbl_addr,
|
|
|
|
|
u16 cqe_pbl_size,
|
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 22:47:06 +08:00
|
|
|
struct qed_rxq_start_ret_params *ret_params);
|
2015-10-26 17:02:28 +08: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 22:47:06 +08:00
|
|
|
int (*q_rx_stop)(struct qed_dev *cdev, u8 rss_id, void *handle);
|
2015-10-26 17:02:28 +08:00
|
|
|
|
|
|
|
|
int (*q_tx_start)(struct qed_dev *cdev,
|
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 22:47:06 +08:00
|
|
|
u8 rss_num,
|
2015-10-26 17:02:28 +08:00
|
|
|
struct qed_queue_start_common_params *params,
|
|
|
|
|
dma_addr_t pbl_addr,
|
|
|
|
|
u16 pbl_size,
|
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 22:47:06 +08:00
|
|
|
struct qed_txq_start_ret_params *ret_params);
|
2015-10-26 17:02:28 +08: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 22:47:06 +08:00
|
|
|
int (*q_tx_stop)(struct qed_dev *cdev, u8 rss_id, void *handle);
|
2015-10-26 17:02:28 +08:00
|
|
|
|
|
|
|
|
int (*filter_config)(struct qed_dev *cdev,
|
|
|
|
|
struct qed_filter_params *params);
|
|
|
|
|
|
|
|
|
|
int (*fastpath_stop)(struct qed_dev *cdev);
|
|
|
|
|
|
|
|
|
|
int (*eth_cqe_completion)(struct qed_dev *cdev,
|
|
|
|
|
u8 rss_id,
|
|
|
|
|
struct eth_slow_path_rx_cqe *cqe);
|
2015-10-26 17:02:33 +08:00
|
|
|
|
|
|
|
|
void (*get_vport_stats)(struct qed_dev *cdev,
|
|
|
|
|
struct qed_eth_stats *stats);
|
2016-04-14 13:38:29 +08:00
|
|
|
|
|
|
|
|
int (*tunn_config)(struct qed_dev *cdev,
|
|
|
|
|
struct qed_tunn_params *params);
|
2015-10-26 17:02:26 +08:00
|
|
|
};
|
|
|
|
|
|
2016-04-10 17:42:59 +08:00
|
|
|
const struct qed_eth_ops *qed_get_eth_ops(void);
|
2015-10-26 17:02:26 +08:00
|
|
|
void qed_put_eth_ops(void);
|
|
|
|
|
|
|
|
|
|
#endif
|