- 02 Jul, 2019 18 commits
-
-
Yunsheng Lin authored
When user has configured a large number of virtual netdev, such as 4K vlans, the carrier on/off operation of the real netdev will also cause it's virtual netdev's link state to be processed in linkwatch. Currently, the processing is done in a work queue, which may cause rtnl locking starvation problem and worker starvation problem for other work queue, such as irqfd_inject wq. This patch releases the cpu when link watch worker has processed a fixed number of netdev' link watch event, and schedule the work queue again when there is still link watch event remaining. Signed-off-by:
Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: PTP timestamping support This is the second patchset adding PTP support in mlxsw. Next patchset will add PTP shapers which are required to maintain accuracy under rates lower than 40Gb/s, while subsequent patchsets will add tracepoints and selftests. Petr says: This patch set introduces support for retrieving and processing hardware timestamps for PTP packets. The way PTP timestamping works on Spectrum-1 is that there are two queues associated with each front panel port. When a packet is timestamped, the timestamp is put to one of the queues: timestamps for transmitted packets to one and for received packets to the other. Activity on these queues is signaled through the events PTP_ING_FIFO and PTP_EGR_FIFO. Packets themselves arrive through two traps: PTP0 and PTP1. It is possible to configure which PTP messages should be trapped under which PTP trap. On Spectrum systems, mlxsw will use PTP0 for event messages (which need timestamping), and PTP1 for general messages (which do not). There are therefore four relevant traps: receive of PTP event resp. general message, and receive of timestamp for a transmitted resp. received PTP packet. The obvious point where to put the new logic is a custom listener to the mentioned traps. Besides handling ingress traffic (be in packets or timestamps), the driver also needs to handle timestamping of transmitted packets. One option would be to invoke the relevant logic from mlxsw_core_ptp_transmitted(). However on Spectrum-2, the timestamps are actually delivered through the completion queue, and for that reason this patchset opts to invoke the logic from the PCI code, via core and the driver, to a chip-specific operation. That way the invocation will be done in a place where a Spectrum-2 implementation will have an opportunity to extract the timestamp. As indicated above, the PTP FIFO signaling happens independently from packet delivery. A packet corresponding to any given timestamp could be delivered sooner or later than the timestamp itself. Additionally, the queues are only four elements deep, and it is therefore possible that the timestamp for a delivered packet never arrives at all. Similarly a PTP packet might be dropped due to CPU traffic pressure, and never be delivered even if the corresponding timestamp was. The driver thus needs to hold a cache of as-yet-unmatched SKBs and timestamps. The first piece to arrive (be it timestamp or SKB) is put to this cache. When the other piece arrives, the timestamp is attached to the SKB and that is passed on. A delayed work is run at regular intervals to prune the old unmatched entries. As mentioned above, the mechanism for timestamp delivery changes on Spectrum-2, where timestamps are part of completion queue elements, and all packets are timestamped. All this bookkeeping is therefore unnecessary on Spectrum-2. For this reason, this patchset spends some time introducing Spectrum-1 specific artifacts such as a possibility to register a given trap only on Spectrum-1. Patches #1-#4 describe new registers. Patches #5 and #6 introduce the possibility to register certain traps only on some systems. The list of Spectrum-1 specific traps is left empty at this point. Patch #7 hooks into packet receive path by registering PTP traps and appropriate handlers (that however do nothing of substance yet). Patch #8 adds a helper to allow storing custom data to SKB->cb. Patch #9 adds a call into the PCI completion queue handler that invokes, via core and spectrum code, a PTP transmit handler. (Which also does not do anything interesting yet.) Patch #10 introduces code to invoke PTP initialization and adds data types for the cache of unmatched entries. Patches #11 and #12 implement the timestamping itself. In #11, the PHC spin_locks are converted to _bh variants, because unlike normal PHC path, which runs in process context, timestamp processing runs as soft interrupt. Then #12 introduces the code for saving and retrieval of unmatched entries, invokes PTP classifier to identify packets of interest, registers timestamp FIFO events, and handles decoding and attaching timestamps to packets. Patch #13 introduces a garbage collector for left-behind entries that have not been matched for about a second. In patch #14, PTP message types are configured to arrive as PTP0 (events) or PTP1 (everything else) as appropriate. At this point, the PTP packets start arriving through the traps, but because PTP is disabled and there is no way to enable it yet, they are always just passed to the usual receive path right away. Finally patches #15 and #16 add the plumbing to actually make it possible to enable this code through SIOCSHWTSTAMP ioctl, and to advertise the hardware timestamping capabilities through ethtool. v2: - Patch #12: - In mlxsw_sp1_ptp_fifo_event_func(), post-increment when iterating over PTP FIFO records. - Patch #14: - Change namespace of message type enumerators from MLXSW_ to MLXSW_SP_. ==================== Signed-off-by: -
Petr Machata authored
The get_ts_info callback is used for obtaining information about timestamping capabilities of a network device. On Spectrum-1, implement it to advertise the PHC and the capability to do HW timestamping, and the supported RX and TX filters. Signed-off-by:
Petr Machata <petrm@mellanox.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Petr Machata authored
The SIOCSHWTSTAMP ioctl configures HW timestamping on a given port. Dispatch the ioctls to per-chip handler (which add to ptp_ops). Find which PTP messages need to be timestamped and configure MTPPPC accordingly. The SIOCGHWTSTAMP ioctl is getter for the current configuration. Signed-off-by:
-
Petr Machata authored
Configure MTPTPT to set which message types should arrive under which PTP trap, and MOGCR to clear the timestamp queue after its contents are reported through PTP_ING_FIFO or PTP_EGR_FIFO. With this configuration, PTP packets start arriving through the PTP traps. However since timestamping is disabled by default and there is currently no way to enable it, they will not be timestamped. Signed-off-by:
-
Petr Machata authored
On Spectrum-1, timestamped PTP packets and the corresponding timestamps need to be kept in caches until both are available, at which point they are matched up and packets forwarded as appropriate. However, not all packets will ever see their timestamp, and not all timestamps will ever see their packet. It is therefore necessary to dispose of such abandoned entries. To that end, introduce a garbage collector to collect entries that have not had their counterpart turn up within about a second. The GC maintains a monotonously-increasing value of GC cycle. Every entry that is put to the hash table is annotated with the GC cycle at which it should be collected. When the GC runs, it walks the hash table, and collects the objects according to their GC cycle annotation. Signed-off-by:
-
Petr Machata authored
On Spectrum-1, timestamps arrive through a pair of dedicated events: MLXSW_TRAP_ID_PTP_ING_FIFO and _EGR_FIFO. The payload delivered with those traps is contents of the timestamp FIFO at a given port in a given direction. Add a Spectrum-1-specific handler for these two events which decodes the timestamps and forwards them to the PTP module. Add a function that parses a packet, dispatching to ptp_classify_raw(), and decodes PTP message type, domain number, and sequence ID. Add a new mlxsw dependency on the PTP classifier. Add helpers that can store and retrieve unmatched timestamps and SKBs to the hash table added in a preceding patch. Add the matching code itself: upon arrival of a timestamp or a packet, look up the corresponding unmatched entry, and match it up. If there is none, add a new unmatched entry. This logic is the same on ingress as on egress. Packets and timestamps that never matched need to be eventually disposed of. A garbage collector added in a follow-up patch will take care of that. Since currently all this code is turned off, no crud will accumulate in the hash table. Signed-off-by:
-
Petr Machata authored
Up until now, the PTP hardware clock code was only invoked in the process context (SYS_clock_adjtime -> do_clock_adjtime -> k_clock::clock_adj -> pc_clock_adjtime -> posix_clock_operations::clock_adjtime -> ptp_clock_info::adjtime -> mlxsw_spectrum). In order to enable HW timestamping, which is tied into trap handling, it will be necessary to take the clock lock from the PCI queue handler tasklets as well. Therefore use the _bh variants when handling the clock lock. Incidentally, Documentation/ptp/ptp.txt recommends _irqsave variants, but that's unnecessarily strong for our needs. Signed-off-by:
-
Petr Machata authored
Add two ptp_ops: init and fini, to initialize and finalize the PTP subsystem. Call as appropriate from mlxsw_sp_init() and _fini(). Lay the groundwork for Spectrum-1 support. On Spectrum-1, the received timestamped packets and their corresponding timestamps arrive independently, and need to be matched up. Introduce the related data types and add to struct mlxsw_sp_ptp_state the hash table that will keep the unmatched entries. Signed-off-by:
-
Petr Machata authored
On Spectrum-1, timestamps are delivered separately from the packets, and need to paired up. Therefore, at some point after mlxsw_sp_port_xmit() is invoked, it is necessary to involve the chip-specific driver code to allow it to do the necessary bookkeeping and matching. On Spectrum-2, timestamps are delivered in CQE. For that reason, position the point of driver involvement into mlxsw_pci_cqe_sdq_handle() to make it hopefully easier to extend for Spectrum-2 in the future. To tell the driver what port the packet was sent on, keep tx_info in SKB control buffer. Introduce a new driver core interface mlxsw_core_ptp_transmitted(), a driver callback ptp_transmitted, and a PTP op transmitted. The callee is responsible for taking care of releasing the SKB passed to the new interfaces, and correspondingly have the new stub callbacks just call dev_kfree_skb_any(). Follow-up patches will introduce the actual content into mlxsw_sp1_ptp_transmitted() in particular. Signed-off-by:
-
Petr Machata authored
The SKB control buffer is useful (and used) for bookkeeping of information related to that SKB. Add helpers so that the mlxsw driver(s) can safely use the buffer as well. The structure is currently empty, individual users will add members to it as necessary. Note that SKB allocation functions already clear the buffer, so the cleanup is only necessary when ndo_start_xmit is called. Signed-off-by:
-
Petr Machata authored
When configured, the Spectrum hardware can recognize PTP packets and trap them to the CPU using dedicated traps, PTP0 and PTP1. One reason to get PTP packets under dedicated traps is to have a separate policer suitable for the amount of PTP traffic expected when switch is operated as a boundary clock. For this, add two new trap groups, MLXSW_REG_HTGT_TRAP_GROUP_SP_PTP0 and _PTP1, and associate the two PTP traps with these two groups. In the driver, specifically for Spectrum-1, event PTP packets will need to be paired up with their timestamps. Those arrive through a different set of traps, added later in the patch set. To support this future use, introduce a new PTP op, ptp_receive. It is possible to configure which PTP messages should be trapped under which PTP trap. On Spectrum systems, we will use PTP0 for event packets (which need timestamping), and PTP1 for control packets (which do not). Thus configure PTP0 trap with a custom callback that defers to the ptp_receive op. Additionally, L2 PTP packets are actually trapped through the LLDP trap, not through any of the PTP traps. So treat the LLDP trap the same way as the PTP0 trap. Unlike PTP traps, which are currently still disabled, LLDP trap is active. Correspondingly, have all the implementations of the ptp_receive op return true, which the handler treats as a signal to forward the packet immediately. Signed-off-by:
-
Petr Machata authored
On Spectrum-1, timestamps for PTP packets are delivered through queues of ingress and egress timestamps. There are two event traps corresponding to activity on each of those queues. This mechanism is absent on Spectrum-2, and therefore the traps should only be registered on Spectrum-1. Carry a chip-specific listener array in mlxsw_sp->listeners and listeners_count. Register listeners from that array in mlxsw_sp_traps_init(). Add a new listener array for Spectrum-1 traps and configure the newly-added mlxsw_sp->listeners with this array. The listener array is empty for now, the events will be added in a later patch. Signed-off-by:
-
Petr Machata authored
On Spectrum-1, timestamps for PTP packets are delivered through queues of ingress and egress timestamps. There are two event traps corresponding to activity on each of those queues. This mechanism is absent on Spectrum-2, and therefore the traps should only be registered on Spectrum-1. Extract out of mlxsw_sp_traps_init() a generic helper, mlxsw_sp_traps_register(), and likewise with _unregister(). The new helpers will later be called with Spectrum-1-specific traps. Signed-off-by:
-
Petr Machata authored
This register serves to configure global parameters of certain monitoring operations. The following patches will use it to configure that when PTP timestamps are delivered through the PTP FIFO traps, the FIFO in question is cleared as well. Signed-off-by:
-
Petr Machata authored
The MTPPTR is used for reading the per port PTP timestamp FIFO. Signed-off-by:
-
Petr Machata authored
This register is used for configuring under which trap to deliver PTP packets depending on type of the packet. Signed-off-by:
-
Petr Machata authored
This register serves for configuration of which PTP messages should be timestamped. This is a global configuration, despite the register name. Signed-off-by:
-
- 01 Jul, 2019 4 commits
-
-
Daniel T. Lee authored
Currently, kernel pktgen has the feature to specify udp destination port for sending packet. (e.g. pgset "udp_dst_min 9") But on samples, each of the scripts doesn't have any option to achieve this. This commit adds the DST_PORT option to specify the target port(s) in the script. -p : ($DST_PORT) destination PORT range (e.g. 433-444) is also allowed Signed-off-by:Daniel T. Lee <danieltimlee@gmail.com> Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
-
Daniel T. Lee authored
This commit adds port parsing and port validate helper function to parse single or range of port(s) from a given string. (e.g. 1234, 443-444) Helpers will be used in prior to set target port(s) in samples/pktgen. Signed-off-by:
-
Eric Dumazet authored
Extend flowlabel_reflect bitmask to allow conditional reflection of incoming flowlabels in echo replies. Note this has precedence against auto flowlabels. Add flowlabel_reflect enum to replace hard coded values. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5e-updates-2019-06-28 This series adds some misc updates for mlx5e driver 1) Allow adding the same mac more than once in MPFS table 2) Move to HW checksumming advertising 3) Report netdevice MPLS features 4) Correct physical port name of the PF representor 5) Reduce stack usage in mlx5_eswitch_termtbl_create 6) Refresh TIR improvement for representors 7) Expose same physical switch_id for all representors ==================== Signed-off-by:
-
- 30 Jun, 2019 1 commit
-
-
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-28 This series contains a smorgasbord of updates to many of the Intel drivers. Gustavo A. R. Silva updates the ice and iavf drivers to use the strcut_size() helper where possible. Miguel increases the pause and refresh time for flow control in the e1000e driver during reset for certain devices. Dann Frazier fixes a potential NULL pointer dereference in ixgbe driver when using non-IPSec enabled devices. Colin Ian King fixes a potential overflow during a shift in the ixgbe driver. Also fixes a potential NULL pointer dereference in the iavf driver by adding a check. Venkatesh Srinivas converts the e1000 driver to use dma_wmb() instead of wmb() for doorbell writes to avoid SFENCEs in the transmit and receive paths. Arjan updates the e1000e driver to improve boot time by over 100 msec by reducing the usleep ranges suring system startup. Artem updates the igb driver register dump in ethtool, first prepares the register dump for future additions of registers in the dump, then secondly, adds the RR2DCDELAY register to the dump. When dealing with time-sensitive networks, this register is helpful in determining your latency from the device to the ring. Alex fixes the ixgbevf driver to use the current cached link state, rather than trying to re-check the value from the PF. Harshitha adds support for MACVLAN offloads in i40e by using channels as MACVLAN interfaces. Detlev Casanova updates the e1000e driver to use delayed work instead of timers to run the watchdog. Vitaly fixes an issue in e1000e, where when disconnecting and reconnecting the physical cable connection, the NIC enters a DMoff state. This state causes a mismatch in link and duplexing, so check the PCIm function state and perform a PHY reset when in this state to resolve the issue. ==================== Signed-off-by:
-
- 29 Jun, 2019 10 commits
-
-
Heiner Kallweit authored
DMA_API_HOWTO.txt includes an example explaining when dma_sync_single_for_device() is not needed, and that example matches our use case. The buffer isn't changed by the CPU and direction is DMA_FROM_DEVICE, so we can remove the call to dma_sync_single_for_device(). Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
Documentation/DMA-API-HOWTO.txt states: By default, the kernel assumes that your device can address 32-bits of DMA addressing. For a 64-bit capable device, this needs to be increased, and for a device with limitations, it needs to be decreased. Therefore we don't need the 32 Bit DMA fallback configuration and can remove it. Signed-off-by:
-
Heiner Kallweit authored
The VLAN tag is stored in the descriptor in network byte order. Using swab16 works on little endian host systems only. Better play safe and use ntohs or htons respectively. Signed-off-by:
-
Florian Westphal authored
running the script on systems without netdevsim now prints: SKIP: ipsec_offload can't load netdevsim instead of error message & failed status. Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
David S. Miller authored
Nikolay Aleksandrov says: ==================== em_ipt: add support for addrtype We would like to be able to use the addrtype from tc for ACL rules and em_ipt seems the best place to add support for the already existing xt match. The biggest issue is that addrtype revision 1 (with ipv6 support) is NFPROTO_UNSPEC and currently em_ipt can't differentiate between v4/v6 if such xt match is used because it passes the match's family instead of the packet one. The first 3 patches make em_ipt match only on IP traffic (currently both policy and addrtype recognize such traffic only) and make it pass the actual packet's protocol instead of the xt match family when it's unspecified. They also add support for NFPROTO_UNSPEC xt matches. The last patch allows to add addrtype rules via em_ipt. We need to keep the user-specified nfproto for dumping in order to be compatible with libxtables, we cannot dump NFPROTO_UNSPEC as the nfproto or we'll get an error from libxtables, thus the nfproto is limited to ipv4/ipv6 in patch 03 and is recorded. v3: don't use the user nfproto for matching, only for dumping, more information is available in the commit message in patch 03 v2: change patch 02 to set the nfproto only when unspecified and drop patch 04 from v1 (Eyal Birger) ==================== Signed-off-by: -
Nikolay Aleksandrov authored
Allow em_ipt to use addrtype for matching. Restrict the use only to revision 1 which has IPv6 support. Since it's a NFPROTO_UNSPEC xt match we use the user-specified nfproto for matching, in case it's unspecified both v4/v6 will be matched by the rule. v2: no changes, was patch 5 in v1 Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Nikolay Aleksandrov authored
If we dump NFPROTO_UNSPEC as nfproto user-space libxtables can't handle it and would exit with an error like: "libxtables: unhandled NFPROTO in xtables_set_nfproto" In order to avoid the error return the user-specified nfproto. If we don't record it then the match family is used which can be NFPROTO_UNSPEC. Even if we add support to mask NFPROTO_UNSPEC in iproute2 we have to be compatible with older versions which would be also be allowed to add NFPROTO_UNSPEC matches (e.g. addrtype after the last patch). v3: don't use the user nfproto for matching, only for dumping the rule, also don't allow the nfproto to be unspecified (explained above) v2: adjust changes to missing patch, was patch 04 in v1 Signed-off-by: -
Nikolay Aleksandrov authored
Set the family based on the packet if it's unspecified otherwise protocol-neutral matches will have wrong information (e.g. NFPROTO_UNSPEC). In preparation for using NFPROTO_UNSPEC xt matches. v2: set the nfproto only when unspecified Suggested-by:
Eyal Birger <eyal.birger@gmail.com> Signed-off-by:
-
Nikolay Aleksandrov authored
Restrict matching only to ip/ipv6 traffic and make sure we can use the headers, otherwise matches will be attempted on any protocol which can be unexpected by the xt matches. Currently policy supports only ipv4/6. Signed-off-by:
-
Xue Chaojing authored
This patch adds vlan offload support for the HINIC driver. Signed-off-by:
Xue Chaojing <xuechaojing@huawei.com> Signed-off-by:
-
- 28 Jun, 2019 7 commits
-
-
Paul Blakey authored
After changing the parent_id to be the same for both NICs of same the hardware device, netdev_port_same_parent_id now returns true for more cases (all the lower devices in the hierarchy are on the same hardware device). If merged eswitch isn't enabled, these cases aren't supported, so disallow them. Signed-off-by:
Paul Blakey <paulb@mellanox.com> Reviewed-by:
Roi Dayan <roid@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com>
-
Paul Blakey authored
Report system_image_guid as the E-Switch switch_id, this ensures that when a NIC contains multiple PCI functions and which has merged eswitch capability, all representors from multiple PFs publish same switch_id. Signed-off-by:
Parav Pandit <parav@mellanox.com> Reviewed-by:
-
Gavi Teitz authored
Refreshing TIRs is done in order to update the TIRs with the current state of SQs in the transport domain, so that the TIRs can filter out undesired self-loopback packets based on the source SQ of the packet. Representor TIRs will only receive packets that originate from their associated vport, due to dedicated steering, and therefore will never receive self-loopback packets, whose source vport will be the vport of the E-Switch manager, and therefore not the vport associated with the representor. As such, it is not necessary to refresh the representors' TIRs, since self-loopback packets can't reach them. Since representors only exist in switchdev mode, and there is no scenario in which a representor will exist in the transport domain alongside a non-representor, it is not necessary to refresh the transport domain's TIRs upon changing the state of a representor's queues. Therefore, do not refresh TIRs upon such a change. Achieve this by adding an update_rx callback to the mlx5e_profile, which refreshes TIRs for non-representors and does nothing for representors, and replace instances of mlx5e_refresh_tirs() upon changing the state of the queues with update_rx(). Signed-off-by:
Gavi Teitz <gavi@mellanox.com> Reviewed-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
-
Arnd Bergmann authored
Putting an empty 'mlx5_flow_spec' structure on the stack is a bit wasteful and causes a warning on 32-bit architectures when building with clang -fsanitize-coverage: drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c: In function 'mlx5_eswitch_termtbl_create': drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads_termtbl.c:90:1: error: the frame size of 1032 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] Since the structure is never written to, we can statically allocate it to avoid the stack usage. To be on the safe side, mark all subsequent function arguments that we pass it into as 'const' as well. Fixes: 10caabda ("net/mlx5e: Use termination table for VLAN push actions") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Mark Bloch <markb@mellanox.com> Signed-off-by:
-
Parav Pandit authored
Consider PCI and non PCI device types while setting device name in get_drvinfo() callback using existing generic device. Signed-off-by:
Vu Pham <vuhuong@mellanox.com> Signed-off-by:
-
Parav Pandit authored
Currently PF phys_port_name is named as pfNvf-1 as vport number for PF vport is 65535. Correct PF's phys_port name as agreed upon name as pfN. Signed-off-by:
-
Ariel Levkovich authored
Set supported device features in the netdevice MPLS features mask. This will enable HW checksumming and TSO for MPLS tagged traffic. Signed-off-by:
Ariel Levkovich <lariel@mellanox.com> Signed-off-by:
-
