38b9e0f6d9
This series includes update to mlx5 ethernet and core driver: In first #11 patches, Vlad submits part 2 of 3 part series to allow TC flow handling for concurrent execution. 1) TC flow handling for concurrent execution (part 2) Vald Says: ========== Refactor data structures that are shared between flows in tc. Currently, all cls API hardware offloads driver callbacks require caller to hold rtnl lock when calling them. Cls API has already been updated to update software filters in parallel (on classifiers that support unlocked execution), however hardware offloads code still obtains rtnl lock before calling driver tc callbacks. This set implements support for unlocked execution of tc hairpin, mod_hdr and encap subsystem. The changed implemented in these subsystems are very similar in general. The main difference is that hairpin is accessed through mlx5e_tc_table (legacy mode), mod_hdr is accessed through both mlx5e_tc_table and mlx5_esw_offload (legacy and switchdev modes) and encap is only accessed through mlx5_esw_offload (switchdev mode). 1.1) Hairpin handling and structure mlx5e_hairpin_entry refactored in following way: - Hairpin structure is extended with atomic reference counter. This approach allows to lookup of hairpin entry and obtain reference to it with hairpin_tbl_lock protection and then continue using the entry unlocked (including provisioning to hardware). - To support unlocked provisioning of hairpin entry to hardware, the entry is extended with 'res_ready' completion and is inserted to hairpin_tbl before calling the firmware. With this approach any concurrent users that attempt to use the same hairpin entry wait for completion first to prevent access to entries that are not fully initialized. - Hairpin entry is extended with new flows_lock spinlock to protect the list when multiple concurrent tc instances update flows attached to the same hairpin entry. 1.2) Modify header handling code and structure mlx5e_mod_hdr_entry are refactored in the following way: - Mod_hdr structure is extended with atomic reference counter. This approach allows to lookup of mod_hdr entry and obtain reference to it with mod_hdr_tbl_lock protection and then continue using the entry unlocked (including provisioning to hardware). - To support unlocked provisioning of mod_hdr entry to hardware, the entry is extended with 'res_ready' completion and is inserted to mod_hdr_tbl before calling the firmware. With this approach any concurrent users that attempt to use the same mod_hdr entry wait for completion first to prevent access to entries that are not fully initialized. - Mod_Hdr entry is extended with new flows_lock spinlock to protect the list when multiple concurrent tc instances update flows attached to the same mod_hdr entry. 1.3) Encapsulation handling code and Structure mlx5e_encap_entry are refactored in the following way: - encap structure is extended with atomic reference counter. This approach allows to lookup of encap entry and obtain reference to it with encap_tbl_lock protection and then continue using the entry unlocked (including provisioning to hardware). - To support unlocked provisioning of encap entry to hardware, the entry is extended with 'res_ready' completion and is inserted to encap_tbl before calling the firmware. With this approach any concurrent users that attempt to use the same encap entry wait for completion first to prevent access to entries that are not fully initialized. - As a difference from approach used to refactor hairpin and mod_hdr, encap entry is not extended with any per-entry fine-grained lock. Instead, encap_table_lock is used to synchronize all operations on encap table and instances of mlx5e_encap_entry. This is necessary because single flow can be attached to multiple encap entries simultaneously. During new flow creation or neigh update event all of encaps that flow is attached to must be accessed together as in atomic manner, which makes usage of per-entry lock infeasible. - Encap entry is extended with new flows_lock spinlock to protect the list when multiple concurrent tc instances update flows attached to the same encap entry. ========== 3) Parav improves the way port representors report their parent ID and port index. 4) Use refcount_t for refcount in vxlan data base from Chuhong Yuan -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEGhZs6bAKwk/OTgTpSD+KveBX+j4FAl1N64MACgkQSD+KveBX +j4iZAf/cXbX7B6QamcslzKR0HXUWeFBxj+6xrohlB4g4jAr62FbcNWbNyho26Fy ePZB5J2P2yujR7a7aDpGwPUFw42kRzmg0uvKVGW95459hVwx7fXaOWX8b9qfF9DK KJdvxw5s/b92qFMXUp/0mUGOD7Md0Q1Dy07rL0T6mgQGp9iKfennhtgGPBjtEkec Y8BLtRB4ZX3X16sSEj0Zm3h7IojqXT/0mqqKXoXM2N+kGTmXWAcCTeFdAUh31BMf ddlgEJu9t2OtLjg0iVKiUKE4r52LjdlJTsnRM0SkkUPSzS/+vI8iUUgF8X/XoqNG PtncRsSOGiWl2EU2Tb4m5v3obIanfA== =HzrJ -----END PGP SIGNATURE----- Merge tag 'mlx5-updates-2019-08-09' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== mlx5-updates-2019-08-09 This series includes update to mlx5 ethernet and core driver: In first #11 patches, Vlad submits part 2 of 3 part series to allow TC flow handling for concurrent execution. 1) TC flow handling for concurrent execution (part 2) Vald Says: ========== Refactor data structures that are shared between flows in tc. Currently, all cls API hardware offloads driver callbacks require caller to hold rtnl lock when calling them. Cls API has already been updated to update software filters in parallel (on classifiers that support unlocked execution), however hardware offloads code still obtains rtnl lock before calling driver tc callbacks. This set implements support for unlocked execution of tc hairpin, mod_hdr and encap subsystem. The changed implemented in these subsystems are very similar in general. The main difference is that hairpin is accessed through mlx5e_tc_table (legacy mode), mod_hdr is accessed through both mlx5e_tc_table and mlx5_esw_offload (legacy and switchdev modes) and encap is only accessed through mlx5_esw_offload (switchdev mode). 1.1) Hairpin handling and structure mlx5e_hairpin_entry refactored in following way: - Hairpin structure is extended with atomic reference counter. This approach allows to lookup of hairpin entry and obtain reference to it with hairpin_tbl_lock protection and then continue using the entry unlocked (including provisioning to hardware). - To support unlocked provisioning of hairpin entry to hardware, the entry is extended with 'res_ready' completion and is inserted to hairpin_tbl before calling the firmware. With this approach any concurrent users that attempt to use the same hairpin entry wait for completion first to prevent access to entries that are not fully initialized. - Hairpin entry is extended with new flows_lock spinlock to protect the list when multiple concurrent tc instances update flows attached to the same hairpin entry. 1.2) Modify header handling code and structure mlx5e_mod_hdr_entry are refactored in the following way: - Mod_hdr structure is extended with atomic reference counter. This approach allows to lookup of mod_hdr entry and obtain reference to it with mod_hdr_tbl_lock protection and then continue using the entry unlocked (including provisioning to hardware). - To support unlocked provisioning of mod_hdr entry to hardware, the entry is extended with 'res_ready' completion and is inserted to mod_hdr_tbl before calling the firmware. With this approach any concurrent users that attempt to use the same mod_hdr entry wait for completion first to prevent access to entries that are not fully initialized. - Mod_Hdr entry is extended with new flows_lock spinlock to protect the list when multiple concurrent tc instances update flows attached to the same mod_hdr entry. 1.3) Encapsulation handling code and Structure mlx5e_encap_entry are refactored in the following way: - encap structure is extended with atomic reference counter. This approach allows to lookup of encap entry and obtain reference to it with encap_tbl_lock protection and then continue using the entry unlocked (including provisioning to hardware). - To support unlocked provisioning of encap entry to hardware, the entry is extended with 'res_ready' completion and is inserted to encap_tbl before calling the firmware. With this approach any concurrent users that attempt to use the same encap entry wait for completion first to prevent access to entries that are not fully initialized. - As a difference from approach used to refactor hairpin and mod_hdr, encap entry is not extended with any per-entry fine-grained lock. Instead, encap_table_lock is used to synchronize all operations on encap table and instances of mlx5e_encap_entry. This is necessary because single flow can be attached to multiple encap entries simultaneously. During new flow creation or neigh update event all of encaps that flow is attached to must be accessed together as in atomic manner, which makes usage of per-entry lock infeasible. - Encap entry is extended with new flows_lock spinlock to protect the list when multiple concurrent tc instances update flows attached to the same encap entry. ========== 3) Parav improves the way port representors report their parent ID and port index. 4) Use refcount_t for refcount in vxlan data base from Chuhong Yuan ==================== Signed-off-by: David S. Miller <davem@davemloft.net> |
||
|---|---|---|
| Documentation | ||
| LICENSES | ||
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| drivers | ||
| fs | ||
| include | ||
| init | ||
| ipc | ||
| kernel | ||
| lib | ||
| mm | ||
| net | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .clang-format | ||
| .cocciconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
README
Linux kernel
============
There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.
In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``. The formatted documentation can also be read online at:
https://www.kernel.org/doc/html/latest/
There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.
Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.