- 14 Dec, 2018 2 commits
-
-
Petr Machata authored
The NETDEV_CHANGEADDR notification is emitted after a device address changes. Extending this message to allow vetoing is certainly possible, but several other notification types have instead adopted a simple two-stage approach: first a "pre" notification is sent to make sure all interested parties are OK with a change that's about to be done. Then the change is done, and afterwards a "post" notification is sent. This dual approach is easier to use: when the change is vetoed, nothing has changed yet, and it's therefore unnecessary to roll anything back. Therefore adopt it for NETDEV_CHANGEADDR as well. To that end, add NETDEV_PRE_CHANGEADDR and an info structure to go along with it. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
A follow-up patch will add a notifier type NETDEV_PRE_CHANGEADDR, which allows vetoing of MAC address changes. One prominent path to that notification is through dev_set_mac_address(). Therefore give this function an extack argument, so that it can be packed together with the notification. Thus a textual reason for rejection (or a warning) can be communicated back to the user. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 13 Dec, 2018 15 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5e-updates-2018-12-11 From Eli Britstein, Patches 1-10 adds remote mirroring support. Patches 1-4 refactor encap related code as pre-steps for using per destination encapsulation properties. Patches 5-7 use extended destination feature for single/multi destination scenarios that have a single encap destination. Patches 8-10 enable multiple encap destinations for a TC flow. From, Daniel Jurgens, Patch 11, Use CQE padding for Ethernet CQs, PPC showed up to a 24% improvement in small packet throughput From Eyal Davidovich, patches 12-14, FW monitor counter support FW monitor counters feature came to solve the delayed reporting of FW stats in the atomic get_stats64 ndo, since we can't access the FW at that stage, this feature will enable immediate FW stats updates in the driver via fw events on specific stats updates. Patch 12, cleanup to avoid querying a FW counter when it is not supported Patch 13, Monitor counters FW commands support Patch 14, Use monitor counters in ethernet netdevice to update FW stats reported in the atomic get_stats64 ndo. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Biao Huang authored
Add MODULE_LICENSE info to fix this: WARNING: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.o Signed-off-by: Biao Huang <biao.huang@mediatek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/mellanox/mlx5/core/en_rep.c: In function 'mlx5e_vport_rep_load': drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:1490:21: warning: variable 'upriv' set but not used [-Wunused-but-set-variable] drivers/net/ethernet/mellanox/mlx5/core/en_rep.c: In function 'mlx5e_vport_rep_unload': drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:1557:21: warning: variable 'upriv' set but not used [-Wunused-but-set-variable] It not used any more since commit ef381359 ("net/mlx5e: Replace egdev with indirect block notifications"). Also remove unused variable 'uplink_rpriv' after this change. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Leon Romanovsky <leonro@mellanox.com> Acked-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Petr Machata says: ==================== Pass extack to SWITCHDEV_PORT_OBJ_ADD Drivers may need to do validation as a result of port object addition. An example is mlxsw, which needs to check the configuration of a VXLAN device attached to an offloaded bridge. Without a mapped VLAN, the invalidity of the device is not important, but as soon as a pvid, untagged VLAN is configured for the device, it has to be validated and offloaded. Should the validation fail, there's currently no way to communicate details of the failure to the user, beyond an error number. Because currently, extack is not available at all in that area of code, this patch starts down at the RTNL level and progresses up towards the driver(s). In patch #1, ndo_bridge_setlink is updated to include extack, and callbacks of all clients are updated as well (ignoring the argument). In patch #2, the bridge driver is updated to propagate the extack through to the switchdev border, br_switchdev_port_vlan_add(). Patches #3, #4 and #5 then gradually extend switchdev to pass the extack argument through to the switchdev blocking notifier chain. Patches #6 and #7 then update mlxsw to pass the extack argument from VXLAN events resp. port events on to mlxsw_sp_bridge_8021q_vxlan_join(). Finally in patches #8 and #9, the code paths from the previous two patches are verified to yield an error message. v2: - Patch #1: - In ndo_bridge_setlink(), keep the whole extack declaration on the same line. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
Test mapping a VLAN at a port device such that on the same VLAN, there already is an unoffloadable VXLAN device. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
Test mapping a VLAN at a VXLAN device that can't be offloaded. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
After switchdev_handle_port_obj_add() was extended in a preceding patch, mlxsw_sp_port_obj_add() now takes an extack argument. Propagate it further by extending a callee chain from mlxsw_sp_port_vlans_add(), via mlxsw_sp_bridge_port_vlan_add() via mlxsw_sp_port_vlan_bridge_join() via mlxsw_sp_port_vlan_fid_join() to mlxsw_sp_bridge_ops.fid_get, adding an extack argument for each of them. This code path is used when a VLAN is added to a port netdevice if there already is an unoffloadable VXLAN device with that VLAN mapped. mlxsw_sp_bridge_8021d_port_join() is updated to obey the new interfaces changed by the abovementioned code, propagating extack ultimately from NETDEV_CHANGEUPPER events. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
Now that VLAN port object addition notifications carry an extack, propagate it from mlxsw_sp_switchdev_vxlan_vlans_add() through mlxsw_sp_switchdev_vxlan_vlan_add() to mlxsw_sp_bridge_8021q_vxlan_join(). This code path is used when a VLAN is added to a VXLAN netdevice that cannot be offloaded. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
Drivers use switchdev_handle_port_obj_add() to handle recursive descent through lower devices. Change this function prototype to take add_cb that itself takes an extack argument. Decode extack from switchdev_notifier_port_obj_info and pass it to add_cb. Update mlxsw and ocelot drivers which use this helper. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
In order to pass extack to the drivers that need it, add an extack field to struct switchdev_notifier_info, and an extack argument to the function call_switchdev_blocking_notifiers(). Also add a helper function switchdev_notifier_info_to_extack(). Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
After the previous patch, bridge driver has extack argument available to pass to switchdev. Therefore extend switchdev_port_obj_add() with this argument, updating all callers, and passing the argument through to switchdev_port_obj_notify(). Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
ndo_bridge_setlink has been updated in the previous patch to have extack available, and changelink RTNL op has had this argument since the time extack was added. Propagate both through the bridge driver to eventually reach br_switchdev_port_vlan_add(), where it will be used by subsequent patches. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Acked-by: Ivan Vecera <ivecera@redhat.com> Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
Drivers may not be able to implement a VLAN addition or reconfiguration. In those cases it's desirable to explain to the user that it was rejected (and why). To that end, add extack argument to ndo_bridge_setlink. Adapt all users to that change. Following patches will use the new argument in the bridge driver. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jonathan Toppins authored
bnxt_en 0000:19:00.0 (unregistered net_device) (uninitialized): hwrm req_type 0x190 seq id 0x6 error 0xffff The message above is commonly seen when a newer driver is used on hardware with older firmware. The issue is this message means nothing to anyone except Broadcom. Remove the message to not confuse users as this message is really not very informative. Signed-off-by: Jonathan Toppins <jtoppins@redhat.com> Acked-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yangtao Li authored
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 12 Dec, 2018 14 commits
-
-
David S. Miller authored
Biao Huang says: ==================== add Ethernet driver support for mt2712 Changes in v6: modifications according to comments from Rob/Andrew/Sean: 1. use delay_ps instead of delay stage. 2. add comments in driver to avoid confusion. 2. rewrite set_delay function. 3. modify binding document for properties: tx-delay-ps/rx-delay-ps/pericfg etc. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Biao Huang authored
The commit adds the device tree binding documentation for the MediaTek DWMAC found on MediaTek MT2712. Signed-off-by: Biao Huang <biao.huang@mediatek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Biao Huang authored
Add Ethernet support for MediaTek SoCs from the mt2712 family Signed-off-by: Biao Huang <biao.huang@mediatek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Add Spectrum-2 multicast routing support Nir says: In Spectrum the firmware provided an abstraction for multicast routing on top of the policy engine. In Spectrum-2 this is no longer the case and the driver must interact directly with the policy engine in order to program multicast routes. Every route is written as an ACL rule, its priority set according to route type (*,G) or (S,G) and its action is an appropriate multicast routing action. Multicast routes are written to a specific ACL group which is bound to the appropriate IP protocol IPv4/IPv6. Patch #1 adds PEMRBT register needed to declare which ACL group is dedicated for each IP protocol multicast routing function. Patch #2 Changes initialization order and puts ACL before router as multicast router now uses ACL module. Patch #3 adds Spectrum-2 ACL keys needed for multicast route matching. Patch #4 adds another ACL profile - in addition to existing flower profile - which allows the multicast routing module to program rules directly into the ACL block. Patch #5 adds the ability to update ACL rules' action, since multicast routes actions may be updated after being configured. Patch #6 separates rule creation operation and rule action creation operation as in multicast router the action is created before the route is inserted. Patch #7 sharpens priority handling in Spectrum-2, to ensure incorrect values are not set to rule's priority. Patch #8 adds the implementation of multicast routing for IPv4 and IPv6 over existing ACL rule programming Finally, patch #9 adds a test for IPv4/IPv6 multicast routing. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nir Dotan authored
Introduce basic testing for both IPv4 and IPv6 multicast. The test creates an (S,G) type route, sends traffic and verifies traffic arrives when the route is present and then verifies traffic does not arrive after deleting the route. This test requires smcroute - https://github.com/troglobit/smcroute which is a tool that allows creation of static multicast routes. Signed-off-by: Nir Dotan <nird@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nir Dotan authored
Add implementation of Spectrum-2 multicast routes for both IPv4 and IPv6 by using ACL module explicitly. In Spectrum-2, multicast routes are set as ACL rules, so initialization takes care of creating dedicated ACL groups and binding them to the appropriate multicast routing protocol IPv4/IPv6, and afterwards routes configuration translates to setting explicit ACL rules. Signed-off-by: Nir Dotan <nird@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nir Dotan authored
In Spectrum-2, higher priority value wins and priority valid values are in the range of {1,cap_kvd_size-1}. mlxsw_sp_acl_tcam_priority_get converts from lower-bound priorities alike tc flower to Spectrum-2 HW range. Up until now tc flower did not provide priority 0 or reached the maximal value, however multicast routing does provide priority 0. Therefore, Change mlxsw_sp_acl_tcam_priority_get to verify priority is in the correct range. Make sure priority is never set to zero and never exceeds the maximal allowed value. Signed-off-by: Nir Dotan <nird@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nir Dotan authored
Up until now, when ACL rule was created its action was created with it. It suits well for tc flower where ACL rule always needs an action, however it does not suit multicast router, where the action is created prior to setting a route, which in Spectrum-2 is actually an ACL rule. Add support for rule creation without action creation. Do it by adding afa_block argument to mlxsw_sp_acl_rule_create, which if NULL then an action would be created, also add an indication within struct mlxsw_sp_acl_rule_info that tells if the action should be destroyed when the rule is destroyed. Signed-off-by: Nir Dotan <nird@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nir Dotan authored
Multicast routes actions may be updated after creation. An example for that is an addition of an egress interface to an existing route. So far, as tc flower API dictated, ACL rules were either created or deleted. Since multicast routes in Spectrum-2 are written to ACL as any rule, it is required to allow the update of a rule's action as it may change. Add methods and operations to support updating rule's action. This is supported only for Spectrum-2. Signed-off-by: Nir Dotan <nird@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nir Dotan authored
Add specific ACL operations needed for programming multicast routing ACL groups and routes. Signed-off-by: Nir Dotan <nird@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nir Dotan authored
Add virtual router ID fields to Spectrum-2 key blocks set, as the field is required for multicast routing. Signed-off-by: Nir Dotan <nird@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nir Dotan authored
In Spectrum-2, MC routing is implemented using ACL block explicitly, so router initialization should take place after ACL initialization. Set the initialization of the ACL block before IP router initizalization takes place, so multicast router will be able to allocate ACL data structures and create its required chains. Signed-off-by: Nir Dotan <nird@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nir Dotan authored
In Spectrum-2, multicast routing is implemented explicitly using policy engine (ACL) block. PEMRBT register is used to bind a dedicated ACL group to a specific IP protocol. Add the register to be later used in multicast router implementation. Signed-off-by: Nir Dotan <nird@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Xue Chaojing authored
There is no need to schedule a different tasklet for refill, This patch remove it. Suggested-by: Neil Horman <nhorman@redhat.com> Signed-off-by: Xue Chaojing <xuechaojing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 11 Dec, 2018 9 commits
-
-
Eyal Davidovich authored
- Adding new notifier block (struct mlx5_nb) monitor_counters_nb for handeling MONITOR_COUNTER new event type. - Adding work queue element: monitor_counters_work for re-arm and update stats. - We re-queue the update stat work, only when working over firmware that doesn't support the monitored counters. Signed-off-by: Eyal Davidovich <eyald@mellanox.com> Reviewed-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
Eyal Davidovich authored
new file monitor_stats.c for the new API. add arm_monitor_counter new command support. add set_monitor_counter new command support. The device can monitor specific counters and provide an event to notify when these counters are changed. The monitoring is done in best effort manner where the minimum notification period is 200 ms, however when the device is loaded, the notification might be delayed. To configure the required counters to be monitored, the SET_MONITOR_COUNTER command shall be used with a list of counters to be monitored. The device firmware can monitor up to HCA_CAP.max_num_of_monitor_counters. The configuration is done based on counter type (such as ppcnt, q counter, etc) and additional param according to the type of counter selected. Upon monitor counter change, the device will generate Monitor_Counter_Change event. The device will not generate new events unless the driver re-arms the monitoring functionality, using the ARM_MONITOR_COUNTER command. Signed-off-by: Eyal Davidovich <eyald@mellanox.com> Reviewed-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
Eyal Davidovich authored
PPCNT is not supported if PCAM access reg is supported and ppcnt bit is clear. Signed-off-by: Eyal Davidovich <eyald@mellanox.com> Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
Daniel Jurgens authored
Writing 64B CQEs to 128B cache lines results in a RMW operation. Padding the CQEs to 128B if possible improves performance on 128B cache line systems like PPC. Testing on PPC showed up to a 24% improvement in small packet throughput vs the default behavior, depending on the workload and system topology. Signed-off-by: Daniel Jurgens <danielj@mellanox.com> Reviewed-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
Eli Britstein authored
Currently a flow is associated with a single encap structure. The FW extended destination features enables the driver to associate a flow with multiple encap instances. Change the encap id field from a flow scope to a per destination value in the flow attributes struct. Use the encaps array to associate a flow table entry with multiple encap entries. Update the neigh logic to offload only if all encapsulations used in a flow are connected, and un-offload upon the first one disconnected. Note that the driver can now support up to two encap destinations. Signed-off-by: Eli Britstein <elibr@mellanox.com> Reviewed-by: Oz Shlomo <ozsh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
Eli Britstein authored
Currently a flow can be associated with a single encap entry. The extended destination feature enables the driver to configure multiple encap entries per flow. Change the encap flow association field to array as a pre-step towards supporting multiple encap destinations. Use only the first array element, with no functional change. Signed-off-by: Eli Britstein <elibr@mellanox.com> Reviewed-by: Oz Shlomo <ozsh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
Eli Britstein authored
Currently the driver can support only a single TC tunnel_set action. Change the tunnel info fields to arrays, as a pre-step to support multiple encapsulations for a single flow, with no functional change. Signed-off-by: Eli Britstein <elibr@mellanox.com> Reviewed-by: Oz Shlomo <ozsh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
Eli Britstein authored
A rule with the following actions is split to a two level FDB: 1. Forward to local mirror vport 2. Header rewrite 3. Forward to local vport In the first level flow table, forward the packet to the local port and forward the packet to the second level flow table for header rewrite and local port forwarding. This configuration fails when mirroring to a remote encapsulated destination because currently an FTE cannot support encap and table destinations. Use the extended destination capabilities to configure the first level flow table with a multi-destination FTE to the uplink and second level table and the second level flow table for the header rewrite and local port forwarding. Signed-off-by: Eli Britstein <elibr@mellanox.com> Reviewed-by: Oz Shlomo <ozsh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-
Eli Britstein authored
Currently the FTE encap flag applies to all destinations. To support mirroring encapsulated traffic to a local port the driver split the two destinations to two flow table entries: Table#0: - FWD to the local vport - Goto table#1 Table#1: - Encap and FWD to wire The firmware extended destination capabilities enable the driver to set an encapsulation flag per destination. Remove the split logic and use the extended destination mechanism instead. Note that split technique is still required for pedit and VLAN push scenarios. Signed-off-by: Eli Britstein <elibr@mellanox.com> Reviewed-by: Oz Shlomo <ozsh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
-