- 01 May, 2018 10 commits
-
-
Ilya Lesokhin authored
Add routines for manipulating TLS TX offload contexts. In Innova TLS, TLS contexts are added or deleted via a command message over the SBU connection. The HW then sends a response message over the same connection. Add implementation for Innova TLS (FPGA-based) hardware. These routines will be used by the TLS offload support in a later patch mlx5/accel is a middle acceleration layer to allow mlx5e and other ULPs to work directly with mlx5_core rather than Innova FPGA or other mlx5 acceleration providers. In the future, when IPSec/TLS or any other acceleration gets integrated into ConnectX chip, mlx5/accel layer will provide the integrated acceleration, rather than the Innova one. Signed-off-by:
Ilya Lesokhin <ilyal@mellanox.com> Signed-off-by:
Boris Pismenny <borisp@mellanox.com> Acked-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ilya Lesokhin authored
The defines are not IPSEC specific. Signed-off-by:
-
Ilya Lesokhin authored
This patch adds a generic infrastructure to offload TLS crypto to a network device. It enables the kernel TLS socket to skip encryption and authentication operations on the transmit side of the data path. Leaving those computationally expensive operations to the NIC. The NIC offload infrastructure builds TLS records and pushes them to the TCP layer just like the SW KTLS implementation and using the same API. TCP segmentation is mostly unaffected. Currently the only exception is that we prevent mixed SKBs where only part of the payload requires offload. In the future we are likely to add a similar restriction following a change cipher spec record. The notable differences between SW KTLS and NIC offloaded TLS implementations are as follows: 1. The offloaded implementation builds "plaintext TLS record", those records contain plaintext instead of ciphertext and place holder bytes instead of authentication tags. 2. The offloaded implementation maintains a mapping from TCP sequence number to TLS records. Thus given a TCP SKB sent from a NIC offloaded TLS socket, we can use the tls NIC offload infrastructure to obtain enough context to encrypt the payload of the SKB. A TLS record is released when the last byte of the record is ack'ed, this is done through the new icsk_clean_acked callback. The infrastructure should be extendable to support various NIC offload implementations. However it is currently written with the implementation below in mind: The NIC assumes that packets from each offloaded stream are sent as plaintext and in-order. It keeps track of the TLS records in the TCP stream. When a packet marked for offload is transmitted, the NIC encrypts the payload in-place and puts authentication tags in the relevant place holders. The responsibility for handling out-of-order packets (i.e. TCP retransmission, qdisc drops) falls on the netdev driver. The netdev driver keeps track of the expected TCP SN from the NIC's perspective. If the next packet to transmit matches the expected TCP SN, the driver advances the expected TCP SN, and transmits the packet with TLS offload indication. If the next packet to transmit does not match the expected TCP SN. The driver calls the TLS layer to obtain the TLS record that includes the TCP of the packet for transmission. Using this TLS record, the driver posts a work entry on the transmit queue to reconstruct the NIC TLS state required for the offload of the out-of-order packet. It updates the expected TCP SN accordingly and transmits the now in-order packet. The same queue is used for packet transmission and TLS context reconstruction to avoid the need for flushing the transmit queue before issuing the context reconstruction request. Signed-off-by:
Aviad Yehezkel <aviadye@mellanox.com> Signed-off-by:
-
Boris Pismenny authored
In TLS inline crypto, we can have one direction in software and another in hardware. Thus, we split the TLS configuration to separate structures for receive and transmit. Signed-off-by:
-
Ilya Lesokhin authored
This patch adds a netdev feature to configure TLS TX offloads. Signed-off-by:
-
Ilya Lesokhin authored
Add new netdev ops to add and delete tls context Signed-off-by:
-
Ilya Lesokhin authored
With socket dependent offloads we rely on the netdev to transform the transmitted packets before sending them to the wire. When a packet from an offloaded socket is rerouted to a different device we need to detect it and do the transformation in software. Signed-off-by:
-
Ilya Lesokhin authored
copy_skb_header is renamed to skb_copy_header and exported. Exposing this function give more flexibility in copying SKBs. skb_copy and skb_copy_expand do not give enough control over which parts are copied. Signed-off-by:
-
Ilya Lesokhin authored
Called when a TCP segment is acknowledged. Could be used by application protocols who hold additional metadata associated with the stream data. This is required by TLS device offload to release metadata associated with acknowledged TLS records. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 40GbE Intel Wired LAN Driver Updates 2018-04-30 This series contains updates to i40e and i40evf only. Jia-Ju Bai replaces an instance of GFP_ATOMIC to GFP_KERNEL, since i40evf is not in atomic context when i40evf_add_vlan() is called. Jake cleans up function header comments to ensure that the function parameter comments actually match the function parameters. Fixed a possible overflow error in the PTP clock code. Fixed warnings regarding restricted __be32 type usage. Mariusz fixes the reading of the LLDP configuration, which moves from using relative values to calculating the absolute address. Jakub adds a check for 10G LR mode for i40e. Paweł fixes an issue, where changing the MTU would turn on TSO, GSO and GRO. Alex fixes a couple of issues with the UDP tunnel filter configuration. First being that the tunnels did not have mutual exclusion in place to prevent a race condition between a user request to add/remove a port and an update. The second issue was we were deleting filters that were not associated with the actual filter we wanted to delete. Harshitha ensures that the queue map sent by the VF is taken into account when enabling/disabling queues in the VF VSI. ==================== Signed-off-by:
-
- 30 Apr, 2018 30 commits
-
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: SPAN: Support routes pointing at bridges Petr says: When mirroring to a gretap or ip6gretap netdevice, the route that directs the encapsulated packets can reference a bridge. In that case, in the software model, the packet is switched. Thus when offloading mirroring like that, take into consideration FDB, STP, PVID configured at the bridge, and whether that VLAN ID should be tagged on egress. Patch #1 introduces functions to get bridge PVID, VLAN flags and to look up an FDB entry. Patches #2 and #3 refactor some existing code and introduce a new accessor function. With patches #4 and #5 mlxsw calls mlxsw_sp_span_respin() on switchdev events as well. There is no impact yet, because bridge as an underlay device is still not allowed. That is implemented in patch #6, which uses the new interfaces to figure out on which one port the mirroring should be configured, and whether the mirrored packets should be VLAN-tagged and how. Changes from v2 to v3: - Rename the suite of bridge accessor function to br_vlan_get_pvid(), br_vlan_get_info() and br_fdb_find_port(). The _get bit is to avoid clashing with an existing static function. Changes from v1 to v2: - Change the suite of bridge accessor functions to br_vlan_pvid_rtnl(), br_vlan_info_rtnl(), br_fdb_find_port_rtnl(). ==================== Signed-off-by: -
Petr Machata authored
When handling mirroring to a gretap or ip6gretap netdevice in mlxsw, the underlay address (i.e. the remote address of the tunnel) may be routed to a bridge. In that case, look up the resolved neighbor Ethernet address in that bridge's FDB. Then configure the offload to direct the mirrored traffic to that port, possibly with tagging. Signed-off-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Reviewed-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Petr Machata authored
Changes to switchdev artifact can make a SPAN entry offloadable or unoffloadable. To that end: - Listen to SWITCHDEV_FDB_*_TO_BRIDGE notifications in addition to the *_TO_DEVICE ones, to catch whatever activity is sent to the bridge (likely by mlxsw itself). On each FDB notification, respin SPAN to reconcile it with the FDB changes. - Also respin on switchdev port attribute changes (which currently covers changes to STP state of ports) and port object additions and removals. Signed-off-by:
-
Petr Machata authored
Since switchdev events can trigger SPAN respin, it is necessary that the data structures are available. Register SPAN first, with a commentary on what the dependencies are. Signed-off-by:
-
Petr Machata authored
Publish the existing function mlxsw_sp_bridge_port_find(), and add another service accessor mlxsw_sp_bridge_port_stp_state(). Publish both in a new file spectrum_switchdev.h. Signed-off-by:
-
Petr Machata authored
Instead of duplicating the decision regarding port forwarding state made by mlxsw_sp_port_vid_stp_set(), extract the decision-making into a new function and reuse. Signed-off-by:
-
Petr Machata authored
Add a couple new functions to allow querying FDB and vlan settings of a bridge. Signed-off-by:
-
Jacob Keller authored
Fix warnings regarding restricted __be32 type usage by strictly specifying the type of the ipv4 address being printed in the dev_err statement. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Harshitha Ramamurthy authored
The expectation of the ops VIRTCHNL_OP_ENABLE_QUEUES and VIRTCHNL_OP_DISABLE_QUEUES is that the queue map sent by the VF is taken into account when enabling/disabling queues in the VF VSI. This patch makes sure that happens. By breaking out the individual queue set up functions so that they can be called directly from the i40e_virtchnl_pf.c file, only the queues as specified by the queue bit map that accompanies the enable/disable queues ops will be handled. Signed-off-by:
Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by:
-
Jacob Keller authored
When operating at 1GbE, the base incval for the PTP clock is so large that multiplying it by numbers close to the max_adj can overflow the u64. Rather than attempting to limit the max_adj to a value small enough to avoid overflow, instead calculate the incvalue adjustment based on the 40GbE incvalue, and then multiply that by the scaling factor for the link speed. This sacrifices a small amount of precision in the adjustment but we avoid erratic behavior of the clock due to the overflow caused if ppb is very near the maximum adjustment. Signed-off-by:
-
Alexander Duyck authored
This fixes at least 2 issues I have found with the UDP tunnel filter configuration. The first issue is the fact that the tunnels didn't have any sort of mutual exclusion in place to prevent an update from racing with a user request to add/remove a port. As such you could request to add and remove a port before the port update code had a chance to respond which would result in a very confusing result. To address it I have added 2 changes. First I added the RTNL mutex wrapper around our updating of the pending, port, and filter_index bits. Second I added logic so that we cannot use a port that has a pending deletion since we need to free the space in hardware before we can allow software to reuse it. The second issue addressed is the fact that we were not recording the actual filter index provided to us by the admin queue. As a result we were deleting filters that were not associated with the actual filter we wanted to delete. To fix that I added a filter_index member to the UDP port tracking structure. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Tested-by:
-
Paweł Jabłoński authored
This patch fixes the problem where each MTU change turns TSO, GSO and GRO on from off state. Now when TSO, GSO or GRO is turned off, MTU change does not turn them on. Signed-off-by:
Paweł Jabłoński <pawel.jablonski@intel.com> Tested-by:
-
Jakub Pawlak authored
The advertising 10G LR mode should be possible to set but in the function i40e_set_link_ksettings() check for this is missed. This patch adds check for 10000baseLR_Full flag for 10G modes. Signed-off-by:
Jakub Pawlak <jakub.pawlak@intel.com> Tested-by:
-
Ahmed Abdelsalam authored
The seg6_make_flowlabel() is used by seg6_do_srh_encap() to compute the flowlabel from a given skb. It relies on skb_get_hash() which eventually calls __skb_flow_dissect() to extract the flow_keys struct values from the skb. In case of IPv4 traffic, calling seg6_make_flowlabel() after skb_push(), skb_reset_network_header(), and skb_mac_header_rebuild() will results in flow_keys struct of all key values set to zero. This patch calls seg6_make_flowlabel() before resetting the headers of skb to get the right key values. Extracted Key values are based on the type inner packet as follows: 1) IPv6 traffic: src_IP, dst_IP, L4 proto, and flowlabel of inner packet. 2) IPv4 traffic: src_IP, dst_IP, L4 proto, src_port, and dst_port 3) L2 traffic: depends on what kind of traffic carried into the L2 frame. IPv6 and IPv4 traffic works as discussed 1) and 2) Here a hex_dump of struct flow_keys for IPv4 and IPv6 traffic 10.100.1.100: 47302 > 30.0.0.2: 5001 00000000: 14 00 02 00 00 00 00 00 08 00 11 00 00 00 00 00 00000010: 00 00 00 00 00 00 00 00 13 89 b8 c6 1e 00 00 02 00000020: 0a 64 01 64 fc00:a1:a > b2::2 00000000: 28 00 03 00 00 00 00 00 86 dd 11 00 99 f9 02 00 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 b2 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 02 fc 00 00 a1 00000030: 00 00 00 00 00 00 00 00 00 00 00 0a Signed-off-by:
Ahmed Abdelsalam <amsalam20@gmail.com> Signed-off-by:
-
Mariusz Stachura authored
Previous method for reading LLDP config was based on hard-coded offsets. It happened to work, because of structured architecture of the NVM memory. In the new approach, known as FLAT, we need to calculate the absolute address, instead of using relative values. Needed defines for memory location were added. Signed-off-by:
Mariusz Stachura <mariusz.stachura@intel.com> Tested-by:
-
Jacob Keller authored
Recent versions of the Linux kernel now warn about incorrect parameter definitions for function comments. Fix up several function comments to correctly reflect the current function arguments. This cleans up the warnings and helps ensure our documentation is accurate. Signed-off-by:
-
YueHaibing authored
use helper __skb_put_zero to replace the pattern of __skb_put() && memset() Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
William Tu authored
Currently the truncated bit is set only when the mirrored packet is larger than mtu. For certain cases, the packet might already been truncated before sending to the erspan tunnel. In this case, the patch detect whether the IP header's total length is larger than the actual skb->len. If true, this indicated that the mirrored packet is truncated and set the erspan truncate bit. I tested the patch using bpf_skb_change_tail helper function to shrink the packet size and send to erspan tunnel. Reported-by:
Xiaoyan Jin <xiaoyanj@vmware.com> Signed-off-by:
William Tu <u9012063@gmail.com> Signed-off-by:
-
Jia-Ju Bai authored
i40evf_add_vlan() is never called in atomic context. i40evf_add_vlan() is only called by i40evf_vlan_rx_add_vid(), which is only set as ".ndo_vlan_rx_add_vid" in struct net_device_ops. ".ndo_vlan_rx_add_vid" is not called in atomic context. Despite never getting called from atomic context, i40evf_add_vlan() calls kzalloc() with GFP_ATOMIC, which does not sleep for allocation. GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL, which can sleep and improve the possibility of sucessful allocation. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Tested-by:
-
David S. Miller authored
Heiner Kallweit says: ==================== r8169: further improvements w/o functional change This series aims at further improving and simplifying the code w/o any intended functional changes. Series was tested on: RTL8169sb, RTL8168d, RTL8168e-vl ==================== Signed-off-by: -
Heiner Kallweit authored
The chip-specific init code includes quite some calls which are identical for all chips. So move these calls to tp->hw_start(). In addition move rtl_set_rx_max_size() a little to make sure it's defined before it's used. Unfortunately the diff generated by git is a little bit hard to read. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
__dev_open() calls the ndo_set_rx_mode callback anyway, so we don't have to do it here too. Signed-off-by:
-
Heiner Kallweit authored
Currently done: - if mac_version in (01, 02, 03, 04) RTL_W8(tp, ChipCmd, CmdTxEnb | CmdRxEnb); - if mac_version in (01, 02, 03, 04) rtl_set_rx_tx_config_registers(tp); - if mac_version not in (01, 02, 03, 04) RTL_W8(tp, ChipCmd, CmdTxEnb | CmdRxEnb); rtl_set_rx_tx_config_registers(tp); So we do exactly the same independent of chip version and can simplify the code. In addition remove the call to rtl_init_rxcfg(), it's called in rtl_init_one() already and the set bits are never touched later. rtl_init_8168/8101 don't include this call either. Signed-off-by:
-
Heiner Kallweit authored
Both quirk masks are the same, so we can merge them. The quirk mask includes most bits so it's actually easier to define a mask with the bits to keep. Signed-off-by:
-
Heiner Kallweit authored
tp->cp_cmd is supposed to reflect the current value of the CplusCmd register. Several (quite old) changes however directly change this register w/o updating tp->cp_cmd. Also we have places in the code reading this register where we could use the cached value. In addition: - Properly initialize tp->cmd with the register value. - In rtl_hw_start_8169 remove one setting of PCIMulRW because it's set unconditionally anyway a few lines later. - In rtl_hw_start_8168 properly mask out the INTT bits before setting INTT_1. So far we rely on both bits being zero. Signed-off-by:
-
Heiner Kallweit authored
Use a proper constant for INTT bit mask. Signed-off-by:
-
Heiner Kallweit authored
__rtl8169_set_features is used in rtl8169_set_features only, so we can inline it. In addition: - Remove check (features ^ dev->features), __netdev_update_features check's already that requested features differ from current ones. - Don't mask out unsupported flags, there's no benefit in it. Signed-off-by:
-
Heiner Kallweit authored
RxChkSum and RxVlan aren't touched outside __rtl8169_set_features (except in probe), so they are always in sync with dev->features. And the RxConfig flags are set in rtl_set_rx_mode() which is called via dev_set_rx_mode() from __dev_open(). Therefore we can safely remove this call. Signed-off-by:
-
Colin Ian King authored
Trivial fix to spelling mistake in oct_stats_strings text Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
David S. Miller authored
Intiyaz Basha says: ==================== liquidio: enhanced ethtool --set-channels feature For the ethtool --set-channels feature, the liquidio driver currently accepts max combined value as the queue count configured during driver load time, where max combined count is the total count of input and output queues. This limitation is applicable only when SR-IOV is enabled, that is, when VFs are created for PF. If SR-IOV is not enabled, the driver can configure max supported (64) queues. This series of patches are for enhancing driver to accept max supported queues for ethtool --set-channels. Changes in V2: Only patch #6 was changed to fix these Sparse warnings reported by kbuild test robot: lio_ethtool.c:848:5: warning: symbol 'lio_23xx_reconfigure_queue_count' was not declared. Should it be static? lio_ethtool.c:877:22: warning: incorrect type in assignment (different base types) lio_ethtool.c:878:22: warning: incorrect type in assignment (different base types) lio_ethtool.c:879:22: warning: incorrect type in assignment (different base types) ==================== Signed-off-by:
-
