aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/intel/ice/ice_sched.c
AgeCommit message (Collapse)AuthorFilesLines
2018-10-02ice: Expand use of VSI handles part 2/2Anirudh Venkataramanan1-103/+48
This patch is a continuation of the previous patch where VSI handles are used instead of VSI numbers. Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-09-27ice: Query the Tx scheduler node before adding itAnirudh Venkataramanan1-1/+66
Query the Tx scheduler tree node information from FW before adding it to the driver's software database. This will keep the node information current in driver. Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-08-28ice: Updates to Tx scheduler codeAnirudh Venkataramanan1-111/+50
1) The maximum device nodes is a global value and shared by the whole device. Add element AQ command would fail if there is no space to add new nodes so the check for max nodes isn't required. So remove ice_sched_get_num_nodes_per_layer and ice_sched_val_max_nodes. 2) In ice_sched_add_elems, set default node's CIR/EIR bandwidth weight. 3) Fix default scheduler topology buffer size as the firmware expects a 4KB buffer at all times, and will error out if one of any other size is provided. 4) In the latest spec, max children per node per layer is replaced by max sibling group size. Now it provides the max children of the below layer node, not the current layer node. 5) Fix some newline/whitespace issues for consistency. Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-08-23ice: Remove unnecessary node owner checkBruce Allan1-2/+1
There is already a check for owner == ICE_SCHED_NODE_OWNER_LAN at the beginning of ice_sched_update_vsi_child_nodes. Remove the additional check to address the static analysis tool smatch issue "warn: we tested 'owner' before and it was 'false'". Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-04-24ice: Fix initialization for num_nodes_addedAnirudh Venkataramanan1-2/+2
ice_sched_add_nodes_to_layer is used recursively, and so we start with num_nodes_added being 0. This way, in case of an error or if num_nodes is NULL, the function just returns 0 to indicate that no nodes were added. Fixes: 5513b920a4f7 ("ice: Update Tx scheduler tree for VSI multi-Tx queue support") Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-26ice: Update Tx scheduler tree for VSI multi-Tx queue supportAnirudh Venkataramanan1-0/+886
This patch adds the ability for a VSI to use multiple Tx queues. More specifically, the patch 1) Provides the ability to update the Tx scheduler tree in the firmware. The driver can configure the Tx scheduler tree by adding/removing multiple Tx queues per TC per VSI. 2) Allows a VSI to reconfigure its Tx queues during runtime. 3) Synchronizes the Tx scheduler update operations using locks. Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-26ice: Configure VSIs for Tx/RxAnirudh Venkataramanan1-0/+105
This patch configures the VSIs to be able to send and receive packets by doing the following: 1) Initialize flexible parser to extract and include certain fields in the Rx descriptor. 2) Add Tx queues by programming the Tx queue context (implemented in ice_vsi_cfg_txqs). Note that adding the queues also enables (starts) the queues. 3) Add Rx queues by programming Rx queue context (implemented in ice_vsi_cfg_rxqs). Note that this only adds queues but doesn't start them. The rings will be started by calling ice_vsi_start_rx_rings on interface up. 4) Configure interrupts for VSI queues. 5) Implement ice_open and ice_stop. Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-26ice: Get MAC/PHY/link info and scheduler topologyAnirudh Venkataramanan1-0/+328
This patch adds code to continue the initialization flow as follows: 1) Get PHY/link information and store it 2) Get default scheduler tree topology and store it 3) Get the MAC address associated with the port and store it Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-26ice: Get switch config, scheduler config and device capabilitiesAnirudh Venkataramanan1-0/+340
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>