- 22 Aug, 2019 12 commits
-
-
huhai authored
When i40e_configure_tx_ring(vsi->tx_rings[i]) returns an error, we should exit from i40e_vsi_configure_tx and return the error, instead of continuing to check whether xdp is enable, and configure the xdp transmit ring. Signed-off-by:
huhai <huhai@kylinos.cn> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Mauro S. M. Rodrigues authored
Similar to the ixgbe issue fixed in: 655c9141 ("ixgbe: Check DDM existence in transceiver before access) i40e has the same issue when reading eeprom from SFP's module that comply with SFF-8472 but not implement the Digital Diagnostic Monitoring (DDM) interface described in it. The existence of such area is specified by bit 6 of byte 92, set to 1 if implemented. Without this patch, due to not checking this bit i40e fails to read SFP module's eeprom with the follow message: ethtool -m enP51p1s0f0 Cannot get Module EEPROM data: Input/output error Because it fails to read the additional 256 bytes in which it was assumed to exist the DDM data. Signed-off-by:
"Mauro S. M. Rodrigues" <maurosr@linux.vnet.ibm.com> Tested-by:
-
Arnd Bergmann authored
The functions i40e_aq_get_phy_abilities_resp() and i40e_set_fc() both have giant structure on the stack, which makes each one use stack frames larger than 500 bytes. As clang decides one function into the other, we get a warning for exceeding the frame size limit on 32-bit architectures: drivers/net/ethernet/intel/i40e/i40e_common.c:1654:23: error: stack frame size of 1116 bytes in function 'i40e_set_fc' [-Werror,-Wframe-larger-than=] When building with gcc, the inlining does not happen, but i40e_set_fc() calls i40e_aq_get_phy_abilities_resp() anyway, so they add up on the kernel stack just as much. The parts that actually use large stacks don't overlap, so make sure each one is a separate function, and mark them as noinline_for_stack to prevent the compilers from combining them again. Fixes: 0a862b43 ("i40e/i40evf: Add module_types and update_link_info") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Tested-by:
-
Colin Ian King authored
Variable err is initialized to a value that is never read and it is re-assigned later. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused Value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Haiyang Zhang says: ==================== Add software backchannel and mlx5e HV VHCA stats This patch set adds paravirtual backchannel in software in pci_hyperv, which is required by the mlx5e driver HV VHCA stats agent. The stats agent is responsible on running a periodic rx/tx packets/bytes stats update. ==================== Signed-off-by: -
Eran Ben Elisha authored
HV VHCA stats agent is responsible on running a preiodic rx/tx packets/bytes stats update. Currently the supported format is version MLX5_HV_VHCA_STATS_VERSION. Block ID 1 is dedicated for statistics data transfer from the VF to the PF. The reporter fetch the statistics data from all opened channels, fill it in a buffer and send it to mlx5_hv_vhca_write_agent. As the stats layer should include some metadata per block (sequence and offset), the HV VHCA layer shall modify the buffer before actually send it over block 1. Signed-off-by:
Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
-
Eran Ben Elisha authored
Control agent is responsible over of the control block (ID 0). It should update the PF via this block about every capability change. In addition, upon block 0 invalidate, it should activate all other supported agents with data requests from the PF. Upon agent create/destroy, the invalidate callback of the control agent is being called in order to update the PF driver about this change. The control agent is an integral part of HV VHCA and will be created and destroy as part of the HV VHCA init/cleanup flow. Signed-off-by:
-
Eran Ben Elisha authored
HV VHCA is a layer which provides PF to VF communication channel based on HyperV PCI config channel. It implements Mellanox's Inter VHCA control communication protocol. The protocol contains control block in order to pass messages between the PF and VF drivers, and data blocks in order to pass actual data. The infrastructure is agent based. Each agent will be responsible of contiguous buffer blocks in the VHCA config space. This infrastructure will bind agents to their blocks, and those agents can only access read/write the buffer blocks assigned to them. Each agent will provide three callbacks (control, invalidate, cleanup). Control will be invoked when block-0 is invalidated with a command that concerns this agent. Invalidate callback will be invoked if one of the blocks assigned to this agent was invalidated. Cleanup will be invoked before the agent is being freed in order to clean all of its open resources or deferred works. Block-0 serves as the control block. All execution commands from the PF will be written by the PF over this block. VF will ack on those by writing on block-0 as well. Its format is described by struct mlx5_hv_vhca_control_block layout. Signed-off-by:
-
Eran Ben Elisha authored
Add wrapper functions for HyperV PCIe read / write / block_invalidate_register operations. This will be used as an infrastructure in the downstream patch for software communication. This will be enabled by default if CONFIG_PCI_HYPERV_INTERFACE is set. Signed-off-by:
-
Haiyang Zhang authored
This interface driver is a helper driver allows other drivers to have a common interface with the Hyper-V PCI frontend driver. Signed-off-by:
-
Dexuan Cui authored
Windows SR-IOV provides a backchannel mechanism in software for communication between a VF driver and a PF driver. These "configuration blocks" are similar in concept to PCI configuration space, but instead of doing reads and writes in 32-bit chunks through a very slow path, packets of up to 128 bytes can be sent or received asynchronously. Nearly every SR-IOV device contains just such a communications channel in hardware, so using this one in software is usually optional. Using the software channel, however, allows driver implementers to leverage software tools that fuzz the communications channel looking for vulnerabilities. The usage model for these packets puts the responsibility for reading or writing on the VF driver. The VF driver sends a read or a write packet, indicating which "block" is being referred to by number. If the PF driver wishes to initiate communication, it can "invalidate" one or more of the first 64 blocks. This invalidation is delivered via a callback supplied by the VF driver by this driver. No protocol is implied, except that supplied by the PF and VF drivers. Signed-off-by:
Jake Oshins <jakeo@microsoft.com> Signed-off-by:
Dexuan Cui <decui@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: K. Y. Srinivasan <kys@microsoft.com> Cc: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5 tc flow handling for concurrent execution (Part 3) This series includes updates to mlx5 ethernet and core driver: Vlad submits part 3 of 3 part series to allow TC flow handling for concurrent execution. Vlad says: ========== Structure mlx5e_neigh_hash_entry code that uses it are refactored in following ways: - Extend neigh_hash_entry with rcu and modify its users to always take reference to the structure when using it (neigh_hash_entry has already had atomic reference counter which was only used when scheduling neigh update on workqueue from atomic context of neigh update netevent). - Always use mlx5e_neigh_update_table->encap_lock when modifying neigh update hash table and list. Originally, this lock was only used to synchronize with netevent handler function, which is called from bh context and cannot use rtnl lock for synchronization. Use rcu read lock instead of encap_lock to lookup nhe in atomic context of netevent even handler function. Convert encap_lock to mutex to allow creating new neigh hash entries while holding it, which is safe to do because the lock is no longer used in atomic context. - Rcu-ify mlx5e_neigh_hash_entry->encap_list by changing operations on encap list to their rcu counterparts and extending encap structure with rcu_head to free the encap instances after rcu grace period. This allows fast traversal of list of encaps attached to nhe under rcu read lock protection. - Take encap_table_lock when accessing encap entries in neigh update and neigh stats update code to protect from concurrent encap entry insertion or removal. This approach leads to potential race condition when neigh update and neigh stats update code can access encap and flow entries that are not fully initialized or are being destroyed, or neigh can change state without updating encaps that are created concurrently. Prevent these issues by following changes in flow and encap initialization: - Extend mlx5e_tc_flow with 'init_done' completion. Modify neigh update to wait for both encap and flow completions to prevent concurrent access to a structure that is being initialized by tc. - Skip structures that failed during initialization: encaps with encap_id<0 and flows that don't have OFFLOADED flag set. - To ensure that no new flows are added to encap when it is being accessed by neigh update or neigh stats update, take encap_table_lock mutex. - To prevent concurrent deletion by tc, ensure that neigh update and neigh stats update hold references to encap and flow instances while using them. With changes presented in this patch set it is now safe to execute tc concurrently with neigh update and neigh stats update. However, these two workqueue tasks modify same flow "tmp_list" field to store flows with reference taken in temporary list to release the references after update operation finishes and should not be executed concurrently with each other. Last 3 patches of this series provide 3 new mlx5 trace points to track mlx5 tc requests and mlx5 neigh updates. ==================== Signed-off-by:
-
- 21 Aug, 2019 28 commits
-
-
Vlad Buslov authored
Allow tracing neigh state during neigh update task that is executed on workqueue and is scheduled by neigh state change event. Usage example: ># cd /sys/kernel/debug/tracing ># echo mlx5:mlx5e_rep_neigh_update >> set_event ># cat trace ... kworker/u48:7-2221 [009] ...1 1475.387435: mlx5e_rep_neigh_update: netdev: ens1f0 MAC: 24:8a:07:9a:17:9a IPv4: 1.1.1.10 IPv6: ::ffff:1.1.1.10 neigh_connected=1 Added corresponding documentation in Documentation/networking/device-driver/mellanox/mlx5.rst Signed-off-by:Vlad Buslov <vladbu@mellanox.com> Reviewed-by:
Dmytro Linkin <dmitrolin@mellanox.com> Signed-off-by:
-
Vlad Buslov authored
Allow tracing result of neigh used value update task that is executed periodically on workqueue. Usage example: ># cd /sys/kernel/debug/tracing ># echo mlx5:mlx5e_tc_update_neigh_used_value >> set_event ># cat trace ... kworker/u48:4-8806 [009] ...1 55117.882428: mlx5e_tc_update_neigh_used_value: netdev: ens1f0 IPv4: 1.1.1.10 IPv6: ::ffff:1.1.1.10 neigh_used=1 Added corresponding documentation in Documentation/networking/device-driver/mellanox/mlx5.rst Signed-off-by: -
Dmytro Linkin authored
Implemented following tracepoints: 1. Configure flower (mlx5e_configure_flower) 2. Delete flower (mlx5e_delete_flower) 3. Stats flower (mlx5e_stats_flower) Usage example: ># cd /sys/kernel/debug/tracing ># echo mlx5:mlx5e_configure_flower >> set_event ># cat trace ... tc-6535 [019] ...1 2672.404466: mlx5e_configure_flower: cookie=0000000067874a55 actions= REDIRECT Added corresponding documentation in Documentation/networking/device-driver/mellanox/mlx5.rst Signed-off-by: -
Vlad Buslov authored
To remove dependency on rtnl lock and prevent neigh update code from accessing uninitialized flows when executing concurrently with tc, extend mlx5e_tc_flow with 'init_done' completion. Modify helper mlx5e_take_all_encap_flows() to wait for flow completion after obtaining reference to it. Modify mlx5e_tc_encap_flows_del() and mlx5e_tc_encap_flows_add() to skip flows that don't have OFFLOADED flag set, which can happen if concurrent flow initialization failed. This commit finishes neigh update refactoring for concurrent execution started in previous change in this series. Signed-off-by:
Roi Dayan <roid@mellanox.com> Signed-off-by:
-
Vlad Buslov authored
In order to remove dependency on rtnl lock and allow neigh update workqueue task to execute concurrently with tc, refactor mlx5e_rep_neigh_update() for concurrent execution: - Lock encap table when accessing encap entry to prevent concurrent changes. To do this properly, the initial encap state check is moved from mlx5e_rep_neigh_update() into mlx5e_rep_update_flows() to be performed under encap_tbl_lock protection. - Wait for encap to be fully initialized before accessing it by means of 'res_ready' completion. - Add mlx5e_take_all_encap_flows() helper which is used to construct a temporary list of flows and efi indexes that is used to access current encap data in flow which can be attached to multiple encaps simultaneously. Release the flows from temporary list after encap_tbl_lock critical section. This is necessary because mlx5e_flow_put() can't be called while holding encap_tbl_lock. - Modify mlx5e_tc_encap_flows_add() and mlx5e_tc_encap_flows_del() to work with user-provided list of flows built by mlx5e_take_all_encap_flows(), instead of traversing encap flow list directly. This is first step in complex neigh update refactoring, which is finished by following commit in this series. Signed-off-by:
-
Vlad Buslov authored
In order to remove dependency on rtnl lock and allow neigh used value update workqueue task to execute concurrently with tc, refactor mlx5e_tc_update_neigh_used_value() for concurrent execution: - Lock encap table when accessing encap entry to prevent concurrent changes. - Save offloaded encap flows to temporary list and release them after encap entry is updated. Add mlx5e_put_encap_flow_list() helper which is intended to be shared with neigh update code in following patch in this series. This is necessary because mlx5e_flow_put() can't be called while holding encap_tbl_lock. Signed-off-by:
-
Vlad Buslov authored
Rcu-ify mlx5e_neigh_hash_entry->encap_list by changing operations on encap list to their rcu counterparts and extending encap structure with rcu_head to free the encap instances after rcu grace period. Use rcu read lock when traversing encap list. Implement helper mlx5e_get_next_valid_encap() function that is used by mlx5e_tc_update_neigh_used_value() to safely iterate over valid entries of nhe->encap_list. Signed-off-by:
Jianbo Liu <jianbol@mellanox.com> Reviewed-by:
-
Vlad Buslov authored
To remove dependency on rtnl lock, always take neigh update encap lock when modifying neigh update hash table and list. Originally, this lock was only used to synchronize with netevent handler function, which is called from bh context and cannot use rtnl lock for synchronization. Take lock in encap entry attach function to prevent concurrent modifications of neigh update hash table and list. Taking the encap lock when creating new nhe introduces a problem that we need to allocate new entry with sleeping GFP_KERNEL flag while holding a spinlock. However, since previous patch in this series has already converted lookup in netevent handler function to user rcu read lock instead of encap lock, we can safely convert the lock type to mutex. Signed-off-by:
-
Vlad Buslov authored
To remove dependency on rtnl lock and to allow unlocked iteration over list of neigh hash entries, extend nhe with rcu. Change operations on neigh list to their rcu counterparts and free neigh hash entry with rcu timeout. Introduce mlx5e_get_next_nhe() helper that is used to iterate over rcu neigh list with reference to nhe taken. Signed-off-by:
-
Vlad Buslov authored
Neigh entry has reference counter, however it is only used when scheduling neigh update event. In all other cases reference to neigh entry is not taken while working with it. Neigh code relies on synchronization provided by rtnl lock and uses encap list size as implicit reference counter. To remove dependency on rtnl lock, always take reference to neigh entry while using it. Remove neigh entry from hash table and delete it only when reference counter reaches zero. This can result spurious neigh update events, when there is an event on entry that has zero encaps attached. However, such events are rare and properly handled by neigh update handler. Extend encap entry with reference to neigh hash entry in order to be able to directly release it when encap is detached, instead of lookup nhe by key through hash table. Extend nhe with reference to device priv structure to guarantee correctness when nhe is used with stack devices, bond setup, in which case it is non-trivial to determine correct device when releasing the nhe. Signed-off-by:
-
Vlad Buslov authored
As a preparation for following refactoring that removes rtnl lock dependency from neigh hash entry handlers, extract code that enqueues neigh update work into standalone function. This commit doesn't change functionality. Signed-off-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
