aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/ethernet
AgeCommit message (Collapse)AuthorFilesLines
2023-02-06ice: convert vf_ops .vsi_rebuild to .create_vsiJacob Keller3-15/+40
The .vsi_rebuild function exists for ice_reset_vf. It is used to release and re-create the VSI during a single-VF reset. This function is only called when we need to re-create the VSI, and not when rebuilding an existing VSI. This makes the single-VF reset process different from the process used to restore functionality after a hardware reset such as the PF reset or EMP reset. When we add support for Scalable IOV VFs, the implementation will be very similar. The primary difference will be in the fact that each VF type uses a different underlying VSI type in hardware. Move the common functionality into a new ice_vf_recreate VSI function. This will allow the two IOV paths to share this functionality. Rework the .vsi_rebuild vf_op into .create_vsi, only performing the task of creating a new VSI. This creates a nice dichotomy between the ice_vf_rebuild_vsi and ice_vf_recreate_vsi, and should make it more clear why the two flows atre distinct. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Marek Szlosek <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2023-02-06ice: introduce ice_vf_init_host_cfg functionJacob Keller3-34/+57
Introduce a new generic helper ice_vf_init_host_cfg which performs common host configuration initialization tasks that will need to be done for both Single Root IOV and the new Scalable IOV implementation. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Marek Szlosek <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2023-02-06ice: add a function to initialize vf entryJacob Keller3-14/+29
Some of the initialization code for Single Root IOV VFs will need to be reused when we introduce Scalable IOV. Pull this code out into a new ice_initialize_vf_entry helper function. Co-developed-by: Harshitha Ramamurthy <[email protected]> Signed-off-by: Harshitha Ramamurthy <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Tested-by: Marek Szlosek <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2023-02-06ice: Pull common tasks into ice_vf_post_vsi_rebuildJacob Keller2-4/+17
The Single Root IOV implementation of .post_vsi_rebuild performs some tasks that will ultimately need to be shared with the Scalable IOV implementation such as rebuilding the host configuration. Refactor by introducing a new wrapper function, ice_vf_post_vsi_rebuild which performs the tasks that will be shared between SR-IOV and Scalable IOV. Move the ice_vf_rebuild_host_cfg and ice_vf_set_initialized calls into this wrapper. Then call the implementation specific post_vsi_rebuild handler afterwards. This ensures that we will properly re-initialize filters and expected settings for both SR-IOV and Scalable IOV. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Marek Szlosek <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2023-02-06ice: move ice_vf_vsi_release into ice_vf_lib.cJacob Keller3-15/+19
The ice_vf_vsi_release function will be used in a future change to refactor the .vsi_rebuild function. Move this over to ice_vf_lib.c so that it can be used there. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Marek Szlosek <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2023-02-06ice: move vsi_type assignment from ice_vsi_alloc to ice_vsi_cfgJacob Keller1-25/+26
The ice_vsi_alloc and ice_vsi_cfg functions are used together to allocate and configure a new VSI, called as part of the ice_vsi_setup function. In the future with the addition of the subfunction code the ice driver will want to be able to allocate a VSI while delaying the configuration to a later point of the port activation. Currently this requires that the port code know what type of VSI should be allocated. This is required because ice_vsi_alloc assigns the VSI type. Refactor the ice_vsi_alloc and ice_vsi_cfg functions so that VSI type assignment isn't done until the configuration stage. This will allow the devlink port addition logic to reserve a VSI as early as possible before the type of the port is known. In this way, the port add can fail in the event that all hardware VSI resources are exhausted. Since the ice_vsi_cfg function already takes the ice_vsi_cfg_params structure, this is relatively straight forward. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Gurucharan G <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]>
2023-02-06ice: refactor VSI setup to use parameter structureJacob Keller6-63/+147
The ice_vsi_setup function, ice_vsi_alloc, and ice_vsi_cfg functions have grown a large number of parameters. These parameters are used to initialize a new VSI, as well as re-configure an existing VSI Any time we want to add a new parameter to this function chain, even if it will usually be unset, we have to change many call sites due to changing the function signature. A future change is going to refactor ice_vsi_alloc and ice_vsi_cfg to move the VSI configuration and initialization all into ice_vsi_cfg. Before this, refactor the VSI setup flow to use a new ice_vsi_cfg_params structure. This will contain the configuration (mainly pointers) used to initialize a VSI. Pass this from ice_vsi_setup into the related functions such as ice_vsi_alloc, ice_vsi_cfg, and ice_vsi_cfg_def. Introduce a helper, ice_vsi_to_params to convert an existing VSI to the parameters used to initialize it. This will aid in the flows where we rebuild an existing VSI. Since we also pass the ICE_VSI_FLAG_INIT to more functions which do not need (or cannot yet have) the VSI parameters, lets make this clear by renaming the function parameter to vsi_flags and using a u32 instead of a signed integer. The name vsi_flags also makes it clear that we may extend the flags in the future. This change will make it easier to refactor the setup flow in the future, and will reduce the complexity required to add a new parameter for configuration in the future. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Gurucharan G <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]>
2023-02-06ice: drop unnecessary VF parameter from several VSI functionsJacob Keller1-13/+8
The vsi->vf pointer gets assigned early on during ice_vsi_alloc. Several functions currently take a VF pointer, but they can just use the existing vsi->vf pointer as needed. Modify these functions to drop the unnecessary VF parameter. Note that ice_vsi_cfg is not changed as a following change will refactor so that the VF pointer is assigned during ice_vsi_cfg rather than ice_vsi_alloc. Signed-off-by: Jacob Keller <[email protected]> Reviewed-by: Michal Swiatkowski <[email protected]> Tested-by: Marek Szlosek <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2023-02-06ice: fix function comment referring to ice_vsi_allocJacob Keller1-1/+1
Since commit 1d2e32275de7 ("ice: split ice_vsi_setup into smaller functions") ice_vsi_alloc has not been responsible for all of the behavior implied by the comment for ice_vsi_setup_vector_base. Fix the comment to refer to the new function ice_vsi_alloc_def(). Signed-off-by: Jacob Keller <[email protected]> Reviewed-by: Michal Swiatkowski <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2023-02-06ice: Add more usage of existing function ice_get_vf_vsi(vf)Brett Creeley1-4/+4
Extend the usage of function ice_get_vf_vsi(vf) in multiple places instead of VF's VSI by using a long string of dereferences (i.e. vf->pf->vsi[vf->lan_vsi_idx]). Signed-off-by: Brett Creeley <[email protected]> Signed-off-by: Kalyan Kodamagula <[email protected]> Tested-by: Piotr Tyda <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2023-02-06net: enetc: act upon mqprio queue config in taprio offloadVladimir Oltean1-14/+6
We assume that the mqprio queue configuration from taprio has a simple 1:1 mapping between prio and traffic class, and one TX queue per TC. That might not be the case. Actually parse and act upon the mqprio config. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: enetc: act upon the requested mqprio queue configurationVladimir Oltean1-31/+70
Regardless of the requested queue count per traffic class, the enetc driver allocates a number of TX rings equal to the number of TCs, and hardcodes a queue configuration of "1@0 1@1 ... 1@max-tc". Other configurations are silently ignored and treated the same. Improve that by allowing what the user requests to be actually fulfilled. This allows more than one TX ring per traffic class. For example: $ tc qdisc add dev eno0 root handle 1: mqprio num_tc 4 \ map 0 0 1 1 2 2 3 3 queues 2@0 2@2 2@4 2@6 [ 146.267648] fsl_enetc 0000:00:00.0 eno0: TX ring 0 prio 0 [ 146.273451] fsl_enetc 0000:00:00.0 eno0: TX ring 1 prio 0 [ 146.283280] fsl_enetc 0000:00:00.0 eno0: TX ring 2 prio 1 [ 146.293987] fsl_enetc 0000:00:00.0 eno0: TX ring 3 prio 1 [ 146.300467] fsl_enetc 0000:00:00.0 eno0: TX ring 4 prio 2 [ 146.306866] fsl_enetc 0000:00:00.0 eno0: TX ring 5 prio 2 [ 146.313261] fsl_enetc 0000:00:00.0 eno0: TX ring 6 prio 3 [ 146.319622] fsl_enetc 0000:00:00.0 eno0: TX ring 7 prio 3 $ tc qdisc del dev eno0 root [ 178.238418] fsl_enetc 0000:00:00.0 eno0: TX ring 0 prio 0 [ 178.244369] fsl_enetc 0000:00:00.0 eno0: TX ring 1 prio 0 [ 178.251486] fsl_enetc 0000:00:00.0 eno0: TX ring 2 prio 0 [ 178.258006] fsl_enetc 0000:00:00.0 eno0: TX ring 3 prio 0 [ 178.265038] fsl_enetc 0000:00:00.0 eno0: TX ring 4 prio 0 [ 178.271557] fsl_enetc 0000:00:00.0 eno0: TX ring 5 prio 0 [ 178.277910] fsl_enetc 0000:00:00.0 eno0: TX ring 6 prio 0 [ 178.284281] fsl_enetc 0000:00:00.0 eno0: TX ring 7 prio 0 $ tc qdisc add dev eno0 root handle 1: mqprio num_tc 8 \ map 0 1 2 3 4 5 6 7 queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 1 [ 186.113162] fsl_enetc 0000:00:00.0 eno0: TX ring 0 prio 0 [ 186.118764] fsl_enetc 0000:00:00.0 eno0: TX ring 1 prio 1 [ 186.124374] fsl_enetc 0000:00:00.0 eno0: TX ring 2 prio 2 [ 186.130765] fsl_enetc 0000:00:00.0 eno0: TX ring 3 prio 3 [ 186.136404] fsl_enetc 0000:00:00.0 eno0: TX ring 4 prio 4 [ 186.142049] fsl_enetc 0000:00:00.0 eno0: TX ring 5 prio 5 [ 186.147674] fsl_enetc 0000:00:00.0 eno0: TX ring 6 prio 6 [ 186.153305] fsl_enetc 0000:00:00.0 eno0: TX ring 7 prio 7 The driver used to set TC_MQPRIO_HW_OFFLOAD_TCS, near which there is this comment in the UAPI header: TC_MQPRIO_HW_OFFLOAD_TCS, /* offload TCs, no queue counts */ which is what enetc was doing up until now (and no longer is; we offload queue counts too), remove that assignment. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: enetc: request mqprio to validate the queue countsVladimir Oltean2-7/+7
The enetc driver does not validate the mqprio queue configuration, so it currently allows things like this: $ tc qdisc add dev swp0 root handle 1: mqprio num_tc 8 \ map 0 1 2 3 4 5 6 7 queues 3@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 1 But also things like this, completely omitting the queue configuration: $ tc qdisc add dev eno0 root handle 1: mqprio num_tc 8 \ map 0 1 2 3 4 5 6 7 hw 1 By requesting validation via the mqprio capability structure, this is no longer allowed, and we bring what is accepted by hardware in line with what is accepted by software. The check that num_tc <= real_num_tx_queues also becomes superfluous and can be dropped, because mqprio_validate_queue_counts() validates that no TXQ range exceeds real_num_tx_queues. That is a stronger check, because there is at least 1 TXQ per TC, so there are at least as many TXQs as TCs. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net/sched: taprio: only pass gate mask per TXQ for igc, stmmac, tsnep, am65_cpswVladimir Oltean6-0/+93
There are 2 classes of in-tree drivers currently: - those who act upon struct tc_taprio_sched_entry :: gate_mask as if it holds a bit mask of TXQs - those who act upon the gate_mask as if it holds a bit mask of TCs When it comes to the standard, IEEE 802.1Q-2018 does say this in the second paragraph of section 8.6.8.4 Enhancements for scheduled traffic: | A gate control list associated with each Port contains an ordered list | of gate operations. Each gate operation changes the transmission gate | state for the gate associated with each of the Port's traffic class | queues and allows associated control operations to be scheduled. In typically obtuse language, it refers to a "traffic class queue" rather than a "traffic class" or a "queue". But careful reading of 802.1Q clarifies that "traffic class" and "queue" are in fact synonymous (see 8.6.6 Queuing frames): | A queue in this context is not necessarily a single FIFO data structure. | A queue is a record of all frames of a given traffic class awaiting | transmission on a given Bridge Port. The structure of this record is not | specified. i.o.w. their definition of "queue" isn't the Linux TX queue. The gate_mask really is input into taprio via its UAPI as a mask of traffic classes, but taprio_sched_to_offload() converts it into a TXQ mask. The breakdown of drivers which handle TC_SETUP_QDISC_TAPRIO is: - hellcreek, felix, sja1105: these are DSA switches, it's not even very clear what TXQs correspond to, other than purely software constructs. Only the mqprio configuration with 8 TCs and 1 TXQ per TC makes sense. So it's fine to convert these to a gate mask per TC. - enetc: I have the hardware and can confirm that the gate mask is per TC, and affects all TXQs (BD rings) configured for that priority. - igc: in igc_save_qbv_schedule(), the gate_mask is clearly interpreted to be per-TXQ. - tsnep: Gerhard Engleder clarifies that even though this hardware supports at most 1 TXQ per TC, the TXQ indices may be different from the TC values themselves, and it is the TXQ indices that matter to this hardware. So keep it per-TXQ as well. - stmmac: I have a GMAC datasheet, and in the EST section it does specify that the gate events are per TXQ rather than per TC. - lan966x: again, this is a switch, and while not a DSA one, the way in which it implements lan966x_mqprio_add() - by only allowing num_tc == NUM_PRIO_QUEUES (8) - makes it clear to me that TXQs are a purely software construct here as well. They seem to map 1:1 with TCs. - am65_cpsw: from looking at am65_cpsw_est_set_sched_cmds(), I get the impression that the fetch_allow variable is treated like a prio_mask. This definitely sounds closer to a per-TC gate mask rather than a per-TXQ one, and TI documentation does seem to recomment an identity mapping between TCs and TXQs. However, Roger Quadros would like to do some testing before making changes, so I'm leaving this driver to operate as it did before, for now. Link with more details at the end. Based on this breakdown, we have 5 drivers with a gate mask per TC and 4 with a gate mask per TXQ. So let's make the gate mask per TXQ the opt-in and the gate mask per TC the default. Benefit from the TC_QUERY_CAPS feature that Jakub suggested we add, and query the device driver before calling the proper ndo_setup_tc(), and figure out if it expects one or the other format. Link: https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/#25193204 Cc: Horatiu Vultur <[email protected]> Cc: Siddharth Vadapalli <[email protected]> Cc: Roger Quadros <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]> Acked-by: Kurt Kanzenbach <[email protected]> # hellcreek Reviewed-by: Gerhard Engleder <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net/sched: move struct tc_mqprio_qopt_offload from pkt_cls.h to pkt_sched.hVladimir Oltean12-2/+12
Since mqprio is a scheduler and not a classifier, move its offload structure to pkt_sched.h, where struct tc_taprio_qopt_offload also lies. Also update some header inclusions in drivers that access this structure, to the best of my abilities. Cc: Igor Russkikh <[email protected]> Cc: Yisen Zhuang <[email protected]> Cc: Salil Mehta <[email protected]> Cc: Jesse Brandeburg <[email protected]> Cc: Tony Nguyen <[email protected]> Cc: Thomas Petazzoni <[email protected]> Cc: Saeed Mahameed <[email protected]> Cc: Leon Romanovsky <[email protected]> Cc: Horatiu Vultur <[email protected]> Cc: Lars Povlsen <[email protected]> Cc: Steen Hegelund <[email protected]> Cc: Daniel Machon <[email protected]> Cc: [email protected] Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06gve: Fix gve interrupt namesPraveen Kaligineedi1-5/+4
IRQs are currently requested before the netdevice is registered and a proper name is assigned to the device. Changing interrupt name to avoid using the format string in the name. Interrupt name before change: eth%d-ntfy-block.<blk_id> Interrupt name after change: gve-ntfy-blk<blk_id>@pci:<pci_name> Signed-off-by: Praveen Kaligineedi <[email protected]> Reviewed-by: Jeroen de Borst <[email protected]> Acked-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06Merge branch '100GbE' of ↵David S. Miller10-967/+1142
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== net: implement devlink reload in ice Michal Swiatkowski says: This is a part of changes done in patchset [0]. Resource management is kind of controversial part, so I split it into two patchsets. It is the first one, covering refactor and implement reload API call. The refactor will unblock some of the patches needed by SIOV or subfunction. Most of this patchset is about implementing driver reload mechanism. Part of code from probe and rebuild is used to not duplicate code. To allow this reuse probe and rebuild path are split into smaller functions. Patch "ice: split ice_vsi_setup into smaller functions" changes boolean variable in function call to integer and adds define for it. Instead of having the function called with true/false now it can be called with readable defines ICE_VSI_FLAG_INIT or ICE_VSI_FLAG_NO_INIT. It was suggested by Jacob Keller and probably this mechanism will be implemented across ice driver in follow up patchset. Previously the code was reviewed here [0]. [0] https://lore.kernel.org/netdev/Y3ckRWtAtZU1BdXm@unreal/T/#m3bb8feba0a62f9b4cd54cd94917b7e2143fc2ecd ==================== Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: microchip: sparx5: fix PTP init/deinit not checking all portsCasper Andersson1-2/+2
Check all ports instead of just port_count ports. PTP init was only checking ports 0 to port_count. If the hardware ports are not mapped starting from 0 then they would be missed, e.g. if only ports 20-30 were mapped it would attempt to init ports 0-10, resulting in NULL pointers when attempting to timestamp. Now it will init all mapped ports. Fixes: 70dfe25cd866 ("net: sparx5: Update extraction/injection for timestamping") Signed-off-by: Casper Andersson <[email protected]> Reviewed-by: Horatiu Vultur <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: ngbe: Support Rx and Tx process pathMengyuan Lou2-13/+61
Add enable and disable operation process for ngbe open/close. Clean Rx and Tx ring interrupts, process packets in the data path. Signed-off-by: Mengyuan Lou <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: txgbe: Support Rx and Tx process pathJiawen Wu1-9/+28
Clean Rx and Tx ring interrupts, process packets in the data path. Signed-off-by: Jiawen Wu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: libwx: Add tx path to process packetsMengyuan Lou4-0/+465
Support to transmit packets without hardware features. Signed-off-by: Mengyuan Lou <[email protected]> Signed-off-by: Jiawen Wu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: libwx: Support to receive packets in NAPIJiawen Wu4-1/+706
Clean all queues associated with a q_vector, to simple receive packets without hardware features. Signed-off-by: Jiawen Wu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: txgbe: Setup Rx and Tx ringJiawen Wu3-3/+44
Improve the configuration of Rx and Tx ring, set Rx flags and implement ndo_set_rx_mode ops. Signed-off-by: Jiawen Wu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: libwx: Allocate Rx and Tx resourcesJiawen Wu5-0/+388
Setup Rx and Tx descriptors for specefic rings. Signed-off-by: Jiawen Wu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: libwx: Configure Rx and Tx unit on hardwareJiawen Wu3-0/+684
Configure hardware for preparing to process packets. Including configure receive and transmit unit of the MAC layer, and setup the specific rings. Signed-off-by: Jiawen Wu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: txgbe: Add interrupt supportJiawen Wu2-0/+219
Determine proper interrupt scheme to enable and handle interrupt. Signed-off-by: Jiawen Wu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: ngbe: Add irqs request flowMengyuan Lou2-1/+202
Add request_irq for tx/rx rings and misc other events. If the application is successful, config vertors for interrupts. Enable some base interrupts mask in ngbe_irq_enable. Signed-off-by: Mengyuan Lou <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: libwx: Add irq flow functionsMengyuan Lou6-2/+788
Add irq flow functions for ngbe and txgbe. Alloc pcie msix irqs for drivers, otherwise fall back to msi/legacy. Signed-off-by: Mengyuan Lou <[email protected]> Signed-off-by: Jiawen Wu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06Merge tag 'mlx5-updates-2023-02-04' of ↵David S. Miller17-54/+129
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== mlx5-updates-2023-02-04 This series provides misc updates to mlx5 driver: 1) Trivial LAG code cleanup patches from Roi 2) Rahul improves mlx5's documentation structure Separates the documentation into multiple pages related to different components in the device driver. Adds Kconfig parameters, devlink parameters, and tracepoints that were previously introduced but not added to the documentation. Introduces a new page on ethtool statistics counters with information about counters previously implemented in the mlx5_core driver but not documented in the kernel tree. 3) From Raed, policy/state selector support for IPSec. 4) From Fragos, add support for XDR speed in IPoIB mlx5 netdev 5) Few more misc cleanups and trivial changes ==================== Signed-off-by: David S. Miller <[email protected]>
2023-02-06sparx5: add support for configuring PSFP via tcDaniel Machon3-3/+240
Add support for tc actions gate and police, in order to implement support for configuring PSFP through tc. Signed-off-by: Daniel Machon <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: microchip: sparx5: initialize PSFPDaniel Machon3-0/+23
Initialize the SDLB's, stream gates and stream filters. Signed-off-by: Daniel Machon <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: microchip: sparx5: add support for PSFP stream filtersDaniel Machon2-0/+95
Add support for configuring PSFP stream filters (IEEE 802.1Q-2018, 8.6.5.1.1). The VCAP CLM (VCAP IS0 ingress classifier) classifies streams, identified by ISDX (Ingress Service Index, frame metadata), and maps ISDX to streams. Signed-off-by: Daniel Machon <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: microchip: sparx5: add support for PSFP stream gatesDaniel Machon2-0/+179
Add support for configuring PSFP stream gates (IEEE 802.1Q-2018, 8.6.5.1.2). Stream gates are time-based policers used by PSFP. Frames are dropped based on the gate state (OPEN/ CLOSE), whose state will be altered based on the Gate Control List (GCL) and current PTP time. Apart from time-based policing, stream gates can alter egress queue selection for the frames that pass through the Gate. This is done through Internal Priority Selector (IPS). Stream gates are mapped from stream filters. Signed-off-by: Daniel Machon <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: microchip: sparx5: add function for calculating PTP basetimeDaniel Machon3-2/+63
Add a new function for calculating PTP basetime, required by the stream gate scheduler to calculate gate state (open / close). Signed-off-by: Daniel Machon <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: microchip: sparx5: add support for PSFP flow-metersDaniel Machon3-1/+98
Add support for configuring PSFP flow-meters (IEEE 802.1Q-2018, 8.6.5.1.3). The VCAP CLM (VCAP IS0 ingress classifier) classifies streams, identified by ISDX (Ingress Service Index, frame metadata), and maps ISDX to flow-meters. SDLB's provide the flow-meter parameters. Signed-off-by: Daniel Machon <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: microchip: sparx5: add support for service policersDaniel Machon3-1/+70
Add initial API for configuring policers. This patch add support for service policers. Signed-off-by: Daniel Machon <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: microchip: sparx5: add support for Service Dual Leacky BucketsDaniel Machon3-1/+367
Add support for Service Dual Leacky Buckets (SDLB), used to implement PSFP flow-meters. Buckets are linked together in a leak chain of a leak group. Leak groups a preconfigured to serve buckets within a certain rate interval. Signed-off-by: Daniel Machon <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: microchip: sparx5: add resource poolsDaniel Machon3-1/+95
Add resource pools and accessor functions. These pools can be queried by the driver, whenever a finite resource is required. Some resources can be reused, in which case an index and a reference count is used to keep track of users. Signed-off-by: Daniel Machon <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-06net: microchip: add registers needed for PSFPDaniel Machon2-7/+579
Add registers needed for PSFP. This patch also renames a single register, shortening its name (SYS_CLK_PER_100PS). Uses have been update accordingly. Signed-off-by: Daniel Machon <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-02-04net/mlx5e: Trigger NAPI after activating an SQMaxim Mikityanskiy4-7/+15
If an SQ is deactivated and reactivated again, some packets could be sent after MLX5E_SQ_STATE_ENABLED is cleared, but before netif_tx_stop_queue, meaning that NAPI might miss some completions. In order to handle them, make sure to trigger NAPI after SQ activation in all cases where it can be relevant. Regular SQs, XDP SQs and XSK SQs are good. Missing cases added: after recovery, after activating HTB SQs and after activating PTP SQs. Signed-off-by: Maxim Mikityanskiy <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2023-02-04net/mlx5e: IPsec, support upper protocol selector field offloadRaed Salem3-0/+56
Add support to policy/state upper protocol selector field offload, this will enable to select traffic for IPsec operation based on l4 protocol (TCP/UDP) with specific source/destination port. Signed-off-by: Raed Salem <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2023-02-04net/mlx5e: IPoIB, Add support for XDR speedDragos Tatulea1-0/+2
Add XDR IB PTYS coding and XDR speed 200Gbps. Signed-off-by: Dragos Tatulea <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Reviewed-by: Gal Pressman <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2023-02-04net/mlx5: Enhance debug print in page allocation failureJack Morgenstein1-1/+2
Provide more details to aid debugging. Fixes: bf0bf77f6519 ("mlx5: Support communicating arbitrary host page size to firmware") Signed-off-by: Eran Ben Elisha <[email protected]> Signed-off-by: Majd Dibbiny <[email protected]> Signed-off-by: Jack Morgenstein <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2023-02-04net/mlx5: Add firmware support for MTUTC scaled_ppm frequency adjustmentsRahul Rameshbabu1-3/+12
When device is capable of handling scaled ppm values for adjusting frequency, conversion to ppb will not be done by the driver. Instead, the scaled ppm value will be passed directly to the device for the frequency adjustment operation. Signed-off-by: Rahul Rameshbabu <[email protected]> Reviewed-by: Gal Pressman <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2023-02-04net/mlx5: Lag, Move mpesw related definitions to mpesw.hRoi Dayan2-15/+15
mpesw definitions should be in mpesw.h and not lag.h. Signed-off-by: Roi Dayan <[email protected]> Reviewed-by: Maor Dickman <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2023-02-04net/mlx5: Lag, Use flag to check for shared FDB modeMark Bloch1-2/+1
It's redundant and incorrect to check lag is also sriov mode. Signed-off-by: Mark Bloch <[email protected]> Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2023-02-04net/mlx5: Lag, Remove redundant bool allocation on the stackRoi Dayan2-9/+3
There is no need to allocate the bool variable and can just return the value. Signed-off-by: Roi Dayan <[email protected]> Reviewed-by: Maor Dickman <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2023-02-04net/mlx5: Lag, Use mlx5_lag_dev() instead of derefering pointersRoi Dayan3-10/+11
Use the existing wrapper mlx5_lag_dev() to access the lag object from dev for better maintainability and consistent code. Signed-off-by: Roi Dayan <[email protected]> Reviewed-by: Maor Dickman <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2023-02-04net/mlx5: Lag, Update multiport eswitch check to log an errorRoi Dayan3-8/+13
Update the function to log an error to the user if failing to offload the rule and while there add correct prefix for the function name. Signed-off-by: Roi Dayan <[email protected]> Reviewed-by: Maor Dickman <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2023-02-03net: enetc: ensure we always have a minimum number of TXQs for stackVladimir Oltean2-0/+17
Currently it can happen that an mqprio qdisc is installed with num_tc 8, and this will reserve 8 (out of 8) TXQs for the network stack. Then we can attach an XDP program, and this will crop 2 TXQs, leaving just 6 for mqprio. That's not what the user requested, and we should fail it. On the other hand, if mqprio isn't requested, we still give the 8 TXQs to the network stack (with hashing among a single traffic class), but then, cropping 2 TXQs for XDP is fine, because the user didn't explicitly ask for any number of TXQs, so no expectations are violated. Simply put, the logic that mqprio should impose a minimum number of TXQs for the network never existed. Let's say (more or less arbitrarily) that without mqprio, the driver expects a minimum number of TXQs equal to the number of CPUs (on NXP LS1028A, that is either 1, or 2). And with mqprio, mqprio gives the minimum required number of TXQs. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.