- 31 Jul, 2019 31 commits
-
-
Tony Nguyen authored
Update driver version to 0.7.5 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>
-
Akeem G Abodunrin authored
As a result of refactoring of VF VSIs interrupts code, there is no need to track its configuration status again with ICE_VF_STATE_CFG_INTR flag - In fact, it is not being checked anywhere in the code right now, so this patch removes the dead code as applicable to the flag. Signed-off-by:
Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Tested-by:
-
Brett Creeley authored
This flag is not needed and is called every time we re-enable interrupts in the hotpath so remove it. Also remove ice_vsi_req_irq() because it was a wrapper function for ice_vsi_req_irq_msix() whose sole purpose was checking the ICE_FLAG_MSIX_ENA flag. Signed-off-by:
Brett Creeley <brett.creeley@intel.com> Tested-by:
-
Akeem G Abodunrin authored
Since Tx rings are being managed by FW/NVM, Tx rings might have not been set up or driver had already wiped them off - In that case, call to disable LAN Tx queue is being returned as not in existence. This patch makes sure we don't return unnecessary error for such scenario. Signed-off-by:
-
Brett Creeley authored
Currently if the call to ice_alloc_mapped_page() fails we jump to the no_buf label, possibly call ice_release_rx_desc(), and return true indicating that there is more work to do. In the success case we just fall out of the while loop, possibly call ice_alloc_mapped_page(), and return false saying we exhausted cleaned_count. This flow can be improved by breaking if ice_alloc_mapped_page() fails and then the flow outside of the while loop is the same for the failure and success case. Signed-off-by:
-
Brett Creeley authored
Currently we are not reporting dropped counts at the port level to ethtool or netlink. This was found when debugging Rx dropped issues and the total packets sent did not equal the total packets received minus the rx_dropped, which was very confusing. To determine dropped counts at the port level we need to read the PRTRPB_RDPC register. To fix reporting we will store the dropped counts in the PF's rx_discards. This will be reported to netlink by storing it in the PF VSI's rx_missed_errors signaling that the receiver missed the packet. Also, we will report this to ethtool in the rx_dropped.nic field. Signed-off-by:
-
Akeem G Abodunrin authored
In case there is a request from a VF to change its number of queues, and the request was successful, we need to update number of queues configured on the VF before updating corresponding VSI for that VF, especially LAN Tx queue tree and TC update, otherwise, we would continued to use old value of vf->num_vf_qs for allocated Tx/Rx queues... Signed-off-by:
-
Akeem G Abodunrin authored
This patch uses allocated number of Tx queues per VSI to set up its scheduling tree instead of using total number of available Tx queues. Only PF VSIs have total number of allocated Tx queues equal to number of available Tx queues, other VSIs have different number of queues configured. Signed-off-by:
-
Brett Creeley authored
Currently we bump the Rx tail and release/give buffers to hardware every 16 descriptors. This causes us to bump Rx tail up to 4 times per napi_poll call. Also we are always bumping tail on an odd index and this is a problem because hardware ignores the lower 3 bits in the QRX_TAIL register. This is making it so hardware sees tail bumps only every 8 descriptors. Instead lets only bump Rx tail once per napi_poll if the value aligns with hardware's expectations of the lower 3 bits being cleared. Also only release/give Rx buffers once per napi_poll call. Signed-off-by:
-
Akeem G Abodunrin authored
This patch adds code to clear VFs enable status until reset is completed, and Tx/Rx rings are setup. Without this patch, the code flow request Tx queues to be disabled after reset, especially PFR - where VF VSI Tx rings have already been wiped off in the NVM and result to adminq error based on the call to disable Tx LAN queue in ice_reset_all_vfs function call. Signed-off-by:
-
Tony Nguyen authored
The firmware reports an error when trying to configure a port with no media. Instead of always configuring the port, check for media before attempting to configure it. In the absence of media, turn off link and poll for media to become available before re-enabling link. Move ice_force_phys_link_state() up to avoid forward declaration. Signed-off-by:
-
Jacob Keller authored
The ice_init_all_ctrlq and ice_shutdown_all_ctrlq functions create and destroy the locks used to protect the send and receive process of each control queue. This is problematic, as the driver may use these functions to shutdown and re-initialize the control queues at run time. For example, it may do this in response to a device reset. If the driver failed to recover from a reset, it might leave the control queues offline. In this case, the locks will no longer be initialized. A later call to ice_sq_send_cmd will then attempt to acquire a lock that has been destroyed. It is incorrect behavior to access a lock that has been destroyed. Indeed, ice_aq_send_cmd already tries to avoid accessing an offline control queue, but the check occurs inside the lock. The root of the problem is that the locks are destroyed at run time. Modify ice_init_all_ctrlq and ice_shutdown_all_ctrlq such that they no longer create or destroy the locks. Introduce new functions, ice_create_all_ctrlq and ice_destroy_all_ctrlq. Call these functions in ice_init_hw and ice_deinit_hw. Now, the control queue locks will remain valid for the life of the driver, and will not be destroyed until the driver unloads. This also allows removing a duplicate check of the sq.count and rq.count values when shutting down the controlqs. The ice_shutdown_ctrlq function already checks this value under the lock. Previously commit dec64ff1 ("ice: use [sr]q.count when checking if queue is initialized") needed this check to happen outside the lock, because it prevented duplicate attempts at destroying the locks. The driver may now safely use ice_init_all_ctrlq and ice_shutdown_all_ctrlq while handling reset events, without causing the locks to be invalid. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
-
Brett Creeley authored
Currently we are always setting prefena to 0. This is causing the hardware to only fetch descriptors when there are none free in the cache for a received packet instead of prefetching when it has used the last descriptor regardless of incoming packets. Fix this by allowing the hardware to prefetch Rx descriptors. Signed-off-by:
-
Tony Nguyen authored
When interrupt tracking was refactored, during rebuild, the call to ice_vsi_setup_vector_base() was inadvertently removed from the PF VSI instead of being removed from the VF VSI. During reset, the failure to properly setup the vector base generates a call trace. Correct this so that resets/rebuilds properly complete. Fixes: cbe66bfe ("ice: Refactor interrupt tracking") Signed-off-by:
-
Jacob Keller authored
Currently, ice_stat_update32 and ice_stat_update40 will limit the value of the software statistic to 32 or 40 bits wide, depending on which register is being read. This means that if a driver is running for a long time, the displayed software register values will roll over to zero at 40 bits or 32 bits. This occurs because the functions directly assign the difference between the previous value and current value of the hardware statistic. Instead, add this value to the current software statistic, and then update the previous value. In this way, each time ice_stat_update40 or ice_stat_update32 are called, they will increment the software tracking value by the difference of the hardware register from its last read. The software tracking value will correctly count up until it overflows a u64. The only requirement is that the ice_stat_update functions be called at least once each time the hardware register overflows. While we're fixing ice_stat_update40, modify it to use rd64 instead of two calls to rd32. Additionally, drop the now unnecessary hireg function parameter. Signed-off-by:
-
Paul Greenwalt authored
Add support for reporting link partner advertising when ETHTOOL_GLINKSETTINGS defined. Get pause param reports the Tx/Rx pause configured, and then ethtool issues ETHTOOL_GSET ioctl and ice_get_settings_link_up reports the negotiated Tx/Rx pause. Negotiated pause frame report per IEEE 802.3-2005 table 288-3. $ ethtool --show-pause ens6f0 Pause parameters for ens6f0: Autonegotiate: on RX: on TX: on RX negotiated: on TX negotiated: on $ ethtool ens6f0 Settings for ens6f0: Supported ports: [ FIBRE ] Supported link modes: 25000baseCR/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: None BaseR RS Advertised link modes: 25000baseCR/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: None BaseR RS Link partner advertised link modes: Not reported Link partner advertised pause frame use: Symmetric Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 25000Mb/s Duplex: Full Port: Direct Attach Copper PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: g Wake-on: g Current message level: 0x00000007 (7) drv probe link Link detected: yes When ETHTOOL_GLINKSETTINGS is not defined, get pause param reports the negotiated Tx/Rx pause. Signed-off-by:Paul Greenwalt <paul.greenwalt@intel.com> Tested-by:
-
YueHaibing authored
While do COMPILE_TEST build without CONFIG_NETDEVICES, we get Kconfig warning: WARNING: unmet direct dependencies detected for PHYLIB Depends on [n]: NETDEVICES [=n] Selected by [y]: - OCTEON_ETHERNET [=y] && STAGING [=y] && (CAVIUM_OCTEON_SOC && NETDEVICES [=n] || COMPILE_TEST [=y]) Reported-by:
Hulk Robot <hulkci@huawei.com> Reported-by:
Mark Brown <broonie@kernel.org> Fixes: 171a9bae ("staging/octeon: Allow test build on !MIPS") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Merge tag 'mac80211-next-for-davem-2019-07-31' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== We have a reasonably large number of changes: * lots more HE (802.11ax) support, particularly things relevant for the the AP side, but also mesh support * debugfs cleanups from Greg * some more work on extended key ID * start using genl parallel_ops, as preparation for weaning ourselves off RTNL and getting parallelism * various other changes all over ==================== Signed-off-by:
-
David S. Miller authored
Petr Machata says: ==================== mlxsw: Test coverage for DSCP leftover fix This patch set fixes some global scope pollution issues in the DSCP tests (in patch #1), and then proceeds (in patch #2) to add a new test for checking whether, after DSCP prioritization rules are removed from a port, DSCP rewrites consistently to zero, instead of the last removed rule still staying in effect. ==================== Signed-off-by: -
Petr Machata authored
Commit dedfde2f ("mlxsw: spectrum_dcb: Configure DSCP map as the last rule is removed") fixed a problem in mlxsw where last DSCP rule to be removed remained in effect when DSCP rewrite was applied. Add a selftest that covers this problem. Signed-off-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
-
Petr Machata authored
These two tests have some problems in the global scope pollution and on contrary, contain unnecessary local declarations. Fix them. Signed-off-by:
-
Ding Xiang authored
"error" is unneeded,just return 0 Signed-off-by:
Ding Xiang <dingxiang@cmss.chinamobile.com> Signed-off-by:
-
Christophe JAILLET authored
A few lines above, we have: tx_size = BIT(tx->order); So use 'tx_size' directly to be consistent with the way 'rx->descs_cpu' and 'rx->descs_dma' are computed below. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Shay Bar authored
In case of HE AP-STA link, ieee80211_send_nullfunc() will not send the QOS NULL packet to check if AP is still associated. In this case, probe_send_count will be non-zero and ieee80211_sta_work() will later disassociate the AP, even though no packet was ever sent. Fix this by decrementing probe_send_count and not calling ieee80211_send_nullfunc() in case of HE link, so that we still wait for some time for the AP beacon to reappear and don't disconnect right away. Signed-off-by:
Shay Bar <shay.bar@celeno.com> Link: https://lore.kernel.org/r/20190703131848.22879-1-shay.bar@celeno.com [clarify commit message] Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
John Crispin authored
Store the OBSS PD parameters inside bss_conf when bringing up an AP and/or when a station connects to an AP. This allows the driver to configure the HW accordingly. Signed-off-by:
John Crispin <john@phrozen.org> Link: https://lore.kernel.org/r/20190730163701.18836-3-john@phrozen.orgSigned-off-by:
-
Johannes Berg authored
Add a strict start type so all new attributes starting from NL80211_ATTR_HE_OBSS_PD are validated strictly. Signed-off-by: -
John Crispin authored
Add the data structure, policy and parsing code allowing userland to send the OBSS PD information into the kernel. Signed-off-by:
-
Karthikeyan Periyasamy authored
This came up in fuzz testing, and really we don't consider all-zeroes to be a valid MAC address in most places, so also reject it here to avoid confusion later on. Signed-off-by:
Karthikeyan Periyasamy <periyasa@codeaurora.org> Link: https://lore.kernel.org/r/1563959770-21570-1-git-send-email-periyasa@codeaurora.org [rewrite commit message] Signed-off-by:
-
Johannes Berg authored
Over time, we really need to get rid of all of our global locking. One of the things needed is to use parallel_ops. This isn't really the most important (RTNL is much more important) but OTOH we just keep adding uses of genl_family_attrbuf() now. Use .parallel_ops to disallow this. Reviewed-By:
Denis Kenzior <denkenz@gmail.com> Link: https://lore.kernel.org/r/20190729143109.18683-1-johannes@sipsolutions.netSigned-off-by:
-
Johannes Berg authored
Give a proper boottime_ns value for netlink RX to avoid scan issues here. Signed-off-by:
-
Colin Ian King authored
The return from ieee80211_get_sband can potentially be a null pointer, so it seems prudent to add a null check to avoid a null pointer dereference on sband. Addresses-Coverity: ("Dereference null return") Fixes: 2ab45876 ("mac80211: add support for the ADDBA extension element") Signed-off-by:Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20190730143205.14261-1-colin.king@canonical.comSigned-off-by:
-
- 30 Jul, 2019 9 commits
-
-
David S. Miller authored
Marek Vasut says: ==================== net: dsa: ksz: Add Microchip KSZ87xx support This series adds support for Microchip KSZ87xx switches, which are slightly simpler compared to KSZ9xxx . ==================== Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Tristram Ha authored
Add Microchip KSZ8795 DSA driver. Signed-off-by:
Tristram Ha <Tristram.Ha@microchip.com> Signed-off-by:
-
Tristram Ha authored
Add DSA tag code for Microchip KSZ8795 switch. The switch is simpler and the tag is only 1 byte, instead of 2 as is the case with KSZ9477. Signed-off-by:
-
Marek Vasut authored
Document Microchip KSZ87xx family switches. These include KSZ8765 - 5 port switch KSZ8794 - 4 port switch KSZ8795 - 5 port switch Signed-off-by:
-
David S. Miller authored
Stefano Garzarella says: ==================== vsock/virtio: optimizations to increase the throughput This series tries to increase the throughput of virtio-vsock with slight changes. While I was testing the v2 of this series I discovered an huge use of memory, so I added patch 1 to mitigate this issue. I put it in this series in order to better track the performance trends. v5: - rebased all patches on net-next - added Stefan's R-b and Michael's A-b v4: https://patchwork.kernel.org/cover/11047717 v3: https://patchwork.kernel.org/cover/10970145 v2: https://patchwork.kernel.org/cover/10938743 v1: https://patchwork.kernel.org/cover/10885431 Below are the benchmarks step by step. I used iperf3 [1] modified with VSOCK support. As Michael suggested in the v1, I booted host and guest with 'nosmap'. A brief description of patches: - Patches 1: limit the memory usage with an extra copy for small packets - Patches 2+3: reduce the number of credit update messages sent to the transmitter - Patches 4+5: allow the host to split packets on multiple buffers and use VIRTIO_VSOCK_MAX_PKT_BUF_SIZE as the max packet size allowed host -> guest [Gbps] pkt_size before opt p 1 p 2+3 p 4+5 32 0.032 0.030 0.048 0.051 64 0.061 0.059 0.108 0.117 128 0.122 0.112 0.227 0.234 256 0.244 0.241 0.418 0.415 512 0.459 0.466 0.847 0.865 1K 0.927 0.919 1.657 1.641 2K 1.884 1.813 3.262 3.269 4K 3.378 3.326 6.044 6.195 8K 5.637 5.676 10.141 11.287 16K 8.250 8.402 15.976 16.736 32K 13.327 13.204 19.013 20.515 64K 21.241 21.341 20.973 21.879 128K 21.851 22.354 21.816 23.203 256K 21.408 21.693 21.846 24.088 512K 21.600 21.899 21.921 24.106 guest -> host [Gbps] pkt_size before opt p 1 p 2+3 p 4+5 32 0.045 0.046 0.057 0.057 64 0.089 0.091 0.103 0.104 128 0.170 0.179 0.192 0.200 256 0.364 0.351 0.361 0.379 512 0.709 0.699 0.731 0.790 1K 1.399 1.407 1.395 1.427 2K 2.670 2.684 2.745 2.835 4K 5.171 5.199 5.305 5.451 8K 8.442 8.500 10.083 9.941 16K 12.305 12.259 13.519 15.385 32K 11.418 11.150 11.988 24.680 64K 10.778 10.659 11.589 35.273 128K 10.421 10.339 10.939 40.338 256K 10.300 9.719 10.508 36.562 512K 9.833 9.808 10.612 35.979 As Stefan suggested in the v1, I measured also the efficiency in this way: efficiency = Mbps / (%CPU_Host + %CPU_Guest) The '%CPU_Guest' is taken inside the VM. I know that it is not the best way, but it's provided for free from iperf3 and could be an indication. host -> guest efficiency [Mbps / (%CPU_Host + %CPU_Guest)] pkt_size before opt p 1 p 2+3 p 4+5 32 0.35 0.45 0.79 1.02 64 0.56 0.80 1.41 1.54 128 1.11 1.52 3.03 3.12 256 2.20 2.16 5.44 5.58 512 4.17 4.18 10.96 11.46 1K 8.30 8.26 20.99 20.89 2K 16.82 16.31 39.76 39.73 4K 30.89 30.79 74.07 75.73 8K 53.74 54.49 124.24 148.91 16K 80.68 83.63 200.21 232.79 32K 132.27 132.52 260.81 357.07 64K 229.82 230.40 300.19 444.18 128K 332.60 329.78 331.51 492.28 256K 331.06 337.22 339.59 511.59 512K 335.58 328.50 331.56 504.56 guest -> host efficiency [Mbps / (%CPU_Host + %CPU_Guest)] pkt_size before opt p 1 p 2+3 p 4+5 32 0.43 0.43 0.53 0.56 64 0.85 0.86 1.04 1.10 128 1.63 1.71 2.07 2.13 256 3.48 3.35 4.02 4.22 512 6.80 6.67 7.97 8.63 1K 13.32 13.31 15.72 15.94 2K 25.79 25.92 30.84 30.98 4K 50.37 50.48 58.79 59.69 8K 95.90 96.15 107.04 110.33 16K 145.80 145.43 143.97 174.70 32K 147.06 144.74 146.02 282.48 64K 145.25 143.99 141.62 406.40 128K 149.34 146.96 147.49 489.34 256K 156.35 149.81 152.21 536.37 512K 151.65 150.74 151.52 519.93 [1] https://github.com/stefano-garzarella/iperf/ ==================== Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Stefano Garzarella authored
Since now we are able to split packets, we can avoid limiting their sizes to VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE. Instead, we can use VIRTIO_VSOCK_MAX_PKT_BUF_SIZE as the max packet size. Signed-off-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Stefan Hajnoczi <stefanha@redhat.com> Acked-by:
-
Stefano Garzarella authored
If the packets to sent to the guest are bigger than the buffer available, we can split them, using multiple buffers and fixing the length in the packet header. This is safe since virtio-vsock supports only stream sockets. Signed-off-by:
-
Stefano Garzarella authored
fwd_cnt and last_fwd_cnt are protected by rx_lock, so we should use the same spinlock also if we are in the TX path. Move also buf_alloc under the same lock. Signed-off-by:
-
Stefano Garzarella authored
In order to reduce the number of credit update messages, we send them only when the space available seen by the transmitter is less than VIRTIO_VSOCK_MAX_PKT_BUF_SIZE. Signed-off-by:
-
