ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
|
|
|
/* Copyright (c) 2018, Intel Corporation. */
|
|
|
|
|
|
|
|
#ifndef _ICE_SCHED_H_
|
|
|
|
#define _ICE_SCHED_H_
|
|
|
|
|
|
|
|
#include "ice_common.h"
|
|
|
|
|
2018-03-20 22:58:13 +08:00
|
|
|
#define ICE_QGRP_LAYER_OFFSET 2
|
2018-03-20 22:58:17 +08:00
|
|
|
#define ICE_VSI_LAYER_OFFSET 4
|
2019-11-06 18:05:28 +08:00
|
|
|
#define ICE_SCHED_INVAL_LAYER_NUM 0xFF
|
|
|
|
/* Burst size is a 12 bits register that is configured while creating the RL
|
|
|
|
* profile(s). MSB is a granularity bit and tells the granularity type
|
|
|
|
* 0 - LSB bits are in 64 bytes granularity
|
|
|
|
* 1 - LSB bits are in 1K bytes granularity
|
|
|
|
*/
|
|
|
|
#define ICE_64_BYTE_GRANULARITY 0
|
|
|
|
#define ICE_KBYTE_GRANULARITY BIT(11)
|
|
|
|
#define ICE_MIN_BURST_SIZE_ALLOWED 64 /* In Bytes */
|
|
|
|
#define ICE_MAX_BURST_SIZE_ALLOWED \
|
|
|
|
((BIT(11) - 1) * 1024) /* In Bytes */
|
|
|
|
#define ICE_MAX_BURST_SIZE_64_BYTE_GRANULARITY \
|
|
|
|
((BIT(11) - 1) * 64) /* In Bytes */
|
|
|
|
#define ICE_MAX_BURST_SIZE_KBYTE_GRANULARITY ICE_MAX_BURST_SIZE_ALLOWED
|
|
|
|
|
|
|
|
#define ICE_RL_PROF_FREQUENCY 446000000
|
|
|
|
#define ICE_RL_PROF_ACCURACY_BYTES 128
|
|
|
|
#define ICE_RL_PROF_MULTIPLIER 10000
|
|
|
|
#define ICE_RL_PROF_TS_MULTIPLIER 32
|
|
|
|
#define ICE_RL_PROF_FRACTION 512
|
|
|
|
|
|
|
|
/* BW rate limit profile parameters list entry along
|
|
|
|
* with bandwidth maintained per layer in port info
|
|
|
|
*/
|
|
|
|
struct ice_aqc_rl_profile_info {
|
|
|
|
struct ice_aqc_rl_profile_elem profile;
|
|
|
|
struct list_head list_entry;
|
|
|
|
u32 bw; /* requested */
|
|
|
|
u16 prof_id_ref; /* profile ID to node association ref count */
|
|
|
|
};
|
2018-03-20 22:58:13 +08:00
|
|
|
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
struct ice_sched_agg_vsi_info {
|
|
|
|
struct list_head list_entry;
|
|
|
|
DECLARE_BITMAP(tc_bitmap, ICE_MAX_TRAFFIC_CLASS);
|
2018-10-27 01:41:02 +08:00
|
|
|
u16 vsi_handle;
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
struct ice_sched_agg_info {
|
|
|
|
struct list_head agg_vsi_list;
|
|
|
|
struct list_head list_entry;
|
|
|
|
DECLARE_BITMAP(tc_bitmap, ICE_MAX_TRAFFIC_CLASS);
|
|
|
|
u32 agg_id;
|
|
|
|
enum ice_agg_type agg_type;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* FW AQ command calls */
|
2019-03-01 07:24:24 +08:00
|
|
|
enum ice_status
|
|
|
|
ice_aq_query_sched_elems(struct ice_hw *hw, u16 elems_req,
|
2020-06-30 08:27:45 +08:00
|
|
|
struct ice_aqc_txsched_elem_data *buf, u16 buf_size,
|
2019-03-01 07:24:24 +08:00
|
|
|
u16 *elems_ret, struct ice_sq_cd *cd);
|
2018-03-20 22:58:09 +08:00
|
|
|
enum ice_status ice_sched_init_port(struct ice_port_info *pi);
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
enum ice_status ice_sched_query_res_alloc(struct ice_hw *hw);
|
2018-10-27 02:44:35 +08:00
|
|
|
void ice_sched_clear_port(struct ice_port_info *pi);
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
void ice_sched_cleanup_all(struct ice_hw *hw);
|
2018-12-20 02:03:28 +08:00
|
|
|
void ice_sched_clear_agg(struct ice_hw *hw);
|
|
|
|
|
2018-03-20 22:58:09 +08:00
|
|
|
struct ice_sched_node *
|
|
|
|
ice_sched_find_node_by_teid(struct ice_sched_node *start_node, u32 teid);
|
|
|
|
enum ice_status
|
|
|
|
ice_sched_add_node(struct ice_port_info *pi, u8 layer,
|
|
|
|
struct ice_aqc_txsched_elem_data *info);
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
void ice_free_sched_node(struct ice_port_info *pi, struct ice_sched_node *node);
|
|
|
|
struct ice_sched_node *ice_sched_get_tc_node(struct ice_port_info *pi, u8 tc);
|
2018-03-20 22:58:13 +08:00
|
|
|
struct ice_sched_node *
|
2018-09-20 08:23:13 +08:00
|
|
|
ice_sched_get_free_qparent(struct ice_port_info *pi, u16 vsi_handle, u8 tc,
|
2018-03-20 22:58:13 +08:00
|
|
|
u8 owner);
|
2018-03-20 22:58:17 +08:00
|
|
|
enum ice_status
|
2018-09-20 08:23:13 +08:00
|
|
|
ice_sched_cfg_vsi(struct ice_port_info *pi, u16 vsi_handle, u8 tc, u16 maxqs,
|
2018-03-20 22:58:17 +08:00
|
|
|
u8 owner, bool enable);
|
2018-10-27 01:41:02 +08:00
|
|
|
enum ice_status ice_rm_vsi_lan_cfg(struct ice_port_info *pi, u16 vsi_handle);
|
2019-11-06 18:05:28 +08:00
|
|
|
enum ice_status
|
|
|
|
ice_cfg_q_bw_lmt(struct ice_port_info *pi, u16 vsi_handle, u8 tc,
|
|
|
|
u16 q_handle, enum ice_rl_type rl_type, u32 bw);
|
|
|
|
enum ice_status
|
|
|
|
ice_cfg_q_bw_dflt_lmt(struct ice_port_info *pi, u16 vsi_handle, u8 tc,
|
|
|
|
u16 q_handle, enum ice_rl_type rl_type);
|
|
|
|
enum ice_status ice_cfg_rl_burst_size(struct ice_hw *hw, u32 bytes);
|
|
|
|
enum ice_status
|
|
|
|
ice_sched_replay_q_bw(struct ice_port_info *pi, struct ice_q_ctx *q_ctx);
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
#endif /* _ICE_SCHED_H_ */
|