- 26 1月, 2018 7 次提交
-
-
由 Edward Cree 提交于
For this we create and use one or more new TX queues on the PTP channel, and enable sync events for it. Based on a patch by Martin Habets <mhabets@solarflare.com>. Signed-off-by: NEdward Cree <ecree@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Martin Habets 提交于
TX timestamps on 8000 series are supplied from the MAC. This timestamp is only 48 bits long. The high order bits from the last time sync event are used for the top 16 bits. Signed-off-by: NMartin Habets <mhabets@solarflare.com> Signed-off-by: NEdward Cree <ecree@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Martin Habets 提交于
If we try to enable the feature and do not have the license for it, the MCPU will refuse and fail our TX queue init. Signed-off-by: NMartin Habets <mhabets@solarflare.com> Signed-off-by: NEdward Cree <ecree@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Martin Habets 提交于
We can now transmit SKBs in 2 ways: 1. Via the MC (for the 7XXX series and earlier), using efx_ptp_xmit_skb_mc(). 2. Via the TX queues on the dedicated PTP channel (8XXX series and later), using efx_ptp_xmit_skb_queue(). The PTP worker thread uses the method set up at probe time. It never checked the return code from the old efx_ptp_xmit_skb(), so it now returns void. We increment the TX dropped counter of the device if the transmit fails. As a result of the probe per channel the remove gets called multiple times. Clean up efx->ptp_data properly to avoid the 2nd call blowing up. Signed-off-by: NMartin Habets <mhabets@solarflare.com> Signed-off-by: NEdward Cree <ecree@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Martin Habets 提交于
Use MC capability MC_CMD_GET_CAPABILITIES_V2_OUT_TX_MAC_TIMESTAMPING to detect whether the NIC supports timestamping packets sent out the main datapath. Signed-off-by: NMartin Habets <mhabets@solarflare.com> Signed-off-by: NEdward Cree <ecree@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Martin Habets 提交于
Before this work, TX timestamping is done by sending each SKB to the MC. On the 8000 series (Medford1) we have high speed timestamping via the MAC, which means we can use normal TX queues for this without a significant drop in bandwidth. On the X2000 series (Medford2) support for transmitting via the MC is removed, so the new way must be used. This patch enables timestamping on a TX queue, if requested. It also enhances TX event handling to process the extra completion events, and puts the time in the SKB. Signed-off-by: NMartin Habets <mhabets@solarflare.com> Signed-off-by: NEdward Cree <ecree@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Bert Kenward 提交于
The NAPI budget is only for RX processing work, not other work such as TX or MCDI completion handling. Signed-off-by: NBert Kenward <bkenward@solarflare.com> Signed-off-by: NEdward Cree <ecree@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 25 1月, 2018 25 次提交
-
-
由 Ivan Mikhaylov 提交于
STA control register has areas of mode and opcodes for opeations. 18 bit is using for mode selection, where 0 is old MIO/MDIO access method and 1 is indirect access mode. 19-20 bits are using for setting up read/write operation(STA opcodes). In current state 'read' is set into old MIO/MDIO mode with 19 bit and write operation is set into 18 bit which is mode selection, not a write operation. To correlate write with read we set it into 20 bit. All those bit operations are MSB 0 based. Signed-off-by: NIvan Mikhaylov <ivan@de.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ivan Mikhaylov 提交于
emac4syn chips has availability to use 8192 rx/tx fifo buffer sizes, in current state if we set it up in dts 8192 as example, we will get only 2048 which may impact on network speed. Signed-off-by: NIvan Mikhaylov <ivan@de.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ngai-Mint Kwan 提交于
Clarify the comment for when entering promiscuous mode that we update the VLAN table. Add a comment distinguishing the case where we're exiting promiscuous mode and need to clear the entire VLAN table. Signed-off-by: NNgai-Mint Kwan <ngai-mint.kwan@intel.com> Signed-off-by: NJacob Keller <jacob.e.keller@gmail.com> Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Ngai-Mint Kwan 提交于
Signed-off-by: NNgai-Mint Kwan <ngai-mint.kwan@intel.com> Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Jacob Keller 提交于
Since commit 856dfd69e84f ("fm10k: Fix multicast mode synch issues", 2016-03-03) we've incorrectly assumed that VLAN 1 is enabled when the default VID is not set. This occurs because we check the default_vid and if it's zero, start several loops over the active_vlans bitmask at 1, instead of checking to ensure that that bit is active. This happened because of commit d9ff3ee8efe9 ("fm10k: Add support for VLAN 0 w/o default VLAN", 2014-08-07) which mistakenly assumed that we should send requests for MAC and VLAN filters with VLAN 0 when the default_vid isn't set. However, the switch generally considers this an invalid configuration, so the only time we'd have a default_vid of 0 is when the switch is down. Instead, lets just not request any filters for the default_vid if it's not yet been assigned. Signed-off-by: NJacob Keller <jacob.e.keller@intel.com> Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Jacob Keller 提交于
Currently, when the driver loads, it sends a request to add VLAN 0 to the VLAN table. For the PF, this is honored, and VLAN 0 is indeed set. For the VF, this request is silently converted into a request for the default VLAN as defined by either the switch vid or the PF vid. This results in the odd behavior that the VLAN table doesn't appear consistent between the PF and the VF. Furthermore, setting a MAC filter with VLAN 0 is generally considered an invalid configuration by the switch, and since commit 856dfd69e84f ("fm10k: Fix multicast mode synch issues", 2016-03-03) we've had code which prevents us from ever sending such a request. Since there's not really a good reason to keep VLAN 0 in the VLAN table, stop requesting it in fm10k_restore_rx_state(). This might seem to indicate that we would no longer properly configure the MAC and VLAN tables for the default vid. However, due to the way that fm10k_find_next_vlan() behaves, it will always return the default_vid as enabled. Signed-off-by: NJacob Keller <jacob.e.keller@intel.com> Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Ngai-Mint Kwan 提交于
When a VF is under PF VLAN assignment: ip link set <pf> vf <#> vlan <vid> This will remove all previous entries in the VLAN table including those generated by VLAN interfaces created on the VF. The issue arises when the VF is under PF VLAN assignment and one or more of these VLAN interfaces of the VF are deleted. When deleting these VLAN interfaces, the following message will be generated in "dmesg": failed to kill vid 0081/<vid> for device <vf> This is due to the fact that "ndo_vlan_rx_kill_vid" exits with an error. The handler for this ndo is "fm10k_update_vid". Any calls to this function while under PF VLAN management will exit prematurely and, thus, it will generate the failure message. Additionally, since "fm10k_update_vid" exits prematurely, none of the VLAN update is performed. So, even though the actual VLAN interfaces of the VF will be deleted, the active_vlans bitmask is not cleared. When the VF is no longer under PF VLAN assignment, the driver mistakenly restores the previous entries of the VLAN table based on an unsynchronized list of active VLANs. The solution to this issue involves checking the VLAN update action type before exiting "fm10k_update_vid". If the VLAN update action type is to "add", this action will not be permitted while the VF is under PF VLAN assignment and the VLAN update is abandoned like before. However, if the VLAN update action type is to "kill", then we need to also clear the active_vlans bitmask. However, we don't need to actually queue any messages to the PF, because the MAC and VLAN tables have already been cleared, and the PF would silently ignore these requests anyways. Signed-off-by: NNgai-Mint Kwan <ngai-mint.kwan@intel.com> Signed-off-by: NJacob Keller <jacob.e.keller@intel.com> Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Jacob Keller 提交于
This fixes a few warnings found by checkpatch.pl --strict Signed-off-by: NJacob Keller <jacob.e.keller@intel.com> Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Wei Yongjun 提交于
Fixes the following sparse warning: drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c:46:27: warning: symbol 'pedits' was not declared. Should it be static? Fixes: 27ece1f3 ("cxgb4: add tc flower support for ETH-DMAC rewrite") Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jason Wang 提交于
The code will try to access dev->iotlb when processing VHOST_IOTLB_INVALIDATE even if it was not initialized which may lead to NULL pointer dereference. Fixes this by check dev->iotlb before. Fixes: 6b1e6cc7 ("vhost: new device IOTLB API") Signed-off-by: NJason Wang <jasowang@redhat.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jason Wang 提交于
We used to call mutex_lock() in vhost_dev_lock_vqs() which tries to hold mutexes of all virtqueues. This may confuse lockdep to report a possible deadlock because of trying to hold locks belong to same class. Switch to use mutex_lock_nested() to avoid false positive. Fixes: 6b1e6cc7 ("vhost: new device IOTLB API") Reported-by: syzbot+dbb7c1161485e61b0241@syzkaller.appspotmail.com Signed-off-by: NJason Wang <jasowang@redhat.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jakub Kicinski 提交于
Since TC block changes drivers are required to check if the TC hw offload flag is set on the interface themselves. Fixes: 2f4b411a ("i40e: Enable cloud filters via tc-flower") Fixes: 44ae12a7 ("net: sched: move the can_offload check from binding phase to rule insertion phase") Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: NSimon Horman <simon.horman@netronome.com> Acked-by: NJiri Pirko <jiri@mellanox.com> Acked-by: NAmritha Nambiar <amritha.nambiar@intel.com> Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michal Kalderon 提交于
A tid was allocated for reserved MR during initialization but not freed. This lead to an annoying output message during rdma unload flow. Signed-off-by: NMichal Kalderon <Michal.Kalderon@cavium.com> Signed-off-by: NAriel Elior <Ariel.Elior@cavium.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michal Kalderon 提交于
Double reservation for kernel dedicated dpi was performed. Once in the core module and once in qedr. Remove the reservation from core. Signed-off-by: NMichal Kalderon <Michal.Kalderon@cavium.com> Signed-off-by: NAriel Elior <Ariel.Elior@cavium.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Alexander Duyck 提交于
The fm10k driver didn't work correctly when macvlan offload was enabled. Specifically what would occur is that we would see no unicast packets being received. This was traced down to us not correctly configuring the default VLAN ID for the port and defaulting to 0. To correct this we either use the default ID provided by the switch or simply use 1. With that we are able to pass and receive traffic without any issues. In addition we were not repopulating the filter table following a reset. To correct that I have added a bit of code to fm10k_restore_rx_state that will repopulate the Rx filter configuration for the macvlan interfaces. Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com> Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Wang Dongsheng 提交于
Bit TPD3[31] is used as a timestamp bit if PTP is enabled, but it's used as an address bit if PTP is disabled. Since PTP isn't supported by the driver, we can extend the DMA address to 46 bits. Signed-off-by: NWang Dongsheng <dongsheng.wang@hxt-semitech.com> Acked-by: NTimur Tabi <timur@codeaurora.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Niklas Cassel 提交于
Doing a bitwise AND between a bool and an int is generally not a good idea. The bool will be promoted to an int with value 0 or 1, the int is generally regarded as true with a non-zero value, thus ANDing them has the potential to yield an undesired result. This commit fixes the following smatch warnings: drivers/net/ethernet/stmicro/stmmac/enh_desc.c:344 enh_desc_prepare_tx_desc() warn: maybe use && instead of & drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c:337 dwmac4_rd_prepare_tx_desc() warn: maybe use && instead of & drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c:380 dwmac4_rd_prepare_tso_tx_desc() warn: maybe use && instead of & Signed-off-by: NNiklas Cassel <niklas.cassel@axis.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Daniel Hua 提交于
Problem description: After ethernet cable connect and disconnect for several iterations on a device with i210, tx timestamp will stop being put into the socket. Steps to reproduce: 1. Setup a device with i210 and wire it to a 802.1AS capable switch ( Extreme Networks Summit x440 is used in our case) 2. Have the gptp daemon running on the device and make sure it is synced with the switch 3. Have the switch disable and enable the port, wait for the device gets resynced with the switch 4. Iterates step 3 until the device is not albe to get resynced 5. Review the log in dmesg and you will see warning message "igb : clearing Tx timestamp hang" Root cause: If ptp_tx_work() gets scheduled just before the port gets disabled, a LINK DOWN event will be processed before ptp_tx_work(), which may cause timeout in ptp_tx_work(). In the timeout logic, the TSYNCTXCTL's TXTT bit (Transmit timestamp valid bit) is not cleared, causing no new timestamp loaded to TXSTMP register. Consequently therefore, no new interrupt is triggerred by TSICR.TXTS bit and no more Tx timestamp send to the socket. Signed-off-by: NDaniel Hua <daniel.hua@ni.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Markus Elfring 提交于
Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Lyude Paul 提交于
Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon hotplugging my kernel would immediately crash due to igb: [ 680.825801] kernel BUG at drivers/pci/msi.c:352! [ 680.828388] invalid opcode: 0000 [#1] SMP [ 680.829194] Modules linked in: igb(O) thunderbolt i2c_algo_bit joydev vfat fat btusb btrtl btbcm btintel bluetooth ecdh_generic hp_wmi sparse_keymap rfkill wmi_bmof iTCO_wdt intel_rapl x86_pkg_temp_thermal coretemp crc32_pclmul snd_pcm rtsx_pci_ms mei_me snd_timer memstick snd pcspkr mei soundcore i2c_i801 tpm_tis psmouse shpchp wmi tpm_tis_core tpm video hp_wireless acpi_pad rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci mfd_core xhci_pci xhci_hcd i2c_hid i2c_core [last unloaded: igb] [ 680.831085] CPU: 1 PID: 78 Comm: kworker/u16:1 Tainted: G O 4.15.0-rc3Lyude-Test+ #6 [ 680.831596] Hardware name: HP HP ZBook Studio G4/826B, BIOS P71 Ver. 01.03 06/09/2017 [ 680.832168] Workqueue: kacpi_hotplug acpi_hotplug_work_fn [ 680.832687] RIP: 0010:free_msi_irqs+0x180/0x1b0 [ 680.833271] RSP: 0018:ffffc9000030fbf0 EFLAGS: 00010286 [ 680.833761] RAX: ffff8803405f9c00 RBX: ffff88033e3d2e40 RCX: 000000000000002c [ 680.834278] RDX: 0000000000000000 RSI: 00000000000000ac RDI: ffff880340be2178 [ 680.834832] RBP: 0000000000000000 R08: ffff880340be1ff0 R09: ffff8803405f9c00 [ 680.835342] R10: 0000000000000000 R11: 0000000000000040 R12: ffff88033d63a298 [ 680.835822] R13: ffff88033d63a000 R14: 0000000000000060 R15: ffff880341959000 [ 680.836332] FS: 0000000000000000(0000) GS:ffff88034f440000(0000) knlGS:0000000000000000 [ 680.836817] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 680.837360] CR2: 000055e64044afdf CR3: 0000000001c09002 CR4: 00000000003606e0 [ 680.837954] Call Trace: [ 680.838853] pci_disable_msix+0xce/0xf0 [ 680.839616] igb_reset_interrupt_capability+0x5d/0x60 [igb] [ 680.840278] igb_remove+0x9d/0x110 [igb] [ 680.840764] pci_device_remove+0x36/0xb0 [ 680.841279] device_release_driver_internal+0x157/0x220 [ 680.841739] pci_stop_bus_device+0x7d/0xa0 [ 680.842255] pci_stop_bus_device+0x2b/0xa0 [ 680.842722] pci_stop_bus_device+0x3d/0xa0 [ 680.843189] pci_stop_and_remove_bus_device+0xe/0x20 [ 680.843627] trim_stale_devices+0xf3/0x140 [ 680.844086] trim_stale_devices+0x94/0x140 [ 680.844532] trim_stale_devices+0xa6/0x140 [ 680.845031] ? get_slot_status+0x90/0xc0 [ 680.845536] acpiphp_check_bridge.part.5+0xfe/0x140 [ 680.846021] acpiphp_hotplug_notify+0x175/0x200 [ 680.846581] ? free_bridge+0x100/0x100 [ 680.847113] acpi_device_hotplug+0x8a/0x490 [ 680.847535] acpi_hotplug_work_fn+0x1a/0x30 [ 680.848076] process_one_work+0x182/0x3a0 [ 680.848543] worker_thread+0x2e/0x380 [ 680.848963] ? process_one_work+0x3a0/0x3a0 [ 680.849373] kthread+0x111/0x130 [ 680.849776] ? kthread_create_worker_on_cpu+0x50/0x50 [ 680.850188] ret_from_fork+0x1f/0x30 [ 680.850601] Code: 43 14 85 c0 0f 84 d5 fe ff ff 31 ed eb 0f 83 c5 01 39 6b 14 0f 86 c5 fe ff ff 8b 7b 10 01 ef e8 b7 e4 d2 ff 48 83 78 70 00 74 e3 <0f> 0b 49 8d b5 a0 00 00 00 e8 62 6f d3 ff e9 c7 fe ff ff 48 8b [ 680.851497] RIP: free_msi_irqs+0x180/0x1b0 RSP: ffffc9000030fbf0 As it turns out, normally the freeing of IRQs that would fix this is called inside of the scope of __igb_close(). However, since the device is already gone by the point we try to unregister the netdevice from the driver due to a hotplug we end up seeing that the netif isn't present and thus, forget to free any of the device IRQs. So: make sure that if we're in the process of dismantling the netdev, we always allow __igb_close() to be called so that IRQs may be freed normally. Additionally, only allow igb_close() to be called from __igb_close() if it hasn't already been called for the given adapter. Signed-off-by: NLyude Paul <lyude@redhat.com> Fixes: 9474933c ("igb: close/suspend race in netif_device_detach") Cc: Todd Fujinaka <todd.fujinaka@intel.com> Cc: Stephen Hemminger <stephen@networkplumber.org> Cc: stable@vger.kernel.org Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Matt Turner 提交于
I personally spent a long time trying to decypher why my CPU would not reach deeper C-states. Let's just tell the next user what's going on. Signed-off-by: NMatt Turner <matt.turner@intel.com> Acked-by: NShannon Nelson <shannon.nelson@oracle.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Jesus Sanchez-Palencia 提交于
By design, the idleslope increments are restricted to 16.384kbps steps. Add a comment to igb_main.c making that explicit and add one example that illustrates the impact of that. Signed-off-by: NJesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Matt Turner 提交于
According to section 12.0.3.4.13 "Receive Descriptor Control - RXDCTL" of the Intel® 82579 Gigabit Ethernet PHY Datasheet v2.1: "HTHRESH should be given a non zero value when ever PTHRESH is used." In RXDCTL(0), PTHRESH lives at bits 5:0, and HTHREST lives at bits 13:8. Set only bit 8 of HTHREST as is done in e1000_flush_rx_ring(). Found by inspection. Signed-off-by: NMatt Turner <matt.turner@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Zhang Shengju 提交于
This patch adds a new function igb_get_max_rss_queues() to get maximum RSS queues, this will reduce duplicate code and facilitate future maintenance. Signed-off-by: NZhang Shengju <zhangshengju@cmss.chinamobile.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Corinna Vinschen 提交于
Before libvirt modifies the MAC address and vlan tag for an SRIOV VF for use by a virtual machine (either using vfio device assignment or macvtap passthru mode), it saves the current MAC address and vlan tag so that it can reset them to their original value when the guest is done. Libvirt can't leave the VF MAC set to the value used by the now-defunct guest since it may be started again later using a different VF, but it certainly shouldn't just pick any random value, either. So it saves the state of everything prior to using the VF, and resets it to that. The igb driver initializes the MAC addresses of all VFs to 00:00:00:00:00:00, and reports that when asked (via an RTM_GETLINK netlink message, also visible in the list of VFs in the output of "ip link show"). But when libvirt attempts to restore the MAC address back to 00:00:00:00:00:00 (using an RTM_SETLINK netlink message) the kernel responds with "Invalid argument". Forbidding a reset back to the original value leaves the VF MAC at the value set for the now-defunct virtual machine. Especially on a system with NetworkManager enabled, this has very bad consequences, since NetworkManager forces all interfacess to be IFF_UP all the time - if the same virtual machine is restarted using a different VF (or even on a different host), there will be multiple interfaces watching for traffic with the same MAC address. To allow libvirt to revert to the original state, we need a way to remove the administrative set MAC on a VF, to allow normal host operation again, and to reset/overwrite the VF MAC via VF netdev. This patch implements the outlined scenario by allowing to set the VF MAC to 00:00:00:00:00:00 via RTM_SETLINK on the PF. igb_ndo_set_vf_mac resets the IGB_VF_FLAG_PF_SET_MAC flag to 0, so it's possible to reset the VF MAC back to the original value via the VF netdev. Note: Recent patches to libvirt allow for a workaround if the NIC isn't capable of resetting the administrative MAC back to all 0, but in theory the NIC should allow resetting the MAC in the first place. Signed-off-by: NCorinna Vinschen <vinschen@redhat.com> Tested-by: NAaron Brown <arron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 24 1月, 2018 8 次提交
-
-
由 Yuval Mintz 提交于
Driver periodically samples all neighbors configured in device in order to update the kernel regarding their state. When finding an entry configured in HW that doesn't show in neigh_lookup() driver logs an error message. This introduces a race when removing multiple neighbors - it's possible that a given entry would still be configured in HW as its removal is still being processed but is already removed from the kernel's neighbor tables. Simply remove the error message and gracefully accept such events. Fixes: c723c735 ("mlxsw: spectrum_router: Periodically update the kernel's neigh table") Fixes: 60f040ca ("mlxsw: spectrum_router: Periodically dump active IPv6 neighbours") Signed-off-by: NYuval Mintz <yuvalm@mellanox.com> Reviewed-by: NIdo Schimmel <idosch@mellanox.com> Signed-off-by: NJiri Pirko <jiri@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Rahul Lakkireddy 提交于
memset variables to 0 to fix sparse warnings: drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c:409:42: sparse: Using plain integer as NULL pointer drivers/net/ethernet/chelsio/cxgb4/cudbg_zlib.c:43:47: sparse: Using plain integer as NULL pointer Fixes: ad75b7d3 ("cxgb4: implement ethtool dump data operations") Fixes: 91c1953d ("cxgb4: use zlib deflate to compress firmware dump") Signed-off-by: NRahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Rahul Lakkireddy 提交于
Fixes: drivers/net/ethernet/chelsio/cxgb4/cudbg_zlib.c:39:5: error: redefinition of 'cudbg_compress_buff' int cudbg_compress_buff(struct cudbg_init *pdbg_init, ^~~~~~~~~~~~~~~~~~~ In file included from drivers/net/ethernet/chelsio/cxgb4/cudbg_zlib.c:23:0: drivers/net/ethernet/chelsio/cxgb4/cudbg_zlib.h:45:19: note: previous definition of 'cudbg_compress_buff' was here static inline int cudbg_compress_buff(struct cudbg_init *pdbg_init, ^~~~~~~~~~~~~~~~~~~ Fixes: 91c1953d ("cxgb4: use zlib deflate to compress firmware dump") Signed-off-by: NRahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ganesh Goudar 提交于
implement ndo_set_vf_vlan for mgmt netdevice to configure the PCIe VF. Original work by: Casey Leedom <leedom@chelsio.com> Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Quentin Monnet 提交于
Make netdevsim print a message to the BPF verifier log buffer when a program is offloaded. Then use this message in hardware offload selftests to make sure that using this buffer actually prints the message to the console for eBPF hardware offload. The message is appended after the last instruction is processed with the verifying function from netdevsim. Output looks like the following: $ tc filter add dev foo ingress bpf obj sample_ret0.o \ sec .text verbose skip_sw Prog section '.text' loaded (5)! - Type: 3 - Instructions: 2 (0 over limit) - License: Verifier analysis: 0: (b7) r0 = 0 1: (95) exit [netdevsim] Hello from netdevsim! processed 2 insns, stack depth 0 "verbose" flag is required to see it in the console since netdevsim does not throw an error after printing the message. Signed-off-by: NQuentin Monnet <quentin.monnet@netronome.com> Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jakub Kicinski 提交于
We should not compile netdevsim/bpf.c if BPF syscall is not enabled. Otherwise bpf core would have to provide wrappers for all functions offload drivers may call, even though system will never see a BPF object. Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: NQuentin Monnet <quentin.monnet@netronome.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Quentin Monnet 提交于
Use the recently added extack support for TC eBPF filters in netdevsim. Signed-off-by: NQuentin Monnet <quentin.monnet@netronome.com> Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Neil Horman 提交于
with the introduction of commit b0eb57cb, it appears that rq->buf_info is improperly handled. While it is heap allocated when an rx queue is setup, and freed when torn down, an old line of code in vmxnet3_rq_destroy was not properly removed, leading to rq->buf_info[0] being set to NULL prior to its being freed, causing a memory leak, which eventually exhausts the system on repeated create/destroy operations (for example, when the mtu of a vmxnet3 interface is changed frequently. Fix is pretty straight forward, just move the NULL set to after the free. Tested by myself with successful results Applies to net, and should likely be queued for stable, please Signed-off-by: NNeil Horman <nhorman@tuxdriver.com> Reported-By: boyang@redhat.com CC: boyang@redhat.com CC: Shrikrishna Khare <skhare@vmware.com> CC: "VMware, Inc." <pv-drivers@vmware.com> CC: David S. Miller <davem@davemloft.net> Acked-by: NShrikrishna Khare <skhare@vmware.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-