- 07 Dec, 2018 19 commits
-
-
Shiju Jose authored
1.The command interface for queryng and clearing hw errors is changed, which requires the new process error functions to be added. This patch removes all the current process error functions and associated definitions. The new functions to handle ras errors would be added in this patch set. 2. Fixed order issue of the hw_blk table. Signed-off-by:
Shiju Jose <shiju.jose@huawei.com> Signed-off-by:
Salil Mehta <salil.mehta@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Un/offload FDB on NVE detach/attach Petr says: When a VXLAN device is attached to a bridge of a driver capable of offloading such, or upped, the FDB entries already present at the device need to be offloaded. Similarly when an offloaded VXLAN device ceases being interesting (it is downed, or detached, or a front-panel port netdevice is detached from the bridge that the VXLAN device is attached to), any offloaded FDB entries need to be unoffloaded and unmarked. This attach / detach processing is implemented in this patchset. In patch #1, a code pattern is extracted into a named function for easier reuse. In patch #2, vxlan_fdb_replay() is added to send SWITCHDEV_VXLAN_FDB_ADD_TO_DEVICE for each FDB entry with a given VNI. The intention is that the offloading driver will interpret these events like any other and thus offload the FDB entries that existed prior to VXLAN attach. In patches #3 and #4, the functions vxlan_fdb_clear_offload() resp. br_fdb_clear_offload() are added. These clear the offloaded flag at matching FDB entries. In patches #5-#9, we introduce FID-type-specific and NVE-type-specific ops necessary to properly abstract invocations of the replay/clear functions. Finally patch #10 implements the FDB management. In patch #11, the mlxsw-specific test case is extended to check that the management of offload marks under the newly-supported situations is correct. Patch #12, from Ido, exercises the new code paths in actual functional test. v2: - Patch #1: - Modify vxlan_fdb_switchdev_notifier_info() to initialize the structure through a passed-in pointer argument, instead of returning it as a value. - Patch #2: - Adapt to API change in vxlan_fdb_switchdev_notifier_info() ==================== Signed-off-by: -
Ido Schimmel authored
When using VLAN-aware bridges with VXLAN, the VLAN that is mapped to the VNI of the VXLAN device is that which is configured as "pvid untagged" on the corresponding bridge port. When these flags are toggled or when the VLAN is deleted entirely, remote hosts should not be able to receive packets from the VTEP. Add a test case for above mentioned scenarios. Signed-off-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Petr Machata authored
When a VXLAN device is attached to an offloaded bridge, or when a front-panel port is attached to a bridge that already has a VXLAN device, mlxsw should offload the existing offloadable FDB entries. Similarly when VXLAN device is downed, the FDB entries are unoffloaded, and the marks thus need to be cleared. Similarly when a front-panel port device is attached to a bridge with a VXLAN device, or when VLAN flags are tweaked on a VXLAN port attached to a VLAN-aware bridge. Test that the replaying / clearing logic works by observing transitions in presence of offload marks under different scenarios. Signed-off-by:
-
Petr Machata authored
Any existing NVE FDB entries need to be offloaded when NVE is enabled for a given FID. Recent patches have added fdb_replay op for this, so just invoke it from mlxsw_sp_nve_fid_enable(). When NVE is disabled on a FID, any existing FDB offloaded marks need to be cleared on NVE device as well as on its bridge master. An op to handle this, fdb_clear_offload, has been added to FID ops and NVE ops in previous patches. Add code to resolve the NVE device, NVE type, and dispatch to both fdb_clear_offload ops. Signed-off-by:
-
Petr Machata authored
If there are any offloaded FDB entries at bridge master of an NVE device at the time that it's un-offloaded, their offloaded marks need to be cleared. How that is done depends on whether the bridge in question is vlan aware. Therefore add a per-FID-type operation. Implement the operation for the 802.1q and 802.1d bridges. Add and publish a function mlxsw_sp_fid_fdb_clear_offload() to dispatch to the new operation according to FID type. Signed-off-by:
-
Petr Machata authored
If there are any offloaded FDB entries at an NVE device at the time that it's un-offloaded, their offloaded marks need to be cleared. How that is done depends on NVE device type, and therefore add a per-NVE-type operation. Implement the operation for the sole NVE device type currently supported by mlxsw, VXLAN. Signed-off-by:
-
Petr Machata authored
A replay of FDB needs to be performed so that the FDB entries existing at the NVE device are offloaded. How the replay is done depends on NVE device type, and therefore add a per-NVE-type operation. Implement the operation for the sole NVE device type currently supported by mlxsw, VXLAN. Signed-off-by:
-
Petr Machata authored
The notifier block will need to be passed to vxlan_fdb_replay() in a follow-up patch. Signed-off-by:
-
Petr Machata authored
A follow-up patch will add support for replay and for clearing of offload marks. These are NVE type-sensitive operations, and to be able to dispatch them properly, a FID needs to know what NVE type is attached to it. Therefore, track the NVE type at struct mlxsw_sp_fid. Extend mlxsw_sp_fid_vni_set() to take it as an argument, and add mlxsw_sp_fid_nve_type(). Signed-off-by:
-
Petr Machata authored
When a driver unoffloads all FDB entries en bloc, it's inefficient to send the switchdev notification one by one. Add a helper that unsets the offload flag on FDB entries on a given bridge port and VLAN. Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Petr Machata authored
When a driver unoffloads all FDB entries en bloc, it's inefficient to send the switchdev notification one by one. Add a helper that walks the FDB table, unsetting the offload flag on RDST with a given VNI. Signed-off-by:
-
Petr Machata authored
When a VXLAN device becomes relevant to a driver (such as when it is attached to an offloaded bridge), the driver will generally need to walk the existing FDB entries and offload them. Add a function vxlan_fdb_replay() to call a given notifier block for each FDB entry with a given VNI. Signed-off-by:
-
Petr Machata authored
There are currently two places that need to initialize the notifier info structure, and one more is coming next when vxlan_fdb_replay() is introduced. These three instances have / will have very similar code that is easy to abstract away into a named function. Add such function, vxlan_fdb_switchdev_notifier_info(), and call it from vxlan_fdb_switchdev_call_notifiers() and vxlan_fdb_find_uc(). Signed-off-by:
-
David S. Miller authored
Igor Russkikh says: ==================== net: aquantia: add RSS configuration In this patchset few bugs related to RSS are fixed and RSS table and hash key configuration is added. We also do increase max number of HW rings upto 8. v2: removed extra arg check ==================== Signed-off-by: -
Dmitry Bogdanov authored
Add support of configuration of RSS hash key and RSS indirection table. Signed-off-by:
Dmitry Bogdanov <dmitry.bogdanov@aquantia.com> Signed-off-by:
Igor Russkikh <igor.russkikh@aquantia.com> Signed-off-by:
-
Dmitry Bogdanov authored
Now RSS indirection table is initialized before setting up the number of hw queues, consequently the table may be filled by non existing queues. This patch moves the initialization when the number of hw queues is known. Signed-off-by:
-
Dmitry Bogdanov authored
Increase the upper limit of the hw queues up to 8. This makes RSS better on multiheaded cpus. This is a maximum AQC hardware supports in one traffic class. The actual value is still limited by a number of available cpu cores. Signed-off-by:
-
Dmitry Bogdanov authored
Set RSS indirection table and RSS hash key sizes to their real size. Signed-off-by:
-
- 06 Dec, 2018 21 commits
-
-
David S. Miller authored
Petr Machata says: ==================== Pass extack to NETDEV_PRE_UP Drivers may need to validate configuration of a device that's about to be upped. An example is mlxsw, which needs to check the configuration of a VXLAN device attached to an offloaded bridge. Should the validation fail, there's currently no way to communicate details of the failure to the user, beyond an error number. Therefore this patch set extends the NETDEV_PRE_UP event to include extack, if available. There are three vectors through which NETDEV_PRE_UP invocation can be reached. The two major ones are dev_open() and dev_change_flags(), the last is then __dev_change_flags(). In patch #1, the first access vector, dev_open() is addressed. An extack parameter is added and all users converted to use it. Before addressing the second vector, two preparatory patches propagate extack argument to the proximity of the dev_change_flags() call in VRF and IPVLAN drivers. That happens in patches #2 and #3. Then in patch #4, dev_change_flags() is treated similarly to dev_open(). Likewise in patch #5, __dev_change_flags() is extended. Then in patches #6 and #7, the extack is finally propagated all the way to the point where the notification is emitted. This change allows particularly mlxsw (which already has code to leverage extack if available) to communicate to the user error messages regarding VXLAN configuration. In patch #8, add a test case that exercises this code and checks that an error message is propagated. For example: local 192.0.2.17 remote 192.0.2.18 \ dstport 4789 nolearning noudpcsum tos inherit ttl 100 local 192.0.2.17 remote 192.0.2.18 \ dstport 4789 nolearning noudpcsum tos inherit ttl 100 Error: mlxsw_spectrum: Conflicting NVE tunnels configuration. v2: - Add David Ahern's tags. ==================== Signed-off-by: -
Petr Machata authored
Add a testsuite dedicated to testing extack propagation and related functionality. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Reviewed-by:
-
Petr Machata authored
Drivers may need to validate configuration of a device that's about to be upped. Should the validation fail, there's currently no way to communicate details of the failure to the user, beyond an error number. To mend that, change __dev_open() to take an extack argument and pass it from __dev_change_flags() and dev_open(), where it was propagated in the previous patches. Change __dev_open() to call call_netdevice_notifiers_extack() so that the passed-in extack is attached to the NETDEV_PRE_UP notifier. Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Petr Machata authored
In order to propagate extack through NETDEV_PRE_UP, add a new function call_netdevice_notifiers_extack() that primes the extack field of the notifier info. Convert call_netdevice_notifiers() to a simple wrapper around the new function that passes NULL for extack. Signed-off-by:
-
Petr Machata authored
In order to pass extack together with NETDEV_PRE_UP notifications, it's necessary to route the extack to __dev_open() from diverse (possibly indirect) callers. The last missing API is __dev_change_flags(). Therefore extend __dev_change_flags() with and extra extack argument and update the two existing users. Since the function declaration line is changed anyway, name the struct net_device argument to placate checkpatch. Signed-off-by:
-
Petr Machata authored
In order to pass extack together with NETDEV_PRE_UP notifications, it's necessary to route the extack to __dev_open() from diverse (possibly indirect) callers. One prominent API through which the notification is invoked is dev_change_flags(). Therefore extend dev_change_flags() with and extra extack argument and update all users. Most of the calls end up just encoding NULL, but several sites (VLAN, ipvlan, VRF, rtnetlink) do have extack available. Since the function declaration line is changed anyway, name the other function arguments to placate checkpatch. Signed-off-by:
-
Petr Machata authored
A follow-up patch will extend dev_change_flags() with an extack argument. Extend ipvlan_set_port_mode() to have that argument available for the conversion. Signed-off-by:
-
Petr Machata authored
A follow-up patch will extend dev_change_flags() with an extack argument. Extend cycle_netdev() to have that argument available for the conversion. Signed-off-by:
-
Petr Machata authored
In order to pass extack together with NETDEV_PRE_UP notifications, it's necessary to route the extack to __dev_open() from diverse (possibly indirect) callers. One prominent API through which the notification is invoked is dev_open(). Therefore extend dev_open() with and extra extack argument and update all users. Most of the calls end up just encoding NULL, but bond and team drivers have the extack readily available. Signed-off-by:
-
Pedro Tammela authored
2 goto labels are indented with a tab. remove the tabs and keep the code style consistent. Signed-off-by:
Pedro Tammela <pctammela@gmail.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
David S. Miller authored
Andrew Lunn says: ==================== Adjust MTU of DSA master interface DSA makes use of additional headers to direct a frame in/out of a specific port of the switch. When the slave interfaces uses an MTU of 1500, the master interface can be asked to handle frames with an MTU of 1504, or 1508 bytes. Some Ethernet interfaces won't transmit/receive frames which are bigger than their MTU. Automate the increasing of the MTU on the master interface, by adding to each tagging driver how much overhead they need, and then calling dev_set_mtu() of the master interface to increase its MTU as needed. ==================== Signed-off-by: -
Andrew Lunn authored
DSA tagging of frames sent over the master interface to the switch increases the size of the frame. Such frames can then be bigger than the normal MTU of the master interface, and it may drop them. Use the overhead information from the tagger to set the MTU of the master device to include this overhead. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Andrew Lunn authored
Each DSA tag protocol needs to add additional headers to the Ethernet frame in order to direct it towards a specific switch egress port. It must also remove the head from a frame received from a switch. Indicate the maximum size of these headers in the tag protocol ops structure, so the core can take these overheads into account. Signed-off-by:
-
Li RongQing authored
caller has guaranted that rxhash is not zero Signed-off-by:
Li RongQing <lirongqing@baidu.com> Acked-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
-
Li RongQing authored
tun flow entry 'updated' fields are written when receive every packet. Thus if a flow is receiving packets from a particular flow entry, it'll cause false-sharing with all the other who has looked it up, so move it in its own cache line and update 'queue_index' and 'update' field only when they are changed to reduce the cache false-sharing. Signed-off-by:
Zhang Yu <zhangyu31@baidu.com> Signed-off-by:
Wang Li <wangli39@baidu.com> Signed-off-by:
-
David Ahern authored
Add extack messages for failures in neigh_add and neigh_delete. Signed-off-by:
-
Hoang Le authored
When setting LINK tolerance, node timer interval will be calculated base on the LINK with lowest tolerance. But when calculated, the old node timer interval only updated if current setting value (tolerance/4) less than old ones regardless of number of links as well as links' lowest tolerance value. This caused to two cases missing if tolerance changed as following: Case 1: 1.1/ There is one link (L1) available in the system 1.2/ Set L1's tolerance from 1500ms => lower (i.e 500ms) 1.3/ Then, fallback to default (1500ms) or higher (i.e 2000ms) Expected: node timer interval is 1500/4=375ms after 1.3 Result: node timer interval will not being updated after changing tolerance at 1.3 since its value 1500/4=375ms is not less than 500/4=125ms at 1.2. Case 2: 2.1/ There are two links (L1, L2) available in the system 2.2/ L1 and L2 tolerance value are 2000ms as initial 2.3/ Set L2's tolerance from 2000ms => lower 1500ms 2.4/ Disable link L2 (bring down its bearer) Expected: node timer interval is 2000ms/4=500ms after 2.4 Result: node timer interval will not being updated after disabling L2 since its value 2000ms/4=500ms is still not less than 1500/4=375ms at 2.3 although L2 is already not available in the system. To fix this, we start the node interval calculation by initializing it to a value larger than any conceivable calculated value. This way, the link with the lowest tolerance will always determine the calculated value. Acked-by:Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
Hoang Le <hoang.h.le@dektech.com.au> Signed-off-by:
-
Rob Herring authored
Convert string compares of DT node names to use of_node_name_eq helper instead. This removes direct access to the node name pointer. For instances using of_node_cmp, this has the side effect of now using case sensitive comparisons. This should not matter for any FDT based system which all of these are. Cc: "David S. Miller" <davem@davemloft.net> Cc: Claudiu Manoil <claudiu.manoil@nxp.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Wingman Kwok <w-kwok2@ti.com> Cc: Murali Karicheri <m-karicheri2@ti.com> Cc: netdev@vger.kernel.org Cc: linux-omap@vger.kernel.org Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Peter Oskolkov authored
When testing high-bandwidth TCP streams with large windows, high latency, and low jitter, netem consumes a lot of CPU cycles doing rbtree rebalancing. This patch uses a linear list/queue in addition to the rbtree: if an incoming packet is past the tail of the linear queue, it is added there, otherwise it is inserted into the rbtree. Without this patch, perf shows netem_enqueue, netem_dequeue, and rb_* functions among the top offenders. With this patch, only netem_enqueue is noticeable if jitter is low/absent. Suggested-by:
Peter Oskolkov <posk@google.com> Reviewed-by:
-
David S. Miller authored
Nikolay Aleksandrov says: ==================== net: bridge: convert multicast to generic rhashtable The current bridge multicast code uses a custom rhashtable implementation which predates the generic rhashtable API. Patch 01 converts it to use the generic kernel rhashtable which simplifies the code a lot and removes duplicated functionality. The convert also makes hash_elasticity obsolete as the generic rhashtable already has such checks and has a fixed elasticity of RHT_ELASTICITY (16 currently) so we emit a warning whenever elasticity is set and return RHT_ELASTICITY when read (patch 03). Patch 02 converts the multicast code to use non-bh RCU flavor as it was mixing bh and non-bh. Since now we have the generic rhashtable which autoshrinks we can be more liberal with the default hash maximum so patch 04 increases it to 4096 and moves it to a define in br_private.h. v3: add non-rcu br_mdb_get variant and use it where we have multicast_lock, drop special hash_max handling and just set it where needed and use non-bh RCU consistently (patch 02, new) v2: send the latest version of the set which handles when IGMP snooping is not defined, changes are in patch 01 ==================== Signed-off-by: -
Nikolay Aleksandrov authored
bridge's default hash_max was 512 which is rather conservative, now that we're using the generic rhashtable API which autoshrinks let's increase it to 4096 and move it to a define in br_private.h. Signed-off-by:
-
