- 27 Mar, 2018 7 commits
-
-
Wei Yongjun authored
Fixes the following sparse warning: drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c:508:5: warning: symbol 'hw_atl_utils_mpi_set_speed' was not declared. Should it be static? Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Maxime Chevallier says: ==================== net: mvpp2: Remove unnecessary dynamic allocs Some utility functions in mvpp2 make use of dynamic alloc to exchange temporary objects representing Parser Entries (which are generic filtering entries in the PPv2 controller). These objects are small (44 bytes each), we can use the stack to exchange them. Some previous discussion on this topic showed that the mvpp2_prs_hw_read, which initializes a struct mvpp2_prs_entry based on one of its fields, can easily lead to erroneous code if we don't zero-out the struct beforehand : https://lkml.org/lkml/2018/3/21/739 To fix this, I propose to rename mvpp2_prs_hw_read into mvpp2_prs_init_from_hw, make it zero-out the struct and take the index as a parameter. That's what's done in the first patch of the series. The second patch is the V3 of ("net: mvpp2: Don't use dynamic allocs for local variables"), making use of mvpp2_prs_init_from_hw and taking previous comments into account. ==================== Signed-off-by:
-
Maxime Chevallier authored
Some helper functions that search for given entries in the TCAM filter on PPv2 controller make use of dynamically alloced temporary variables, allocated with GFP_KERNEL. These functions can be called in atomic context, and dynamic alloc is not really needed in these cases anyways. This commit gets rid of dynamic allocs and use stack allocation in the following functions, and where they're used : - mvpp2_prs_flow_find - mvpp2_prs_vlan_find - mvpp2_prs_double_vlan_find - mvpp2_prs_mac_da_range_find For all these functions, instead of returning an temporary object representing the TCAM entry, we simply return the TCAM id that matches the requested entry. Signed-off-by:
Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by:
-
Maxime Chevallier authored
The mvpp2_prs_hw_read function uses the 'index' field of the struct mvpp2_prs_entry to initialize the rest of the fields. This makes it unclear from a caller's perspective, who needs to manipulate a struct that is not entirely initialized. This commit makes it an init function for prs_entry, by passing it the index as a parameter. The function now zeroes the entry, and sets the index field before doing all other init from HW. The function is renamed 'mvpp2_prs_init_from_hw' to make that clear. Signed-off-by:
-
Colin Ian King authored
The call to nla_nest_start calls nla_put which can lead to a NULL return so it's possible for attr to become NULL and we can potentially get a NULL pointer dereference on attr. Fix this by checking for a NULL return. Detected by CoverityScan, CID#1466125 ("Dereference null return") Fixes: 955dc68c ("net/ncsi: Add generic netlink family") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Xin Long authored
After Commit dae399d7 ("sctp: hold transport instead of assoc when lookup assoc in rx path"), it put transport instead of asoc in sctp_has_association. Variable 'asoc' is not used any more. So this patch is to remove it, while at it, it also changes the return type of sctp_has_association to bool, and does the same for it's caller sctp_endpoint_is_peeled_off. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> 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-03-26 This series contains updates to i40e only. Jake provides several patches which remove the need for cmpxchg64(), starting with moving I40E_FLAG_[UDP]_FILTER_SYNC from pf->flags to pf->state since they are modified during run time possibly when the RTNL lock is not held so they should be a state bits and not flags. Moved additional "flags" which should be state fields, into pf->state. Ensure we hold the RTNL lock for the entire sequence of preparing for reset and when resuming, which will protect the flags related to interrupt scheme under RTNL lock so that their modification is properly threaded. Finally, cleanup the use of cmpxchg64() since it is no longer needed. Cleaned up the holes in the feature flags created my moving some flags to the state field. Björn Töpel adds XDP_REDIRECT support as well as tweaking the page counting for XDP_REDIRECT so that it will function properly. ==================== Signed-off-by:
-
- 26 Mar, 2018 33 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 100GbE Intel Wired LAN Driver Updates 2018-03-26 This patch series adds the ice driver, which will support the Intel(R) E800 Series of network devices. This is the first phase in the release of this driver where we implement basic transmit and receive. The idea behind the multi-phase release is to aid in code review as well as testing. Subsequent phases will implement advanced features (like SR-IOV, tunnelling, flow director, QoS, etc.) that build upon the previous phase(s). Each phase will be submitted as a patch series. ==================== Signed-off-by: -
Björn Töpel authored
The driver now acts upon the XDP_REDIRECT return action. Two new ndos are implemented, ndo_xdp_xmit and ndo_xdp_flush. XDP_REDIRECT action enables XDP program to redirect frames to other netdevs. Signed-off-by:
Björn Töpel <bjorn.topel@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Björn Töpel authored
This commit tweaks the page counting for XDP_REDIRECT to function properly. XDP_REDIRECT support will be added in a future commit. The current page counting scheme assumes that the reference count cannot decrease until the received frame is sent to the upper layers of the networking stack. This assumption does not hold for the XDP_REDIRECT action, since a page (pointed out by xdp_buff) can have its reference count decreased via the xdp_do_redirect call. To work around that, we now start off by a large page count and then don't allow a refcount less than two. Signed-off-by:
-
Jacob Keller authored
Remove the gaps created by the recent refactor of various feature flags that have moved to the state field. Use only a u32 now that we have fewer than 32 flags in the field. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
-
Jacob Keller authored
Now that the only places which modify flags are either (a) during initialization prior to creating a netdevice, or (b) while holding the rtnl lock, we no longer need the cmpxchg64 call in i40e_set_priv_flags. Signed-off-by:
-
Jacob Keller authored
When we suspend and resume, we need to clear and re-enable the interrupt scheme. This was previously not done while holding the RTNL lock, which could be problematic, because we are actually destroying and re-creating queues. Hold the RTNL lock for the entire sequence of preparing for reset, and when resuming. This additionally protects the flags related to interrupt scheme under RTNL lock so that their modification is properly threaded. This is part of a larger effort to remove the need for cmpxchg64 in i40e_set_priv_flags(). Signed-off-by:
-
Jacob Keller authored
The iWarp client flags are all potentially changed when the RTNL lock is not held, so they should not be part of the pf->flags variable. Instead, move them into the state field so that we can use atomic bit operations. This is part of a larger effort to remove cmpxchg64 in i40e_set_priv_flags() Signed-off-by:
-
Jacob Keller authored
This flag is modified outside of the RTNL lock and thus should not be part of the pf->flags variable. Use a state bit instead, so that we can use atomic bit operations. This is part of a larger effort to remove cmpxchg64 in i40e_set_priv_flags() Signed-off-by:
-
Jacob Keller authored
The two Flow Directory auto disable flags are used at run time to mark when the flow director features needed to be disabled. Thus the flags could change even when the RTNL lock is not held. They also have some code constructions which really should be test_and_set or test_and_clear using atomic bit operations. Create new state fields to mark this, and stop including them in pf->flags. This is part of a larger effort to remove the need for cmpxchg64 in i40e_set_priv_flags(). Signed-off-by:
-
Jacob Keller authored
This flag is modified during run time, possibly even when the RTNL lock is not held. Additionally it has a few places which should be using test_and_set or test_and_clear atomic bit operations. Create a new state bit __I40E_UDP_SYNC_PENDING and use it instead of the ole I40E_FLAG_UDP_FILTER_SYNC flag. This is part of a larger effort to remove the need for using cmpxchg64 in i40e_set_priv_flags. Signed-off-by:
-
Jacob Keller authored
The I40E_FLAG_FILTER_SYNC flag is modified during run time possibly when the RTNL lock is not held. Thus, it should not be part of pf->flags, and instead should be using atomic bit operations in the pf->state field. Create a __I40E_MACVLAN_SYNC_PENDING state bit, and use it instead of the old I40E_FLAG_FILTER_SYNC flag. This is part of a larger effort to remove the need for cmpxchg64 in i40e_set_priv_flags(). Signed-off-by:
-
Anirudh Venkataramanan authored
This patch implements multiple pieces of functionality: 1. Added ice_vsi_sync_filters, which is called through the service task to push filter updates to the hardware. 2. Add support to enable/disable promiscuous mode on an interface. Enabling/disabling promiscuous mode on an interface results in addition/removal of a promisc filter rule through ice_vsi_sync_filters. 3. Implement handlers for ndo_set_mac_address, ndo_change_mtu, ndo_poll_controller and ndo_set_rx_mode. This patch also marks the end of the driver addition by bumping up the driver version. Signed-off-by:
Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by:
Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by:
-
Anirudh Venkataramanan authored
Link events are posted to a PF's admin receive queue (ARQ). This patch adds the ability to detect and process link events. This patch also adds the ability to process resets. The driver can process the following resets: 1) EMP Reset (EMPR) 2) Global Reset (GLOBR) 3) Core Reset (CORER) 4) Physical Function Reset (PFR) EMPR is the largest level of reset that the driver can handle. An EMPR resets the manageability block and also the data path, including PHY and link for all the PFs. The affected PFs are notified of this event through a miscellaneous interrupt. GLOBR is a subset of EMPR. It does everything EMPR does except that it doesn't reset the manageability block. CORER is a subset of GLOBR. It does everything GLOBR does but doesn't reset PHY and link. PFR is a subset of CORER and affects only the given physical function. In other words, PFR can be thought of as a CORER for a single PF. Since only the issuing PF is affected, a PFR doesn't result in the miscellaneous interrupt being triggered. All the resets have the following in common: 1) Tx/Rx is halted and all queues are stopped. 2) All the VSIs and filters programmed for the PF are lost and have to be reprogrammed. 3) Control queue interfaces are reset and have to be reprogrammed. In the rebuild flow, control queues are reinitialized, VSIs are reallocated and filters are restored. Signed-off-by: -
Anirudh Venkataramanan authored
This patch adds the ability for a VSI to use multiple Tx queues. More specifically, the patch 1) Provides the ability to update the Tx scheduler tree in the firmware. The driver can configure the Tx scheduler tree by adding/removing multiple Tx queues per TC per VSI. 2) Allows a VSI to reconfigure its Tx queues during runtime. 3) Synchronizes the Tx scheduler update operations using locks. Signed-off-by: -
Anirudh Venkataramanan authored
This patch implements a watchdog task to get packet statistics from the device. This patch also adds support for the following ethtool operations: ethtool devname ethtool -s devname [msglvl N] [msglevel type on|off] ethtool -g|--show-ring devname ethtool -G|--set-ring devname [rx N] [tx N] ethtool -i|--driver devname ethtool -d|--register-dump devname [raw on|off] [hex on|off] [file name] ethtool -k|--show-features|--show-offload devname ethtool -K|--features|--offload devname feature on|off ethtool -P|--show-permaddr devname ethtool -S|--statistics devname ethtool -a|--show-pause devname ethtool -A|--pause devname [autoneg on|off] [rx on|off] [tx on|off] ethtool -r|--negotiate devname CC: Andrew Lunn <andrew@lunn.ch> CC: Jakub Kicinski <kubakici@wp.pl> CC: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
Stephen Hemminger <stephen@networkplumber.org> Tested-by:
-
Anirudh Venkataramanan authored
This patch adds support for VLANs. When a VLAN is created a switch filter is added to direct the VLAN traffic to the corresponding VSI. When a VLAN is deleted, the filter is deleted as well. This patch also adds support for the following hardware offloads. 1) VLAN tag insertion/stripping 2) Receive Side Scaling (RSS) 3) Tx checksum and TCP segmentation 4) Rx checksum Signed-off-by: -
Anirudh Venkataramanan authored
This patch implements ice_start_xmit (the handler for ndo_start_xmit) and related functions. ice_start_xmit ultimately calls ice_tx_map, where the Tx descriptor is built and posted to the hardware by bumping the ring tail. This patch also implements ice_napi_poll, which is invoked when there's an interrupt on the VSI's queues. The interrupt can be due to either a completed Tx or an Rx event. In case of a completed Tx/Rx event, resources are reclaimed. Additionally, in case of an Rx event, the skb is fetched and passed up to the network stack. Signed-off-by:
-
Anirudh Venkataramanan authored
This patch configures the VSIs to be able to send and receive packets by doing the following: 1) Initialize flexible parser to extract and include certain fields in the Rx descriptor. 2) Add Tx queues by programming the Tx queue context (implemented in ice_vsi_cfg_txqs). Note that adding the queues also enables (starts) the queues. 3) Add Rx queues by programming Rx queue context (implemented in ice_vsi_cfg_rxqs). Note that this only adds queues but doesn't start them. The rings will be started by calling ice_vsi_start_rx_rings on interface up. 4) Configure interrupts for VSI queues. 5) Implement ice_open and ice_stop. Signed-off-by:
-
Anirudh Venkataramanan authored
A VSI needs traffic directed towards it. This is done by programming filter rules on the switch (embedded vSwitch) element in the hardware, which connects the VSI to the ingress/egress port. This patch introduces data structures and functions necessary to add remove or update switch rules on the switch element. This is a pretty low level function that is generic enough to add a whole range of filters. This patch also introduces two top level functions ice_add_mac and ice_remove mac which through a series of intermediate helper functions eventually call ice_aq_sw_rules to add/delete simple MAC based filters. It's worth noting that one invocation of ice_add_mac/ice_remove_mac is capable of adding/deleting multiple MAC filters. Also worth noting is the fact that the driver maintains a list of currently active filters, so every filter addition/removal causes an update to this list. This is done for a couple of reasons: 1) If two VSIs try to add the same filters, we need to detect it and do things a little differently (i.e. use VSI lists, described below) as the same filter can't be added more than once. 2) In the event of a hardware reset we can simply walk through this list and restore the filters. VSI Lists: In a multi-VSI situation, it's possible that multiple VSIs want to add the same filter rule. For example, two VSIs that want to receive broadcast traffic would both add a filter for destination MAC ff:ff:ff:ff:ff:ff. This can become cumbersome to maintain and so this is handled using a VSI list. A VSI list is resource that can be allocated in the hardware using the ice_aq_alloc_free_res admin queue command. Simply put, a VSI list can be thought of as a subscription list containing a set of VSIs to which the packet should be forwarded, should the filter match. For example, if VSI-0 has already added a broadcast filter, and VSI-1 wants to do the same thing, the filter creation flow will detect this, allocate a VSI list and update the switch rule so that broadcast traffic will now be forwarded to the VSI list which contains VSI-0 and VSI-1. Signed-off-by:
-
Anirudh Venkataramanan authored
This patch introduces data structures and functions to alloc/free VSIs. The driver represents a VSI using the ice_vsi structure. Some noteworthy points about VSI allocation: 1) A VSI is allocated in the firmware using the "add VSI" admin queue command (implemented as ice_aq_add_vsi). The firmware returns an identifier for the allocated VSI. The VSI context is used to program certain aspects (loopback, queue map, etc.) of the VSI's configuration. 2) A VSI is deleted using the "free VSI" admin queue command (implemented as ice_aq_free_vsi). 3) The driver represents a VSI using struct ice_vsi. This is allocated and initialized as part of the ice_vsi_alloc flow, and deallocated as part of the ice_vsi_delete flow. 4) Once the VSI is created, a netdev is allocated and associated with it. The VSI's ring and vector related data structures are also allocated and initialized. 5) A VSI's queues can either be contiguous or scattered. To do this, the driver maintains a bitmap (vsi->avail_txqs) which is kept in sync with the firmware's VSI queue allocation imap. If the VSI can't get a contiguous queue allocation, it will fallback to scatter. This is implemented in ice_vsi_get_qs which is called as part of the VSI setup flow. In the release flow, the VSI's queues are released and the bitmap is updated to reflect this by ice_vsi_put_qs. CC: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by:
Shannon Nelson <shannon.nelson@oracle.com> Tested-by:
-
Anirudh Venkataramanan authored
This patch continues the initialization flow as follows: 1) Allocate and initialize necessary fields (like vsi, num_alloc_vsi, irq_tracker, etc) in the ice_pf instance. 2) Setup the miscellaneous interrupt handler. This also known as the "other interrupt causes" (OIC) handler and is used to handle non hotpath interrupts (like control queue events, link events, exceptions, etc. 3) Implement a background task to process admin queue receive (ARQ) events received by the driver. CC: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by:
-
Anirudh Venkataramanan authored
This patch adds code to continue the initialization flow as follows: 1) Get PHY/link information and store it 2) Get default scheduler tree topology and store it 3) Get the MAC address associated with the port and store it Signed-off-by:
-
Anirudh Venkataramanan authored
This patch adds to the initialization flow by getting switch configuration, scheduler configuration and device capabilities. Switch configuration: On boot, an L2 switch element is created in the firmware per physical function. Each physical function is also mapped to a port, to which its switch element is connected. In other words, this switch can be visualized as an embedded vSwitch that can connect a physical function's virtual station interfaces (VSIs) to the egress/ingress port. Egress/ingress filters will be eventually created and applied on this switch element. As part of the initialization flow, the driver gets configuration data from this switch element and stores it. Scheduler configuration: The Tx scheduler is a subsystem responsible for setting and enforcing QoS. As part of the initialization flow, the driver queries and stores the default scheduler configuration for the given physical function. Device capabilities: As part of initialization, the driver has to determine what the device is capable of (ex. max queues, VSIs, etc). This information is obtained from the firmware and stored by the driver. CC: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Offload IPv6 multicast routes Yuval says: The series is intended to allow offloading IPv6 multicast routes and is split into two parts: - First half of the patches continue extending ip6mr [& refactor ipmr] with missing bits necessary for the offloading - fib-notifications, mfc refcounting and default rule identification. - Second half of the patches extend functionality inside mlxsw, beginning with extending lower-parts to support IPv6 mroutes to host and later extending the router/mr internal APIs within the driver to accommodate support in ipv6 configurations. Lastly it adds support in the RTNL_FAMILY_IP6MR notifications, allowing driver to react and offload related routes. ==================== Signed-off-by: -
Yuval Mintz authored
Add a new trap for PIMv6 packets. As PIM already has a designated trap group [ & rate limiter], simply use the same for PIMv6 as well. Signed-off-by:
Yuval Mintz <yuvalm@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Yuval Mintz authored
Following previous patches driver is ready to handle notifications arriving from ip6mr - start processing those when they arrive following the same manner ipmr currently goes through. This should enable driver to start offloading ipv6 multicast routes. Signed-off-by:
-
Yuval Mintz authored
Populate the various operation structures meant for IPv6 with logic unique to that protocol suite. Signed-off-by:
-
Yuval Mintz authored
spectrum_router and spectrum_mr have several APIs that are used to manipulate configurations originating from ipmr fib notifications. Following previous patches all the protocol-specifics that are necessary for the configuration are hidden within spectrum_mr. This allows us to clean the API and make sure that other than choosing the mr_table based on the fib notification family, spectrum_router wouldn't care about the source of the notification when passing it onward to spectrum_mr. This would later allow us to leverage the same code for fib notifications originating from ip6mr. Signed-off-by:
-
Yuval Mintz authored
Current multicast routing logic in driver assumes it's always meant to deal with IPv4 multicast routes, leaving several placeholders for later IPv6 support [currently usually WARN()]. This patch changes the driver's internal multicast route struct into holding a common mr_mfc instead of the IPv4 mfc_cache. The various placeholders are grouped into 2: - Functions that require only the common bits; These remain and the restriction for IPv4-only is lifted. - Function that require IPv4-specifics - for handling these functions we add sets of operations that encapsulate the protocol differences Signed-off-by: -
Yuval Mintz authored
A step toward offloading IPv6 routing, this adds an additional multicast routing table meant for IPv6 [with its underlying TCAM region] and populates the default rule for IPv6 multicast packets. Following this, ingress IPv6 multicast packets would be trapped and delivered to the host CPU. Signed-off-by:
-
Yuval Mintz authored
Since commit c011ec1b ("mlxsw: spectrum: Add the multicast routing offloading logic") spectrum_mr did not populate the protocol portion of the catcahall_route_params; mr-tcam logic worked correctly for ipv4 since the enum value for MLXSW_SP_L3_PROTO_IPV4 is '0'. Explicitly fill the protocol as we'll soon need to differentiate between ipv4 and ipv6. Signed-off-by:
-
Yuval Mintz authored
Add new fields for the rmft register necessary for setting the IPv6 multicast FIB table. Add a matching wrapper function for filling the register in the IPv6 scenario. Signed-off-by:
-
Yuval Mintz authored
Similarly to what was done in commit 4af5964e ("mlxsw: reg: Configure RIF to forward IPv4 multicast packets by default") we now set two additional bits to allow IPv6 multicast forwarding. Signed-off-by:
-
