- 30 Apr, 2017 26 commits
-
-
Eli Cohen authored
struct esw_mc_addr is a small struct that can be part of struct mlx5_eswitch. Define it as a field and not as a pointer and save the kzalloc call and then error flow handling. Signed-off-by:
Eli Cohen <eli@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com>
-
Eran Ben Elisha authored
We will activate the HW LRO only on servers with PCI BW > MAX LINK BW, or when PCI BW > 16Gbps. On other cases we do not want LRO by default as LRO sessions might get timeout and add redundant software overhead. Tested: ethtool -k <ifs-name> | grep large-receive-offload On systems with and without the limitations. Signed-off-by:
Eran Ben Elisha <eranbe@mellanox.com> Cc: kernel-team@fb.com Signed-off-by:
-
Tariq Toukan authored
CQE ownership indication is as small as a single bit. Use u8 to speedup the comparison. Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Cc: kernel-team@fb.com Signed-off-by:
-
Tariq Toukan authored
"prefetchw()" prefetches the cacheline for write. Use it for skb->data, as soon we'll be copying the packet header there. Performance: Single-stream packet-rate tested with pktgen. Packets are dropped in tc level to zoom into driver data-path. Larger gain is expected for smaller packets, as less time is spent on handling SKB fragments, making the path shorter and the improvement more significant. --------------------------------------------- packet size | before | after | gain | 64B | 4,113,306 | 4,778,720 | 16% | 1024B | 3,633,819 | 3,950,593 | 8.7% | Signed-off-by:
-
Tariq Toukan authored
UMR operations are more frequent and important. Check them first, and add a compiler branch predictor hint. According to current design, ICOSQ CQ can contain at most one pending CQE per napi. Poll function is optimized accordingly. Performance: Single-stream packet-rate tested with pktgen. Packets are dropped in tc level to zoom into driver data-path. Larger gain is expected for larger packet sizes, as BW is higher and UMR posts are more frequent. --------------------------------------------- packet size | before | after | gain | 64B | 4,092,370 | 4,113,306 | 0.5% | 1024B | 3,421,435 | 3,633,819 | 6.2% | Signed-off-by:
-
Hadar Hen Zion authored
The user can change delay_first_probe_time parameter through sysctl. Listen to NETEVENT_DELAY_PROBE_TIME_UPDATE notifications and update the intervals for updating the neighbours 'used' value periodic task and for flow HW counters query periodic task. Both of the intervals will be update only in case the new delay prob time value is lower the current interval. Since the driver saves only one min interval value and not per device, the users will be able to set lower interval value for updating neighbour 'used' value periodic task but they won't be able to schedule a higher interval for this periodic task. The used interval for scheduling neighbour 'used' value periodic task is the minimal delay prob time parameter ever seen by the driver. Signed-off-by:
Hadar Hen Zion <hadarh@mellanox.com> Reviewed-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
-
Hadar Hen Zion authored
When IP tunnel encapsulation rules are offloaded, the kernel can't see the traffic of the offloaded flow. The neighbour for the IP tunnel destination of the offloaded flow can mistakenly become STALE and deleted by the kernel since its 'used' value wasn't changed. To make sure that a neighbour which is used by the HW won't become STALE, we proactively update the neighbour 'used' value every DELAY_PROBE_TIME period, when packets were matched and counted by the HW for one of the tunnel encap flows related to this neighbour. The periodic task that updates the used neighbours is scheduled when a tunnel encap rule is successfully offloaded into HW and keeps re-scheduling itself as long as the representor's neighbours list isn't empty. Add, remove, lookup and status change operations done over the representor's neighbours list or the neighbour hash entry encaps list are all serialized by RTNL lock. Signed-off-by:
-
Hadar Hen Zion authored
In order to offload TC encap rules, the driver does a lookup for the IP tunnel neighbour according to the output device and the destination IP given by the user. To keep tracking after the validity state of such neighbours, we keep the neighbours information (pair of device pointer and destination IP) in a hash table maintained at the relevant egress representor and register to get NETEVENT_NEIGH_UPDATE events. When getting neighbour update netevent, we search for a match among the cached neighbours entries used for encapsulation. In case the neighbour isn't valid, we can't offload the flow into the HW. We cache the flow (requested matching and actions) in the driver and offload the rule later, when the neighbour is resolved and becomes valid. When a flow is only cached in the driver and not offloaded into HW yet, we use EAGAIN return value to mark it internally, the TC ndo still returns success. Listen to kernel neighbour update netevents to trace relevant neighbours validity state: 1. If a neighbour becomes valid, offload the related rules to HW. 2. If the neighbour becomes invalid, remove the related rules from HW. 3. If the neighbour mac address was changed, update the encap header. Remove all the offloaded rules using the old encap header from the HW and insert new rules to HW with updated encap header. Access to the neighbors hash table is protected by RTNL lock of its caller or by the table's spinlock. Details of the locking/synchronization among the different actions applied on the neighbour table: Add/remove operations - protected by RTNL lock of its caller (all TC commands are protected by RTNL lock). Add and remove operations are initiated only when the user inserts/removes a TC rule into/from the driver. Lookup/remove operations - since the lookup operation is done from netevent notifier block, RTNL lock can't be used (atomic context). Use the table's spin lock to protect lookups from TC user removal operation. bh is used since netevent can be called from a softirq context. Lookup/add operations - The hash table access functions are taking care of the protection between lookup and add operations. When adding/removing encap headers and rules to/from the HW, RTNL lock is used. It can happen when: 1. The user inserts/removes a TC rule into/from the driver (TC commands are protected by RTNL lock of it's caller). 2. The driver gets neighbour notification event, which reports about neighbour validity status change. Before adding/removing encap headers and rules to/from the HW, RTNL lock is taken. A neighbour hash table entry should be freed when its encap list is empty. Since The neighbour update netevent notification schedules a neighbour update work that uses the neighbour hash entry, it can't be freed unconditionally when the encap list becomes empty during TC delete rule flow. Use reference count to protect from freeing neighbour hash table entry while it's still in use. When the user asks to unregister a netdvice used by one of the neigbours, neighbour removal notification is received. Then we take a reference on the neighbour and don't free it until the relevant encap entries (and flows) are marked as invalid (not offloaded) and removed from HW. As long as the encap entry is still valid (checked under RTNL lock) we can safely access the neighbour device saved on mlx5e_neigh struct. Signed-off-by:
-
Hadar Hen Zion authored
Add hash table to the representors which is to be used by the next patch to save neighbours information in the driver. In order to offload IP tunnel encapsulation rules, the driver must find the tunnel dst neighbour according to the output device and the destination address given by the user. The next patch will cache the neighbors information in the driver to allow support in neigh update flow for tunnel encap rules. The neighbour entries are also saved in a list so we easily iterate over them when querying statistics in order to provide 'used' feedback to the kernel neighbour NUD core. Signed-off-by:
-
Hadar Hen Zion authored
The nud_state and hardware address fields are protected by the neighbour lock, we should acquire it before accessing those parameters. Use this lock to avoid inconsistency between the neighbour validity state and it's hardware address. Signed-off-by:
-
Hadar Hen Zion authored
Instead of relaying on the 'flow->rule' pointer value which can be valid or invalid (in case the FW returns an error while trying to offload the rule), monitor the rule state using a flag. In downstream patch which adds support to IP tunneling neigh update flow, a TC rule could be cached in the driver and not offloaded into the HW. In this case, the flow handle pointer stays NULL. Check the offloaded flag to properly deal with rules which are currently not offloaded when querying rule statistics. This patch doesn't add any new functionality. Signed-off-by:
-
Hadar Hen Zion authored
Passing output device parameter to the helper functions that deal with creation of encapsulation headers is redundant. Output device parameter can be defined inside those helpers, no need to pass it. Refactor the code by removing the parameter from the function signature. This patch doesn't change any functionality. Signed-off-by:
-
Or Gerlitz authored
The encap entry structure isn't manipulated by the eswitch code, hence it can/needs to be removed from the eswitch header. Do that, and change it to have mlx5e_ prefix. This patch doesn't change any functionality. Signed-off-by:
-
Or Gerlitz authored
Encap wise, the tc eswitch flow attribute struct needs to have only the encap ID which is programmed later to the HW and none of the higher level encap params, fix that. This patch doesn't change any functionality. Signed-off-by:
-
Saeed Mahameed authored
Make representor netdev private data extendable by adding new struct "mlx5e_rep_priv" and use it as the rep netdev private data struct instead of directly pointing to mlx5_eswitch_rep. Added new en_rep.h header file to contain all representor related definitions and prototypes, and moved all representor specific logic into en_rep.c. Needed for downstream patches to extend representor functionality to support neighbour update. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 10GbE Intel Wired LAN Driver Updates 2017-04-29 This series contains updates to ixgbe and ixgbevf only, most notable is the addition of XDP support to our 10GbE drivers. Paul fixes ixgbe to acquire the PHY semaphore before accessing PHY registers when issuing a device reset. John adds XDP support (yeah!) for ixgbe. Emil fixes an issue by flushing the MACVLAN filters on VF reset to avoid conflicts with other VFs that may end up using the same MAC address. Also fixed a bug where ethtool -S displayed some empty fields for ixgbevf because it was using ixgbe_stats instead ixgbevf_stats for IXGBEVF_QUEUE_STATS_LEN. Tony adds the ability to specify a zero MAC address in order to clear the VF's MAC address from the RAR table. Also adds support for a new 1000Base-T device based on x550EM_X MAC type. Fixed an issue where the RSS key specified by the user would be over-written with a pre-existing value, so change the rss_key to a pointer so we can check to see if the key has a value set before attempting to set it. Fixed the logic for mailbox support for getting RETA and RSS values, which are only supported by 82599 and x540 devices. v2: fixed up patches #2 and #3 based on feedback from Jakub and to address build issues when page sizes are larger than 4k ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Tony Nguyen authored
The RSS key is being repopulated every time the interface is brought up regardless of whether there is an existing value. If the user sets the RSS key and the interface is brought up (e.g. reset), the user specified RSS key will be overwritten. This patch changes the rss_key to a pointer so we can check to see if the key has been populated and preserve it accordingly. Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Tony Nguyen authored
Mailbox support for getting RETA and RSS is available for only 82599 and x540; a previous patch reversed the logic and these adapters were returning not supported. Also, the NACK check in ixgbevf_get_rss_key_locked() was checking for the command IXGBE_VF_GET_RETA instead of IXGBE_VF_GET_RSS_KEY. This patch corrects both issues by correcting the logic and checking for the right command. Signed-off-by:
-
Tony Nguyen authored
The RSS key is being repopulated every time the interface is brought up regardless of whether there is an existing value. If the user sets the RSS key and the interface is brought up (e.g. reset), the user specified RSS key will be overwritten. This patch changes the rss_key to a pointer so we can check to see if the key has been populated and preserve it accordingly. Signed-off-by:
-
Paul Greenwalt authored
Add support for new 1000Base-T device based on X550EM_X MAC type. All PHY operations are disabled as the PHY is controlled by FW. Signed-off-by:
Paul Greenwalt <paul.greenwalt@intel.com> Tested-by:
Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by:
-
Tony Nguyen authored
Currently, there is no logic that allows a VF's MAC address to be removed from the RAR table. Allow the user to specify a zero MAC address in order to clear the VF's MAC address from the RAR table. This functionality is also utilized by libvirt when removing VFs. Signed-off-by:
-
Emil Tantilov authored
IXGBEVF_QUEUE_STATS_LEN is based on ixgebvf_stats, not ixgbe_stats. This change fixes a bug where ethtool -S displayed some empty fields. Signed-off-by:
Emil Tantilov <emil.s.tantilov@intel.com> Tested-by:
-
Emil Tantilov authored
Flush the macvlan filters on VF reset to avoid conflict with other VFs that may end up using the same MAC address. The main change here is the call to ixgbe_set_vf_macvlan() with index 0. Moved ixgbe_set_vf_macvlan() in front of ixgbe_vf_reset_event() to avoid adding a prototype. Reported-by:
Sritej Kanakadandi Sritej Rama <skanakad@cisco.com> Signed-off-by:
-
John Fastabend authored
Current XDP implementation hits the tail on every XDP_TX return code. This patch changes driver behavior to only hit the tail after packet processing is complete. With this patch I can run XDP drop programs @ 14+Mpps and XDP_TX programs are at ~13.5Mpps. Signed-off-by:
John Fastabend <john.r.fastabend@intel.com> Tested-by:
-
John Fastabend authored
A couple design choices were made here. First I use a new ring pointer structure xdp_ring[] in the adapter struct instead of pushing the newly allocated XDP TX rings into the tx_ring[] structure. This means we have to duplicate loops around rings in places we want to initialize both TX rings and XDP rings. But by making it explicit it is obvious when we are using XDP rings and when we are using TX rings. Further we don't have to do ring arithmatic which is error prone. As a proof point for doing this my first patches used only a single ring structure and introduced bugs in FCoE code and macvlan code paths. Second I am aware this is not the most optimized version of this code possible. I want to get baseline support in using the most readable format possible and then once this series is included I will optimize the TX path in another series of patches. Signed-off-by:
-
John Fastabend authored
Basic XDP drop support for ixgbe. Uses READ_ONCE/xchg semantics on XDP programs instead of RCU primitives as suggested by Daniel Borkmann and Alex Duyck. v2: fix the build issues seen w/ XDP when page sizes are larger than 4K and made minor fixes based on feedback from Jakub Kicinski Signed-off-by:Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
-
- 29 Apr, 2017 1 commit
-
-
Paul Greenwalt authored
A recent firmware change fixed an issue to acquire the PHY semaphore before accessing PHY registers. This led to a case where SW can issue a device reset clearing the MDIO registers. This patch makes SW acquire the PHY semaphore before issuing a device reset. Signed-off-by:
-
- 28 Apr, 2017 13 commits
-
-
David S. Miller authored
Daniel Borkmann says: ==================== Misc BPF updates This set cleans up ldimm64 leftovers from early eBPF days and adds couple of test cases related to this to the verifier test suite. It also cleans up the kallsyms spinlock (had same patch also in queue) by relaxing it through switching to _bh variant. It fixes up test_progs in relation to htons/ntohs and adds accessor macros for the percpu tests in test_maps. ==================== Signed-off-by: -
Daniel Borkmann authored
To overcome bugs as described and fixed in 89087c45 ("bpf: Fix values type used in test_maps"), provide a generic BPF_DECLARE_PERCPU() and bpf_percpu() accessor macro for all percpu map values used in tests. Declaring variables works as follows (also works for structs): BPF_DECLARE_PERCPU(uint32_t, my_value); They can then be accessed normally as uint32_t type through: bpf_percpu(my_value, <cpu_nr>) For example: bpf_percpu(my_value, 0)++; Implicitly, we make sure that the passed type is allocated and aligned by gcc at least on a 8-byte boundary, so that it works together with the map lookup/update syscall for percpu maps. We use it as a usage example in test_maps, so that others are free to adapt this into their code when necessary. Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Daniel Borkmann authored
Dave reported that on sparc test_progs generates buggy swapped eth->h_proto protocol comparisons: 10: (15) if r3 == 0xdd86 goto pc+9 R0=imm2,min_value=2,max_value=2 R1=pkt(id=0,off=0,r=14) R2=pkt_end R3=inv R4=pkt(id=0,off=14,r=14) R5=inv56 R10=fp This is due to the unconditional ... #define htons __builtin_bswap16 #define ntohs __builtin_bswap16 ... in test_progs that causes this. Make use of asm/byteorder.h and use __constant_htons() where possible and only perform the bswap16 when on little endian in non-constant case. Fixes: 6882804c ("selftests/bpf: add a test for overlapping packet range checks") Fixes: 37821613 ("selftests/bpf: add l4 load balancer test based on sched_cls") Reported-by:
-
Hannes Frederic Sowa authored
Hannes rightfully spotted that the bpf_lock doesn't need to be irqsave variant. We never perform any such updates where this would be necessary (neither right now nor in future), therefore relax this further. Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Daniel Borkmann authored
Add several test cases around ldimm64, fp arithmetic and direct packet access. Signed-off-by:
-
Daniel Borkmann authored
For both cases, the verifier is already rejecting such invalid formed instructions. Thus, remove these artifacts from old times and align it with ppc64, sparc64 and s390x JITs that don't have them in the first place. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-nextDavid S. Miller authored
Steffen Klassert says: ==================== pull request (net-next): ipsec-next 2017-04-28 Just one patch to fix a misplaced spin_unlock_bh in an error path. Please pull or let me know if there are problems. ==================== Signed-off-by: -
David S. Miller authored
Merge tag 'mac80211-next-for-davem-2017-04-28' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== Another set of patches for -next: * API support for concurrent scheduled scan requests * API changes for roaming reporting * BSS max idle support in mac80211 * API changes for TX status reporting in mac80211 * API changes for RX rate reporting in mac80211 * rewrite monitor logic to prepare for BPF filters * bugfix for rare devices without 2.4 GHz support * a bugfix for recent DFS changes * some further cleanups The API changes are actually at a nice time, since it's typically quiet just before the merge window, and trees can be synchronized easily during it. ==================== Signed-off-by:
-
Herbert Xu authored
The commit 6d684e54 ("rhashtable: Cap total number of entries to 2^31") breaks rhashtable users that do not set max_size. This is because when max_size is zero max_elems is also incorrectly set to zero instead of 2^31. This patch fixes it by only lowering max_elems when max_size is not zero. Fixes: 6d684e54 ("rhashtable: Cap total number of entries to 2^31") Reported-by:
Florian Fainelli <f.fainelli@gmail.com> Reported-by:
kernel test robot <fengguang.wu@intel.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Arend Van Spriel authored
Have proper request id filled in the SCHED_SCAN_RESULTS and SCHED_SCAN_STOPPED notifications toward user-space by having the driver provide it through the api. Reviewed-by:
Hante Meuleman <hante.meuleman@broadcom.com> Reviewed-by:
Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by:
Franky Lin <franky.lin@broadcom.com> Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Avraham Stern authored
Parse the BSS max idle period element and set the BSS configuration accordingly so the driver can use this information to configure the max idle period and to use protected management frames for keep alive when required. The BSS max idle period element is defined in IEEE802.11-2016, section 9.4.2.79 Signed-off-by:
Avraham Stern <avraham.stern@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Avraham Stern authored
cfg80211_roamed() and cfg80211_roamed_bss() take the same arguments except that cfg80211_roamed() requires the BSSID and cfg80211_roamed_bss() requires the bss entry. Unify the two functions by using a struct for driver initiated roaming information so that either the BSSID or the bss entry can be passed as an argument to the unified function. Signed-off-by:
-
Mohammed Shafi Shajakhan authored
Existing API 'ieee80211_get_sdata_band' returns default 2 GHz band even if the channel context configuration is NULL. This crashes for chipsets which support 5 Ghz alone when it tries to access members of 'sband'. Channel context configuration can be NULL in multivif case and when channel switch is in progress (or) when it fails. Fix this by replacing the API 'ieee80211_get_sdata_band' with 'ieee80211_get_sband' which returns a NULL pointer for sband when the channel configuration is NULL. An example scenario is as below: In multivif mode (AP + STA) with drivers like ath10k, when we do a channel switch in the AP vif (which has a number of clients connected) and a STA vif which is connected to some other AP, when the channel switch in AP vif fails, while the STA vifs tries to connect to the other AP, there is a window where the channel context is NULL/invalid and this results in a crash while the clients connected to the AP vif tries to reconnect and this race is very similar to the one investigated by Michal in https://patchwork.kernel.org/patch/3788161/ and this does happens with hardware that supports 5Ghz alone after long hours of testing with continuous channel switch on the AP vif ieee80211 phy0: channel context reservation cannot be finalized because some interfaces aren't switching wlan0: failed to finalize CSA, disconnecting wlan0-1: deauthenticating from 8c:fd:f0:01:54:9c by local choice (Reason: 3=DEAUTH_LEAVING) WARNING: CPU: 1 PID: 19032 at net/mac80211/ieee80211_i.h:1013 sta_info_alloc+0x374/0x3fc [mac80211] [<bf77272c>] (sta_info_alloc [mac80211]) [<bf78776c>] (ieee80211_add_station [mac80211])) [<bf73cc50>] (nl80211_new_station [cfg80211]) Unable to handle kernel NULL pointer dereference at virtual address 00000014 pgd = d5f4c000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM PC is at sta_info_alloc+0x380/0x3fc [mac80211] LR is at sta_info_alloc+0x37c/0x3fc [mac80211] [<bf772738>] (sta_info_alloc [mac80211]) [<bf78776c>] (ieee80211_add_station [mac80211]) [<bf73cc50>] (nl80211_new_station [cfg80211])) Cc: Michal Kazior <michal.kazior@tieto.com> Signed-off-by:
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by:
-
