- 31 Mar, 2020 3 commits
-
-
Ido Schimmel authored
Register three dummy packet trap policers with devlink and implement callbacks to change their parameters and read their counters. This will be used later on in the series to test the devlink-trap policer infrastructure. v2: * Remove check about burst size being a power of 2 and instead add a debugfs knob to fail the operation * Provide max/min rate/burst size when registering policers and remove the validity checks from nsim_dev_devlink_trap_policer_set() Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Reviewed-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Extend devlink-trap documentation with information about packet trap policers. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Devices capable of offloading the kernel's datapath and perform functions such as bridging and routing must also be able to send (trap) specific packets to the kernel (i.e., the CPU) for processing. For example, a device acting as a multicast-aware bridge must be able to trap IGMP membership reports to the kernel for processing by the bridge module. In most cases, the underlying device is capable of handling packet rates that are several orders of magnitude higher compared to those that can be handled by the CPU. Therefore, in order to prevent the underlying device from overwhelming the CPU, devices usually include packet trap policers that are able to police the trapped packets to rates that can be handled by the CPU. This patch allows capable device drivers to register their supported packet trap policers with devlink. User space can then tune the parameters of these policer (currently, rate and burst size) and read from the device the number of packets that were dropped by the policer, if supported. Subsequent patches in the series will allow device drivers to create default binding between these policers and packet trap groups and allow user space to change the binding. v2: * Add 'strict_start_type' in devlink policy * Have device drivers provide max/min rate/burst size for each policer. Use them to check validity of user provided parameters Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Reviewed-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 30 Mar, 2020 37 commits
-
-
David S. Miller authored
Russell King says: ==================== split phylink PCS operations This series splits the phylink_mac_ops structure so that PCS can be supported separately with their own PCS operations, separating them from the MAC layer. This may need adaption later as more users come along. v2: change pcs_config() and associated called function prototypes to only pass the information that is required, and add some documention. v3: change phylink_create() prototype ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Russell King authored
Add a separate set of PCS operations, which MAC drivers can use to couple phylink with their associated MAC PCS layer. The PCS operations include: - pcs_get_state() - reads the link up/down, resolved speed, duplex and pause from the PCS. - pcs_config() - configures the PCS for the specified mode, PHY interface type, and setting the advertisement. - pcs_an_restart() - restarts 802.3 in-band negotiation with the link partner - pcs_link_up() - informs the PCS that link has come up, and the parameters of the link. Link parameters are used to program the PCS for fixed speed and non-inband modes. Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Russell King authored
Rename the bland 'ops' member of struct phylink to be a more descriptive 'mac_ops' - this is necessary as we're about to introduce another set of operations. Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Russell King authored
Change phylink_mii_c22_pcs_set_advertisement() to take only the PHY interface and advertisement mask, rather than the full phylink state. Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Factor out mapping the tx skb to a new function rtl8169_tx_map(). This allows to remove redundancies, and rtl8169_get_txd_opts1() has only one user left, so it can be inlined. As a result rtl8169_xmit_frags() is significantly simplified, and in rtl8169_start_xmit() the code is simplified and better readable. No functional change intended. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2020-03-29 Here are a few more Bluetooth patches for the 5.7 kernel: - Fix assumption of encryption key size when reading fails - Add support for DEFER_SETUP with L2CAP Enhanced Credit Based Mode - Fix issue with auto-connected devices - Fix suspend handling when entering the state fails ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Yuval Basson authored
The qed_chain data structure was modified in commit 1a4a6975 ("qed: Chain support for external PBL") to support receiving an external pbl (due to iWARP FW requirements). The pages pointed to by the pbl are allocated in qed_chain_alloc and their virtual address are stored in an virtual addresses array to enable accessing and freeing the data. The physical addresses however weren't stored and were accessed directly from the external-pbl during free. Destroy-qp flow, leads to freeing the external pbl before the chain is freed, when the chain is freed it tries accessing the already freed external pbl, leading to a use-after-free. Therefore we need to store the physical addresses in additional to the virtual addresses in a new data structure. Fixes: 1a4a6975 ("qed: Chain support for external PBL") Signed-off-by:
Michal Kalderon <mkalderon@marvell.com> Signed-off-by:
Yuval Bason <ybason@marvell.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
If the mtu is greater than TD_MSS_MAX, then TSO is disabled, see rtl8169_fix_features(). Because mss is less than mtu, we can't have the case mss > TD_MSS_MAX in the TSO path. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Vladimir Oltean says: ==================== Port and flow policers for DSA (SJA1105, Felix/Ocelot) This series adds support for 2 types of policers: - port policers, via tc matchall filter - flow policers, via tc flower filter for 2 DSA drivers: - sja1105 - felix/ocelot First we start with ocelot/felix. Prior to this patch, the ocelot core library currently only supported: - Port policers - Flow-based dropping and trapping But the felix wrapper could not actually use the port policers due to missing linkage and support in the DSA core. So one of the patches addresses exactly that limitation by adding the missing support to the DSA core. The other patch for felix flow policers (via the VCAP IS2 engine) is actually in the ocelot library itself, since the linkage with the ocelot flower classifier has already been done in an earlier patch set. Then with the newly added .port_policer_add and .port_policer_del, we can also start supporting the L2 policers on sja1105. Then, for full functionality of these L2 policers on sja1105, we also implement a more limited set of flow-based policing keys for this switch, namely for broadcast and VLAN PCP. Series version 1 was submitted here: https://patchwork.ozlabs.org/cover/1263353/ Nothing functional changed in v2, only a rebase. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
This patch adds complete support for manipulating the L2 Policing Tables from this switch. There are 45 table entries, one entry per each port and traffic class, and one dedicated entry for broadcast traffic for each ingress port. Policing entries are shareable, and we use this functionality to support shared block filters. We are modeling broadcast policers as simple tc-flower matches on dst_mac. As for the traffic class policers, the switch only deduces the traffic class from the VLAN PCP field, so it makes sense to model this as a tc-flower match on vlan_prio. How to limit broadcast traffic coming from all front-panel ports to a cumulated total of 10 Mbit/s: tc qdisc add dev sw0p0 ingress_block 1 clsact tc qdisc add dev sw0p1 ingress_block 1 clsact tc qdisc add dev sw0p2 ingress_block 1 clsact tc qdisc add dev sw0p3 ingress_block 1 clsact tc filter add block 1 flower skip_sw dst_mac ff:ff:ff:ff:ff:ff \ action police rate 10mbit burst 64k How to limit traffic with VLAN PCP 0 (also includes untagged traffic) to 100 Mbit/s on port 0 only: tc filter add dev sw0p0 ingress protocol 802.1Q flower skip_sw \ vlan_prio 0 action police rate 100mbit burst 64k The broadcast, VLAN PCP and port policers are compatible with one another (can be installed at the same time on a port). Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
This adds partial configuration support for the L2 Policing Table. Out of the 45 policing entries, only 5 are used (one for each port), in a shared manner. All 8 traffic classes, and the broadcast policer, are redirected to a common instance which belongs to the ingress port. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
This patch is a trivial passthrough towards the ocelot library, which support port policers since commit 2c1d029a ("net: mscc: ocelot: Implement port policers via tc command"). Some data structure conversion between the DSA core and the Ocelot library is necessary, for policer parameters. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
The approach taken to pass the port policer methods on to drivers is pragmatic. It is similar to the port mirroring implementation (in that the DSA core does all of the filter block interaction and only passes simple operations for the driver to implement) and dissimilar to how flow-based policers are going to be implemented (where the driver has full control over the flow_cls_offload data structure). Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
Make room for other actions for the matchall filter by keeping the mirred argument parsing self-contained in its own function. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Xiaoliang Yang authored
Ocelot has 384 policers that can be allocated to ingress ports, QoS classes per port, and VCAP IS2 entries. ocelot_police.c supports to set policers which can be allocated to police action of VCAP IS2. We allocate policers from maximum pol_id, and decrease the pol_id when add a new vcap_is2 entry which is police action. Signed-off-by:
Xiaoliang Yang <xiaoliang.yang_1@nxp.com> Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Shannon Nelson says: ==================== ionic support for firmware upgrade The Pensando Distributed Services Card can get firmware upgrades from the off-host centralized management suite, and can be upgraded without a host reboot or driver reload. This patchset sets up the support for fw upgrade in the Linux driver. When the upgrade begins, the DSC first brings the link down, then stops the firmware. The driver will notice this and quiesce itself by stopping the queues and releasing DMA resources, then monitoring for firmware to start back up. When the upgrade is finished the firmware is restarted and link is brought up, and the driver rebuilds the queues and restarts traffic flow. First we separate the Link state from the netdev state, then reorganize a few things to prepare for partial tear-down of the queues. Next we fix up the state machine so that we take the Tx and Rx queues down and back up when we get LINK_DOWN and LINK_UP events. Lastly, we add handling of the FW reset itself by tearing down the lif internals and rebuilding them with the new FW setup. v2: This changes the design from (ab)using the full .ndo_stop and .ndo_open routines to getting a better separation between the alloc and the init functions so that we can keep our resource allocations as long as possible. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
When the FW RESET event comes to the driver from the firmware, or the fw_status goes to 0 (stopped) or to 0xff (no PCI connection), then shut down the driver activity. This event signals a FW upgrade where we need to quiesce all operations and wait for the FW to restart. The FW will continue the update process once it sees all the LIFs are reset. When the update process is done it will set the fw_status back to RUNNING. Meanwhile, the heartbeat check continues and when the fw_status is seen as set to running we can restart the driver operations. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
When the link goes down, we need to disable the queues on the NIC in addition to stopping the netdev stack. This lets the FW know that the driver has stopped queue activity, and then the FW can do internal reconfiguration work, whether actually Link related, or for other internal FW needs. To do this, we pull out the queue enable and disable from ionic_open() and ionic_stop() so they can be used by other routines. To help keep things sane, we swap the queue enables so that the rx queue and its napi are enabled before the tx queue which rides on the rx queues napi. We also drop the ionic_lif_quiesce() as it doesn't do anything more than what the queue disable has already taken care of. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
Make sure the queue structures exist before trying to delete them. This addresses a couple of error recovery issues. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
Clean out tx requests that didn't get finished before shutting down the queue. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
Move the irq request and free out of the qcq_init and deinit and into the alloc and free routines where they belong for better resource management. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
Move the qcq debugfs add to the queue alloc, and likewise move the debugfs delete to the queue free. The LIF debugfs add also needs to be moved, but the del is already in the LIF free. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
Add a link_status_check to the heartbeat watchdog. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
Rearrange the link_up/link_down messages so that we announce link up when we first notice that the link is up when the driver loads, and decouple the link_up/link_down messages from the UP and DOWN netdev state. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Cited commit extended the enums 'hwtstamp_tx_types' and 'hwtstamp_rx_filters' with values that were not accounted for in the switch statements, resulting in the build warnings below. Fix by adding a default case. drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c: In function ‘mlxsw_sp_ptp_get_message_types’: drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c:915:2: warning: enumeration value ‘__HWTSTAMP_TX_CNT’ not handled in switch [-Wswitch] 915 | switch (tx_type) { | ^~~~~~ drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c:927:2: warning: enumeration value ‘__HWTSTAMP_FILTER_CNT’ not handled in switch [-Wswitch] 927 | switch (rx_filter) { | ^~~~~~ Fixes: f76510b4 ("ethtool: add timestamping related string sets") Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Reported-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Eran Ben Elisha says: ==================== Devlink health auto attributes refactor This patchset refactors the auto-recover health reporter flag to be explicitly set by the devlink core. In addition, add another flag to control auto-dump attribute, also to be explicitly set by the devlink core. For that, patch 0001 changes the auto-recover default value of netdevsim dummy reporter. After reporter registration, both flags can be altered be administrator only. Changes since v1: - Change default behaviour of netdevsim dummy reporter - Move initialization of DEVLINK_ATTR_HEALTH_REPORTER_AUTO_DUMP ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eran Ben Elisha authored
On low memory system, run time dumps can consume too much memory. Add administrator ability to disable auto dumps per reporter as part of the error flow handle routine. This attribute is not relevant while executing DEVLINK_CMD_HEALTH_REPORTER_DUMP_GET. By default, auto dump is activated for any reporter that has a dump method, as part of the reporter registration to devlink. Signed-off-by:
Eran Ben Elisha <eranbe@mellanox.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eran Ben Elisha authored
When health reporter is registered to devlink, devlink will implicitly set auto recover if and only if the reporter has a recover method. No reason to explicitly get the auto recover flag from the driver. Remove this flag from all drivers that called devlink_health_reporter_create. All existing health reporters set auto recovery to true if they have a recover method. Yet, administrator can unset auto recover via netlink command as prior to this patch. Signed-off-by:
Eran Ben Elisha <eranbe@mellanox.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Reviewed-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eran Ben Elisha authored
Health reporters should be registered with auto recover set to true. Align dummy reporter behaviour with that, as in later patch the option to set auto recover behaviour will be removed. In addition, align netdevsim selftest to the new default value. Signed-off-by:
Eran Ben Elisha <eranbe@mellanox.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Richard Cochran authored
The PTP Hardware Clock (PHC) subsystem offers an API for configuring programmable pins. User space sets or gets the settings using ioctls, and drivers verify dialed settings via a callback. Drivers may also query pin settings by calling the ptp_find_pin() method. Although the core subsystem protects concurrent access to the pin settings, the implementation places illogical restrictions on how drivers may call ptp_find_pin(). When enabling an auxiliary function via the .enable(on=1) callback, drivers may invoke the pin finding method, but when disabling with .enable(on=0) drivers are not permitted to do so. With the exception of the mv88e6xxx, all of the PHC drivers do respect this restriction, but still the locking pattern is both confusing and unnecessary. This patch changes the locking implementation to allow PHC drivers to freely call ptp_find_pin() from their .enable() and .verify() callbacks. V2 ChangeLog: - fixed spelling in the kernel doc - add Vladimir's tested by tag Signed-off-by:
Richard Cochran <richardcochran@gmail.com> Reported-by:
Yangbo Lu <yangbo.lu@nxp.com> Tested-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jiri Pirko authored
The rest of the devlink code sets the extack message using NL_SET_ERR_MSG_MOD. Change the existing appearances of NL_SET_ERR_MSG to NL_SET_ERR_MSG_MOD. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jiri Pirko says: ==================== net: sched: expose HW stats types per action used by drivers The first patch is just adding a helper used by the second patch too. The second patch is exposing HW stats types that are used by drivers. Example: $ tc filter add dev enp3s0np1 ingress proto ip handle 1 pref 1 flower dst_ip 192.168.1.1 action drop $ tc -s filter show dev enp3s0np1 ingress filter protocol ip pref 1 flower chain 0 filter protocol ip pref 1 flower chain 0 handle 0x1 eth_type ipv4 dst_ip 192.168.1.1 in_hw in_hw_count 2 action order 1: gact action drop random type none pass val 0 index 1 ref 1 bind 1 installed 10 sec used 10 sec Action statistics: Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 used_hw_stats immediate <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jiri Pirko authored
It may be up to the driver (in case ANY HW stats is passed) to select which type of HW stats he is going to use. Add an infrastructure to expose this information to user. $ tc filter add dev enp3s0np1 ingress proto ip handle 1 pref 1 flower dst_ip 192.168.1.1 action drop $ tc -s filter show dev enp3s0np1 ingress filter protocol ip pref 1 flower chain 0 filter protocol ip pref 1 flower chain 0 handle 0x1 eth_type ipv4 dst_ip 192.168.1.1 in_hw in_hw_count 2 action order 1: gact action drop random type none pass val 0 index 1 ref 1 bind 1 installed 10 sec used 10 sec Action statistics: Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 used_hw_stats immediate <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jiri Pirko authored
Introduce a helper to pass value and selector to. The helper packs them into struct and puts them into netlink message. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-nextDavid S. Miller authored
Steffen Klassert says: ==================== pull request (net-next): ipsec-next 2020-03-28 1) Use kmem_cache_zalloc() instead of kmem_cache_alloc() in xfrm_state_alloc(). From Huang Zijiang. 2) esp_output_fill_trailer() is the same in IPv4 and IPv6, so share this function to avoide code duplcation. From Raed Salem. 3) Add offload support for esp beet mode. From Xin Long. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Christophe JAILLET authored
There is no point in preparing the module name in a buffer. The format string can be passed diectly to 'request_module()'. This axes a few lines of code and cleans a few things: - max len for a driver name is MODULE_NAME_LEN wich is ~ 60 chars, not 128. It would be down-sized in 'request_module()' - we should pass the total size of the buffer to 'snprintf()', not the size minus 1 Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
YueHaibing authored
Fix sparse warnings: drivers/net/ethernet/amazon/ena/ena_netdev.c:460:6: warning: symbol 'ena_xdp_exchange_program_rx_in_range' was not declared. Should it be static? drivers/net/ethernet/amazon/ena/ena_netdev.c:481:6: warning: symbol 'ena_xdp_exchange_program' was not declared. Should it be static? drivers/net/ethernet/amazon/ena/ena_netdev.c:1555:5: warning: symbol 'ena_xdp_handle_buff' was not declared. Should it be static? Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-