- 20 3月, 2021 4 次提交
-
-
由 Jiapeng Zhong 提交于
Fix the following coccicheck warnings: ./drivers/net/ethernet/intel/igc/igc_main.c:4961:2-14: WARNING: Assignment of 0/1 to bool variable. ./drivers/net/ethernet/intel/igc/igc_main.c:4955:2-14: WARNING: Assignment of 0/1 to bool variable. ./drivers/net/ethernet/intel/igc/igc_main.c:4933:1-13: WARNING: Assignment of 0/1 to bool variable. ./drivers/net/ethernet/intel/igc/igc_main.c:4592:1-24: WARNING: Assignment of 0/1 to bool variable. ./drivers/net/ethernet/intel/igc/igc_main.c:4438:2-25: WARNING: Assignment of 0/1 to bool variable. ./drivers/net/ethernet/intel/igc/igc_main.c:4396:2-25: WARNING: Assignment of 0/1 to bool variable. ./drivers/net/ethernet/intel/igc/igc_main.c:4018:2-25: WARNING: Assignment of 0/1 to bool variable. Reported-by: NAbaci Robot <abaci@linux.alibaba.com> Signed-off-by: NJiapeng Zhong <abaci-bugfix@linux.alibaba.com> Tested-by: NDvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Sasha Neftin 提交于
MII_CR_LOOPBACK masks not in use in i225 device and can be removed. Signed-off-by: NSasha Neftin <sasha.neftin@intel.com> Tested-by: NDvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Sasha Neftin 提交于
Force PHY speed not supported for i225 devices. MII_CR_SPEED masks not in use in i225 device and can be removed. Signed-off-by: NSasha Neftin <sasha.neftin@intel.com> Tested-by: NDvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Sasha Neftin 提交于
MII_CR_RESET mask not in use in i225 device and can be removed Signed-off-by: NSasha Neftin <sasha.neftin@intel.com> Tested-by: NDvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
- 18 3月, 2021 1 次提交
-
-
由 Alexander Duyck 提交于
Update the Intel drivers to make use of ethtool_sprintf. The general idea is to reduce code size and overhead by replacing the repeated pattern of string printf statements and ETH_STRING_LEN counter increments. Signed-off-by: NAlexander Duyck <alexanderduyck@fb.com> Acked-by: NJesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 16 3月, 2021 6 次提交
-
-
由 Chen Yu 提交于
Although there is platform issue of runtime suspend support on CNP, it would be more flexible to let the user decide whether to disable runtime or not because: 1. This can be done in userspace via echo on > /sys/devices/pci0000\:00/0000\:00\:1f.d/power/control 2. More and more NICs would support runtime suspend, disabling the runtime suspend on them by default would impact the validation. Only disable runtime suspend on CNP in case of any user space regression. Signed-off-by: NChen Yu <yu.c.chen@intel.com> Tested-by: NDvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Chen Yu 提交于
The NIC is put in runtime suspend status when there is no cable connected. As a result, it is safe to keep non-wakeup NIC in runtime suspended during s2ram because the system does not rely on the NIC plug event nor WoL to wake up the system. Besides that, unlike the s2idle, s2ram does not need to manipulate S0ix settings during suspend. This patch introduces the .prepare() for e1000e so that if the NIC is runtime suspended the subsequent suspend/resume hooks will be skipped so as to speed up the s2ram. The pm core will check whether the NIC is a wake up device so there's no need to check it again in .prepare(). DPM_FLAG_SMART_PREPARE flag should be set during probe to ask the pci subsystem to honor the driver's prepare() result. Besides, the NIC remains runtime suspended after resumed from s2ram as there is no need to resume it. Tested on i7-2600K with 82579V NIC Before the patch: e1000e 0000:00:19.0: pci_pm_suspend+0x0/0x160 returned 0 after 225146 usecs e1000e 0000:00:19.0: pci_pm_resume+0x0/0x90 returned 0 after 140588 usecs After the patch: echo disabled > //sys/devices/pci0000\:00/0000\:00\:19.0/power/wakeup becomes 0 usecs because the hooks will be skipped. Suggested-by: NKai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: NChen Yu <yu.c.chen@intel.com> Tested-by: NDvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Bhaskar Chowdhury 提交于
s/structue/structure/ Signed-off-by: NBhaskar Chowdhury <unixbhaskar@gmail.com> Acked-by: NRandy Dunlap <rdunlap@infradead.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Magnus Karlsson 提交于
Optimize ice_run_xdp_zc() for the XDP program verdict being XDP_REDIRECT in the xsk zero-copy path. This path is only used when having AF_XDP zero-copy on and in that case most packets will be directed to user space. This provides a little over 100k extra packets in throughput on my server when running l2fwd in xdpsock. Signed-off-by: NMagnus Karlsson <magnus.karlsson@intel.com> Tested-by: NGeorge Kuruvinakunnel <george.kuruvinakunnel@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Magnus Karlsson 提交于
Optimize ixgbe_run_xdp_zc() for the XDP program verdict being XDP_REDIRECT in the xsk zero-copy path. This path is only used when having AF_XDP zero-copy on and in that case most packets will be directed to user space. This provides a little under 100k extra packets in throughput on my server when running l2fwd in xdpsock. Signed-off-by: NMagnus Karlsson <magnus.karlsson@intel.com> Tested-by: NVishakha Jambekar <vishakha.jambekar@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Magnus Karlsson 提交于
Optimize i40e_run_xdp_zc() for the XDP program verdict being XDP_REDIRECT in the xsk zero-copy path. This path is only used when having AF_XDP zero-copy on and in that case most packets will be directed to user space. This provides a little over 100k extra packets in throughput on my server when running l2fwd in xdpsock. Signed-off-by: NMagnus Karlsson <magnus.karlsson@intel.com> Tested-by: NGeorge Kuruvinakunnel <george.kuruvinakunnel@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
- 11 3月, 2021 1 次提交
-
-
由 Vladimir Oltean 提交于
As explained in commit 29d98f54 ("net: enetc: allow hardware timestamping on TX queues with tc-etf enabled"), hardware TX timestamping requires an skb with skb->tstamp = 0. When a packet is sent with SO_TXTIME, the skb->skb_mstamp_ns corrupts the value of skb->tstamp, so the drivers need to explicitly reset skb->tstamp to zero after consuming the TX time. Create a helper named skb_txtime_consumed() which does just that. All drivers which offload TC_SETUP_QDISC_ETF should implement it, and it would make it easier to assess during review whether they do the right thing in order to be compatible with hardware timestamping or not. Suggested-by: NVinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Acked-by: NVinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 06 3月, 2021 1 次提交
-
-
由 Jia-Ju Bai 提交于
When iavf_process_config() fails, no error return code of iavf_init_get_resources() is assigned. To fix this bug, err is assigned with the return value of iavf_process_config(), and then err is checked. Reported-by: NTOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 05 3月, 2021 2 次提交
-
-
由 Dinghao Liu 提交于
When ixgbe_fdir_write_perfect_filter_82599() fails, input allocated by kzalloc() has not been freed, which leads to memleak. Signed-off-by: NDinghao Liu <dinghao.liu@zju.edu.cn> Reviewed-by: NPaul Menzel <pmenzel@molgen.mpg.de> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Antony Antony 提交于
Based on talks and indirect references ixgbe IPsec offlod do not support IPsec tunnel mode offload. It can only support IPsec transport mode offload. Now explicitly fail when creating non transport mode SA with offload to avoid false performance expectations. Fixes: 63a67fe2 ("ixgbe: add ipsec offload add and remove SA") Signed-off-by: NAntony Antony <antony@phenome.org> Acked-by: NShannon Nelson <snelson@pensando.io> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
- 23 2月, 2021 5 次提交
-
-
由 Henry Tieman 提交于
It was possible to have Rx queues that were not available for use by RSS. This would happen when increasing the number of Rx queues while there was a user defined RSS LUT. Always update the number of available RSS queues when changing the number of Rx queues. Fixes: 87324e74 ("ice: Implement ethtool ops for channels") Signed-off-by: NHenry Tieman <henry.w.tieman@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Dave Ertman 提交于
DCBX_CAP bits were not being adjusted when switching between SW and FW controlled LLDP. Adjust bits to correctly indicate which mode the LLDP logic is in. Fixes: b94b013e ("ice: Implement DCBNL support") Signed-off-by: NDave Ertman <david.m.ertman@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Brett Creeley 提交于
Currently if an AVF driver doesn't account for the possibility of a port VLAN when determining its max packet size then packets at MTU will be dropped. It is not the VF driver's responsibility to account for a port VLAN so fix this. To fix this, do the following: 1. Add a function that determines the max packet size a VF is allowed by using the port's max packet size and whether the VF is in a port VLAN. If a port VLAN is configured then a VF's max packet size will always be the port's max packet size minus VLAN_HLEN. Otherwise it will be the port's max packet size. 2. Use this function to verify the max packet size from the VF. 3. If there is a port VLAN configured then add 4 bytes (VLAN_HLEN) to the VF's max packet size configuration. Also, the VIRTCHNL_OP_GET_VF_RESOURCES message provides the capability to communicate a VF's max packet size. Use the new function for this purpose. Fixes: 1071a835 ("ice: Implement virtchnl commands for AVF support") Signed-off-by: NBrett Creeley <brett.creeley@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Brett Creeley 提交于
Currently the PF will only set a trusted VF as the default VSI when it requests FLAG_VF_UNICAST_PROMISC over VIRTCHNL. However, when FLAG_VF_MULTICAST_PROMISC is set it's expected that the trusted VF will see multicast packets that don't have a matching destination MAC in the devices internal switch. Fix this by setting the trusted VF as the default VSI if either FLAG_VF_UNICAST_PROMISC or FLAG_VF_MULTICAST_PROMISC is set. Fixes: 01b5e89a ("ice: Add VF promiscuous support") Signed-off-by: NBrett Creeley <brett.creeley@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Dave Ertman 提交于
In the driver currently, we are reporting max number of TCs to the DCBNL callback as a kernel define set to 8. This is preventing userspace applications performing DCBx to correctly down map the TCs from requested to actual values. Report the actual max TC value to userspace from the capability struct. Fixes: b94b013e ("ice: Implement DCBNL support") Signed-off-by: NDave Ertman <david.m.ertman@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
- 20 2月, 2021 2 次提交
-
-
由 Norbert Ciosek 提交于
Fixes the following sparse warnings: i40e_main.c:5953:32: warning: cast from restricted __le16 i40e_main.c:8008:29: warning: incorrect type in assignment (different base types) i40e_main.c:8008:29: expected unsigned int [assigned] [usertype] ipa i40e_main.c:8008:29: got restricted __le32 [usertype] i40e_main.c:8008:29: warning: incorrect type in assignment (different base types) i40e_main.c:8008:29: expected unsigned int [assigned] [usertype] ipa i40e_main.c:8008:29: got restricted __le32 [usertype] i40e_txrx.c:1950:59: warning: incorrect type in initializer (different base types) i40e_txrx.c:1950:59: expected unsigned short [usertype] vlan_tag i40e_txrx.c:1950:59: got restricted __le16 [usertype] l2tag1 i40e_txrx.c:1953:40: warning: cast to restricted __le16 i40e_xsk.c:448:38: warning: invalid assignment: |= i40e_xsk.c:448:38: left side has type restricted __le64 i40e_xsk.c:448:38: right side has type int Fixes: 2f4b411a ("i40e: Enable cloud filters via tc-flower") Fixes: 2a508c64 ("i40e: fix VLAN.TCI == 0 RX HW offload") Fixes: 3106c580 ("i40e: Use batched xsk Tx interfaces to increase performance") Fixes: 8f88b303 ("i40e: Add infrastructure for queue channel support") Signed-off-by: NNorbert Ciosek <norbertx.ciosek@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Mateusz Palczewski 提交于
Fix insufficient distinction between IPv4 and IPv6 addresses when creating a filter. IPv4 and IPv6 are kept in the same memory area. If IPv6 is added, then it's caught by IPv4 check, which leads to err -95. Fixes: 2f4b411a ("i40e: Enable cloud filters via tc-flower") Signed-off-by: NGrzegorz Szczurek <grzegorzx.szczurek@intel.com> Signed-off-by: NMateusz Palczewski <mateusz.palczewski@intel.com> Reviewed-by: NJaroslaw Gawin <jaroslawx.gawin@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
- 19 2月, 2021 6 次提交
-
-
由 Sylwester Dziedziuch 提交于
When creating VFs they were sometimes not getting resources. It was caused by not executing i40e_reset_all_vfs due to flag __I40E_VF_DISABLE being set on PF. Because of this IAVF was never able to finish setup sequence never getting reset indication from PF. Changed test_and_set_bit __I40E_VF_DISABLE in i40e_sync_filters_subtask to test_bit and removed clear_bit. This function should not set this bit it should only check if it hasn't been already set. Fixes: a7542b87 ("i40e: check __I40E_VF_DISABLE bit in i40e_sync_filters_subtask") Signed-off-by: NSylwester Dziedziuch <sylwesterx.dziedziuch@intel.com> Tested-by: NKonrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Mateusz Palczewski 提交于
Fix addition of VLAN filter for PF after enabling FW LLDP agent. Changing LLDP Agent causes FW to re-initialize per NVM settings. Remove default PF filter and move "Enable/Disable" to currently used reset flag. Without this patch PF would try to add MAC VLAN filter with default switch filter present. This causes AQ error and sets promiscuous mode on. Fixes: c65e78f8 ("i40e: Further implementation of LLDP") Signed-off-by: NPrzemyslaw Patynowski <przemyslawx.patynowski@intel.com> Signed-off-by: NMateusz Palczewski <mateusz.palczewski@intel.com> Reviewed-by: NSylwester Dziedziuch <sylwesterx.dziedziuch@intel.com> Reviewed-by: NAleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Mateusz Palczewski 提交于
During driver loading flow control settings were written to FW using a variable which was always zero, since it was being set only by ethtool. This behavior has been corrected and driver no longer overwrites the default FW/NVM settings. Fixes: 373149fc ("i40e: Decrease the scope of rtnl lock") Signed-off-by: NDawid Lukwinski <dawid.lukwinski@intel.com> Signed-off-by: NMateusz Palczewski <mateusz.palczewski@intel.com> Reviewed-by: NAleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Mateusz Palczewski 提交于
Zero-initialize AQ command data structures to comply with API specifications. Fixes: 2f4b411a ("i40e: Enable cloud filters via tc-flower") Fixes: f4492db1 ("i40e: Add NPAR BW get and set functions") Signed-off-by: NAndrzej Sawuła <andrzej.sawula@intel.com> Signed-off-by: NMateusz Palczewski <mateusz.palczewski@intel.com> Reviewed-by: NArkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Reviewed-by: NAleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Keita Suzuki 提交于
Struct i40e_veb is allocated in function i40e_setup_pf_switch, and stored to an array field veb inside struct i40e_pf. However when i40e_setup_misc_vector fails, this memory leaks. Fix this by calling exit and teardown functions. Signed-off-by: NKeita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Slawomir Laba 提交于
When a packet contains an IPv6 header with next header which is an extension header and not a protocol one, the kernel function skb_transport_header called with such sk_buff will return a pointer to the extension header and not to the TCP one. The above explained call caused a problem with packet processing for skb with encapsulation for tunnel with I40E_TX_CTX_EXT_IP_IPV6. The extension header was not skipped at all. The ipv6_skip_exthdr function does check if next header of the IPV6 header is an extension header and doesn't modify the l4_proto pointer if it points to a protocol header value so its safe to omit the comparison of exthdr and l4.hdr pointers. The ipv6_skip_exthdr can return value -1. This means that the skipping process failed and there is something wrong with the packet so it will be dropped. Fixes: a3fd9d88 ("i40e/i40evf: Handle IPv6 extension headers in checksum offload") Signed-off-by: NSlawomir Laba <slawomirx.laba@intel.com> Signed-off-by: NPrzemyslaw Patynowski <przemyslawx.patynowski@intel.com> Reviewed-by: NAleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
- 16 2月, 2021 2 次提交
-
-
由 Colin Ian King 提交于
The variable mfs_max is not initialized and is being compared to find the maximum value. Fix this by initializing it to 0. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: 90bc8e00 ("i40e: Add hardware configuration for software based DCB") Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Gustavo A. R. Silva 提交于
It seems that the right argument to be passed is &tcp_ip6_spec->ip6dst, not &tcp_ip6_spec->ip6src, when calling function ipv6_addr_any(). Addresses-Coverity-ID: 1501734 ("Copy-paste error") Fixes: efca91e8 ("i40e: Add flow director support for IPv6") Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 13 2月, 2021 10 次提交
-
-
由 Maciej Fijalkowski 提交于
Output of ixgbe_rx_offset() is based on ethtool's priv flag setting, which when changed, causes PF reset (disables napi, frees irqs, loads different Rx mem model, etc.). This means that within napi its result is constant and there is no reason to call it per each processed frame. Add new 'rx_offset' field to ixgbe_ring that is meant to hold the ixgbe_rx_offset() result and use it within ixgbe_clean_rx_irq(). Furthermore, use it within ixgbe_alloc_mapped_page(). Last but not least, un-inline the function of interest as it lives in .c file so let compiler do the decision about the inlining. Reviewed-by: NBjörn Töpel <bjorn.topel@intel.com> Signed-off-by: NMaciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Maciej Fijalkowski 提交于
Output of ice_rx_offset() is based on ethtool's priv flag setting, which when changed, causes PF reset (disables napi, frees irqs, loads different Rx mem model, etc.). This means that within napi its result is constant and there is no reason to call it per each processed frame. Add new 'rx_offset' field to ice_ring that is meant to hold the ice_rx_offset() result and use it within ice_clean_rx_irq(). Furthermore, use it within ice_alloc_mapped_page(). Reviewed-by: NBjörn Töpel <bjorn.topel@intel.com> Signed-off-by: NMaciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Maciej Fijalkowski 提交于
Output of i40e_rx_offset() is based on ethtool's priv flag setting, which when changed, causes PF reset (disables napi, frees irqs, loads different Rx mem model, etc.). This means that within napi its result is constant and there is no reason to call it per each processed frame. Add new 'rx_offset' field to i40e_ring that is meant to hold the i40e_rx_offset() result and use it within i40e_clean_rx_irq(). Furthermore, use it within i40e_alloc_mapped_page(). Last but not least, un-inline the function of interest so that compiler makes the decision about inlining as it lives in .c file. Reviewed-by: NBjörn Töpel <bjorn.topel@intel.com> Signed-off-by: NMaciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Björn Töpel 提交于
Fold the count decrement into the while-statement. Reviewed-by: NMaciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: NBjörn Töpel <bjorn.topel@intel.com> Tested-by: NKiran Bhandare <kiranx.bhandare@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Maciej Fijalkowski 提交于
Whole zero-copy variant of clean Rx IRQ is executed when xsk_pool is attached to rx_ring and it can happen only when XDP program is present on interface. Therefore it is safe to assume that program is always !NULL and there is no need for checking it in ice_run_xdp_zc. Reviewed-by: NBjörn Töpel <bjorn.topel@intel.com> Signed-off-by: NMaciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: NKiran Bhandare <kiranx.bhandare@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Maciej Fijalkowski 提交于
dev_validate_mtu checks that mtu value specified by user is not less than min mtu and not greater than max allowed mtu. It is being done before calling the ndo_change_mtu exposed by driver, so remove these redundant checks in ice_change_mtu. Reviewed-by: NBjörn Töpel <bjorn.topel@intel.com> Signed-off-by: NMaciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Maciej Fijalkowski 提交于
Similar thing has been done in i40e, as there is no real need for having the sk_buff pointer in each rx_buf. Non-eop frames can be simply handled on that pointer moved upwards to rx_ring. Reviewed-by: NBjörn Töpel <bjorn.topel@intel.com> Signed-off-by: NMaciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Maciej Fijalkowski 提交于
There's no need for 'result' variable, we can directly return the internal status based on action returned by xdp prog. Reviewed-by: NBjörn Töpel <bjorn.topel@intel.com> Signed-off-by: NMaciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: NKiran Bhandare <kiranx.bhandare@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Maciej Fijalkowski 提交于
i40e_is_non_eop had a leftover comment and unused skb argument which was used for placing the skb onto rx_buf in case when current buffer was non-eop one. This is not relevant anymore as commit e72e5659 ("i40e/i40evf: Moves skb from i40e_rx_buffer to i40e_ring") pulled the non-complete skb handling out of rx_bufs up to rx_ring. Therefore, let's adjust the function arguments that i40e_is_non_eop takes. Furthermore, since there is already a function responsible for bumping the ntc, make use of that and drop that logic from i40e_is_non_eop so that the scope of this function is limited to what the name actually states. Reviewed-by: NBjörn Töpel <bjorn.topel@intel.com> Signed-off-by: NMaciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-
由 Maciej Fijalkowski 提交于
i40e_cleanup_headers has a statement about check against skb being linear or not which is not relevant anymore, so let's remove it. Same case for i40e_can_reuse_rx_page, it references things that are not present there anymore. Reviewed-by: NBjörn Töpel <bjorn.topel@intel.com> Signed-off-by: NMaciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: NTony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
-