- 19 Jun, 2019 17 commits
-
-
Jiri Pirko authored
Use previously introduced infra to obtain and store ingress ifindex instead doing it locally. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jiri Pirko authored
Add new key meta that contains ingress ifindex value and add a function to dissect this from skb. The key and function is prepared to cover other potential skb metadata values dissection. Signed-off-by:
-
Colin Ian King authored
Function mlx5_devlink_alloc is missing a void argument, add it to clean up the non-ANSI function declaration. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
David S. Miller authored
Maxime Chevallier says: ==================== net: mvpp2: cls: Allow steering based on vlan tag The PPv2 classifier can perform flow steering based on keys extracted from the VLAN tag. This series adds support for using the vlan id and the vlan prio as keys, using the ethtool interface. Patch 1 is a preparatory patch that prevent false-positive matches, using a dedicated lookup id for the RSS C2 lookup. Patch 2 allows to separate the flows based on the header fields they contain. The main goal is to be able to separate tagged traffic from untagged traffic for flow steering, just as we already do for RSS. Patch 3 solves an issue we have when extracting fields that aren't full bytes, such as the vlan tag which is 12 bits wide, or the priority which is 3 bits wide. Finally, patch 4 adds support for steering based on both vlan id and priority, extracted from the outermost tag. ==================== Signed-off-by: -
Maxime Chevallier authored
This commit allows using the vlan Id and priority as parts of the key for classification offload. These fields are extracted from the outermost tag, if multiple tags are present. Vlan Id and priority are considered as 2 different fields by the classifier, however the fields are both appended in the Header Extracted Key in the same layout as they are found in the tags. This means that when steering only based on the prio, a 16-bit slot is still taken in the HEK. The classifier doesn't allow extracting the DEI bit from the tag, so we explicitly prevent user from using this bit in the key. This commit adds the vlan priotity as a compatible HEK field for tagged traffic, meaning that we limit the possibility of extracting this field only to the flows that contain tagged traffic. Signed-off-by:
Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by:
-
Maxime Chevallier authored
The C2 TCAM used for classification uses a key (Header Extracted Key) built by concatenating several fields extracted from the packet header. After a lot of trial-and-error and some guess work, it seems the HEK is right justified, with the first fields being stored in the MSB, then concatenated up until the LSB. Until now, this doesn't cause any issue since all HEK fields we use are full bytes. However this is an issue for the upcoming VLAN id and pri extraction, which aren't full bytes. Rework the way we built that TCAM key, by changing the order in which we append the fields. Signed-off-by:
-
Maxime Chevallier authored
The way we currently handle classification offload and RSS is by having dedicated lookup sequences in the flow table, each being selected depending on several fields being present in the packet header. We need to make sure the classification operation we want to perform can be done in each flow we want to insert it into. As an example, classifying on VLAN tag can only be done on flows used for tagged traffic. This commit makes sure we don't insert rules in flows we aren't compatible with. Signed-off-by:
-
Maxime Chevallier authored
When performing a TCAM lookup in the C2 engine, it's possible that multiple entries match the packet. To make sure the correct entry match when performing a lookup, the Flow Table can set a lookup type, which will be used in the TCAM lookup, thus preventing such false-positives. We need to make sure the RSS match doesn't interfere with other classification lookups, hence we use a dedicated lookup_type for it. Signed-off-by:
-
David S. Miller authored
Yash Shah says: ==================== Add macb support for SiFive FU540-C000 On FU540, the management IP block is tightly coupled with the Cadence MACB IP block. It manages many of the boundary signals from the MACB IP This patchset controls the tx_clk input signal to the MACB IP. It switches between the local TX clock (125MHz) and PHY TX clocks. This is necessary to toggle between 1Gb and 100/10Mb speeds. Future patches may add support for monitoring or controlling other IP boundary signals. This patchset is mostly based on work done by Wesley Terpstra <wesley@sifive.com> This patchset is based on Linux v5.2-rc1 and tested on HiFive Unleashed board with additional board related patches needed for testing can be found at dev/yashs/ethernet_v3 branch of: https://github.com/yashshah7/riscv-linux.git Change History: V3: - Revert "MACB_SIFIVE_FU540" config changes in Kconfig and driver code. The driver does not depend on SiFive GPIO driver. V2: - Change compatible string from "cdns,fu540-macb" to "sifive,fu540-macb" - Add "MACB_SIFIVE_FU540" in Kconfig to support SiFive FU540 in macb driver. This is needed because on FU540, the macb driver depends on SiFive GPIO driver. - Avoid writing the result of a comparison to a register. - Fix the issue of probe fail on reloading the module reported by: Andreas Schwab <schwab@suse.de> ==================== Signed-off-by:
-
Yash Shah authored
The management IP block is tightly coupled with the Cadence MACB IP block on the FU540, and manages many of the boundary signals from the MACB IP. This patch only controls the tx_clk input signal to the MACB IP. Future patches may add support for monitoring or controlling other IP boundary signals. Signed-off-by:
Yash Shah <yash.shah@sifive.com> Signed-off-by:
-
Yash Shah authored
Add the compatibility string documentation for SiFive FU540-C0000 interface. On the FU540, this driver also needs to read and write registers in a management IP block that monitors or drives boundary signals for the GEMGXL IP block that are not directly mapped to GEMGXL registers. Therefore, add additional range to "reg" property for SiFive GEMGXL management IP registers. Signed-off-by:
Paul Walmsley <paul.walmsley@sifive.com> Signed-off-by:
-
David S. Miller authored
Xue Chaojing says: ==================== hinic: add rss support and rss parameters configuration This series add rss support for HINIC driver and implement the ethtool interface related to rss parameter configuration. user can use ethtool configure rss parameters or show rss parameters. ==================== Signed-off-by: -
Xue Chaojing authored
This patch adds support rss parameters with ethtool, user can change hash key, hash indirection table, hash function by ethtool -X, and show rss parameters by ethtool -x. Signed-off-by:
Xue Chaojing <xuechaojing@huawei.com> Signed-off-by:
-
Xue Chaojing authored
This patch moves ethtool code from hinic_main.c to hinic_ethtool.c Signed-off-by:
-
Xue Chaojing authored
This patch adds rss support for the HINIC driver. Signed-off-by:
-
Colin Ian King authored
Currently the call to device_property_read_u32_array is not error checked leading to potential garbage values in the delays array that are then used in msleep delays. Add a sanity check to the property fetching. Addresses-Coverity: ("Uninitialized scalar variable") Signed-off-by: -
Geert Uytterhoeven authored
"git diff" says: \ No newline at end of file after modifying the file. Signed-off-by:Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
- 18 Jun, 2019 23 commits
-
-
Arnd Bergmann authored
A previous attempt to shut up the uninitialized variable use warning was apparently insufficient. When CONFIG_PROFILE_ANNOTATED_BRANCHES is set, gcc-8 still warns, because the unlikely() check in DP_NOTICE() causes it to no longer track the state of all variables correctly: drivers/net/ethernet/qlogic/qed/qed_dev.c: In function 'qed_llh_set_ppfid_affinity': drivers/net/ethernet/qlogic/qed/qed_dev.c:798:47: error: 'abs_ppfid' may be used uninitialized in this function [-Werror=maybe-uninitialized] addr = NIG_REG_PPF_TO_ENGINE_SEL + abs_ppfid * 0x4; ~~~~~~~~~~^~~~~ This is not a nice workaround, but always initializing the output from qed_llh_abs_ppfid() at least shuts up the false positive reliably. Fixes: 79284ade ("qed: Add llh ppfid interface and 100g support for offload protocols") Fixes: 8e2ea3ea ("qed: Fix static checker warning") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Acked-by: Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by:
-
Geert Uytterhoeven authored
Flexible array members should be denoted using [] instead of [0], else gcc will not warn when they are no longer at the end of a struct. Signed-off-by:
-
Denis Kirjanov authored
in IPoIB case we can't see a VF broadcast address for but can see for PF Before: 11: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast state UP mode DEFAULT group default qlen 256 link/infiniband 80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff vf 0 MAC 14:80:00:00:66:fe, spoof checking off, link-state disable, trust off, query_rss off ... After: 11: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast state UP mode DEFAULT group default qlen 256 link/infiniband 80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff vf 0 link/infiniband 80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff, spoof checking off, link-state disable, trust off, query_rss off v1->v2: add the IFLA_VF_BROADCAST constant v2->v3: put IFLA_VF_BROADCAST at the end to avoid KABI breakage and set NLA_REJECT dev_setlink Signed-off-by:Denis Kirjanov <kda@linux-powerpc.org> Acked-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Denis Kirjanov authored
in the case of IPoIB with SRIOV enabled hardware ip link show command incorrecly prints 0 instead of a VF hardware address. Before: 11: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast state UP mode DEFAULT group default qlen 256 link/infiniband 80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff vf 0 MAC 00:00:00:00:00:00, spoof checking off, link-state disable, trust off, query_rss off ... After: 11: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast state UP mode DEFAULT group default qlen 256 link/infiniband 80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff vf 0 link/infiniband 80:00:00:66:fe:80:00:00:00:00:00:00:24:8a:07:03:00:a4:3e:7c brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff, spoof checking off, link-state disable, trust off, query_rss off v1->v2: just copy an address without modifing ifla_vf_mac v2->v3: update the changelog Signed-off-by: -
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Improve IPv6 route insertion rate Unlike IPv4, an IPv6 multipath route in the kernel is composed from multiple sibling routes, each representing a single nexthop. Therefore, an addition of a multipath route with N nexthops translates to N in-kernel notifications. This is inefficient for device drivers that need to program the route to the underlying device. Each time a new nexthop is appended, a new nexthop group needs to be constructed and the old one deleted. This patchset improves the situation by sending a single notification for a multipath route addition / deletion instead of one per-nexthop. When adding thousands of multipath routes with 16 nexthops, I measured an improvement of about x10 in the insertion rate. Patches #1-#3 add a flag that indicates that in-kernel notifications need to be suppressed and extend the IPv6 FIB notification info with information about the number of sibling routes that are being notified. Patches #4-#5 adjust the two current listeners to these notifications to ignore notifications about IPv6 multipath routes. Patches #6-#7 adds add / delete notifications for IPv6 multipath routes. Patches #8-#14 do the same for mlxsw. Patch #15 finally removes the limitations added in patches #4-#5 and stops the kernel from sending a notification for each added / deleted nexthop. Patch #16 adds test cases. v2 (David Ahern): * Remove patch adjusting netdevsim to consume resources for each fib6_info. Instead, consume one resource for the entire multipath route * Remove 'multipath_rt' usage in patch #10 * Remove 'multipath_rt' from 'struct fib6_entry_notifier_info' in patch #15. The member is only removed in this patch to prevent drivers from processing multipath routes twice during the series ==================== Signed-off-by: -
Ido Schimmel authored
Test that the offload indication for unicast routes is correctly set in different scenarios. IPv4 support will be added in the future. Signed-off-by:
-
Ido Schimmel authored
Both listeners - mlxsw and netdevsim - of IPv6 FIB notifications are now ready to handle IPv6 multipath notifications. Therefore, stop ignoring such notifications in both drivers and stop sending notification for each added / deleted nexthop. v2: * Remove 'multipath_rt' from 'struct fib6_entry_notifier_info' Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Ido Schimmel authored
Allow the driver to create an IPv6 multipath route in one go by passing an array of sibling routes and iterating over them. Signed-off-by:
-
Ido Schimmel authored
Currently, the functions that take care of populating IPv6 nexthop groups only add / delete a single nexthop. Prepare them to handle multiple routes in one notification by passing an array of routes and adding / deleting all of them. Signed-off-by:
-
Ido Schimmel authored
Prepare the driver to handle multiple routes in a single notification by passing an array of routes to the functions that actually add / delete a route. Signed-off-by:
-
Ido Schimmel authored
Previously, IPv6 replace notifications were only sent from fib6_add_rt2node(). The function only emitted such notifications if a route actually replaced another route. A previous patch added another call site in ip6_route_multipath_add() from which such notification can be emitted even if a route was merely added and did not replace another route. Adjust the driver to take this into account and potentially set the 'replace' flag to 'false' if the notified route did not replace an existing route. Signed-off-by:
-
Ido Schimmel authored
Prepare the driver to process IPv6 multipath notifications by passing an array of 'struct fib6_info' instead of just one route. A reference is taken on each sibling route in order to prevent them from being freed until they are processed by the workqueue. v2: * Remove 'multipath_rt' usage Signed-off-by:
-
Ido Schimmel authored
The function mlxsw_sp_router_fib6_event() takes care of preparing the needed information for the work item that actually inserts the route into the device. When processing an IPv6 multipath route, the function will need to allocate an array to store pointers to all the sibling routes. Change the function's signature to return an error code and adjust the single call site. Signed-off-by:
-
Ido Schimmel authored
No such notifications are sent by the IPv6 code, so remove them. Signed-off-by:
-
Ido Schimmel authored
If all the nexthops of a multipath route are being deleted, send one notification for the entire route, instead of one per-nexthop. Signed-off-by:
-
Ido Schimmel authored
Emit a notification when a multipath routes is added or replace. Note that unlike the replace notifications sent from fib6_add_rt2node(), it is possible we are sending a 'FIB_EVENT_ENTRY_REPLACE' when a route was merely added and not replaced. Signed-off-by:
-
Ido Schimmel authored
In a similar fashion to previous patch, have netdevsim ignore IPv6 multipath notifications for now. Signed-off-by:
-
Ido Schimmel authored
IPv6 multipath notifications are about to be sent, but mlxsw is not ready to process them, so ignore them. The limitation will be lifted by a subsequent patch which will also stop the kernel from sending a notification for each nexthop. Signed-off-by:
-
Ido Schimmel authored
Extend the IPv6 FIB notifier info with number of sibling routes being notified. This will later allow listeners to process one notification for a multipath routes instead of N, where N is the number of nexthops. Signed-off-by:
-
Ido Schimmel authored
The struct includes a 'skip_notify' flag that indicates if netlink notifications to user space should be suppressed. As explained in commit 3b1137fe ("net: ipv6: Change notifications for multipath add to RTA_MULTIPATH"), this is useful to suppress per-nexthop RTM_NEWROUTE notifications when an IPv6 multipath route is added / deleted. Instead, one notification is sent for the entire multipath route. This concept is also useful for in-kernel notifications. Sending one in-kernel notification for the addition / deletion of an IPv6 multipath route - instead of one per-nexthop - provides a significant increase in the insertion / deletion rate to underlying devices. Add a 'skip_notify_kernel' flag to suppress in-kernel notifications. Signed-off-by:
-
Ido Schimmel authored
Some fields were not documented. Add documentation. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== Intel Wired LAN Driver Updates 2019-06-17 This series contains updates to the iavf driver only. Akeem updates the driver to change how VLAN tags are being populated and programmed into the hardware by starting from the first member of the list until the number of allowed VLAN tags is exhausted. Mitch fixed the variable type since the variable counter starts out negative and climbs to zero, so use a signed integer instead of unsigned. Also increase the timeout to avoid erroneous errors. Fixed the driver to be able to handle when the hardware hands us a null receive descriptor with no data attached, yet is still valid. Aleksandr fixes the driver to use GFP_ATOMIC when allocating memory in atomic context. Avinash updates the driver to fix a calculation error in virtchnl regarding the valid length. Jakub does some refactoring of the commands processing the watchdog state machine to reduce the length and complexity of the function. Also decalre watchdog task as delayed work and use a dedicated work queue to service the driver tasks. Paul updated the iavf_process_aq_command to call the necessary functions to be able to clear cloud filter bits that need to be cleared. ==================== Signed-off-by: -
Shalom Toledo authored
Compilation on 32-bit ARM fails after commit 992aa864 ("mlxsw: spectrum_ptp: Add implementation for physical hardware clock operations") because of 64-bit division: arm-linux-gnueabi-ld: drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.o: in function `mlxsw_sp1_ptp_phc_settime': spectrum_ptp.c:(.text+0x39c): undefined reference to `__aeabi_uldivmod' Fix by using div_u64(). Fixes: 992aa864 ("mlxsw: spectrum_ptp: Add implementation for physical hardware clock operations") Signed-off-by:
Shalom Toledo <shalomt@mellanox.com> Reviewed-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
