- 13 Jan, 2015 38 commits
-
-
Jiri Pirko authored
The same macros are used for rx as well. So rename it. Signed-off-by:
Jiri Pirko <jiri@resnulli.us> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jiri Pirko authored
tc code implicitly considers skb->protocol even in case of accelerated vlan paths and expects vlan protocol type here. However, on rx path, if the vlan header was already stripped, skb->protocol contains value of next header. Similar situation is on tx path. So for skbs that use skb->vlan_tci for tagging, use skb->vlan_proto instead. Reported-by:
Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
-
Rickard Strandqvist authored
Removes some functions that are not used anywhere: channel_to_vpivci() query_tx_channel_config() rx_disabled_handler() This was partially found by using a static code analysis program called cppcheck. Signed-off-by:
Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by:
-
Rickard Strandqvist authored
Remove the function aal5_spacefor() that is not used anywhere. This was partially found by using a static code analysis program called cppcheck. Signed-off-by:
-
Sasha Levin authored
Commit f2f9800d "tipc: make tipc node table aware of net namespace" has added a dereference of sock->sk before making sure it's not NULL, which makes releasing a tipc socket NULL pointer dereference for sockets that are not fully initialized. Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
-
David L Stevens authored
This patch fixes the rx packet length check in the sunvnet driver to allow for a TSO max packet length greater than the LDC channel negotiated MTU. These are negotiated separately and there is no requirement that port->tsolen be less than port->rmtu, but if it isn't, it'll drop packets with rx length errors. Signed-off-by:
David L Stevens <david.stevens@oracle.com> Acked-by:
Sowmini Varadhan <sowmini.varadhan@oracle.com> Signed-off-by:
-
Arnd Bergmann authored
Not all architectures are able to call __builtin_return_address(). On ARM, the mISDN code produces this warning: hardware/mISDN/w6692.c: In function 'w6692_dctrl': hardware/mISDN/w6692.c:1181:75: warning: unsupported argument to '__builtin_return_address' pr_debug("%s: %s dev(%d) open from %p\n", card->name, __func__, ^ hardware/mISDN/mISDNipac.c: In function 'open_dchannel': hardware/mISDN/mISDNipac.c:759:75: warning: unsupported argument to '__builtin_return_address' pr_debug("%s: %s dev(%d) open from %p\n", isac->name, __func__, ^ In a lot of cases, this is relatively easy to work around by passing the value of __builtin_return_address(0) from the callers into the functions that want it. One exception is the indirect 'open' function call in struct isac_hw. While it would be possible to fix this as well, this patch only addresses the other callers properly and lets this one return the direct parent function, which should be good enough. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
The return type of find_first_bit() is architecture specific, on ARM it is 'unsigned int', while the asm-generic code used on x86 and a lot of other architectures returns 'unsigned long'. When building the mlx5 driver on ARM, we get a warning about this: infiniband/hw/mlx5/mem.c: In function 'mlx5_ib_cont_pages': infiniband/hw/mlx5/mem.c:84:143: warning: comparison of distinct pointer types lacks a cast m = min(m, find_first_bit(&tmp, sizeof(tmp))); This patch changes the driver to use min_t to make it behave the same way on all architectures. Signed-off-by:Eli Cohen <eli@mellanox.com> Signed-off-by:
-
Arnd Bergmann authored
The mlx5 driver passes a string pointer in through a 'u64' variable, which on 32-bit machines causes a build warning: drivers/net/ethernet/mellanox/mlx5/core/debugfs.c: In function 'qp_read_field': drivers/net/ethernet/mellanox/mlx5/core/debugfs.c:303:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] The code is in fact safe, so we can shut up the warning by adding extra type casts. Signed-off-by:
-
Arnd Bergmann authored
The rocker driver tries to assign a pointer to a 64-bit integer and then back to a pointer. This is safe on all architectures, but causes a compiler warning when pointers are shorter than 64-bit: rocker/rocker.c: In function 'rocker_desc_cookie_ptr_get': rocker/rocker.c:809:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] return (void *) desc_info->desc->cookie; ^ This adds another cast to uintptr_t to tell the compiler that it's safe. Signed-off-by: -
Hariprasad Shenai authored
Removing old hard-wired initialization code in the driver, which is no longer used. Also deprecating few module parameters. Signed-off-by:
Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by:
-
Ying Xue authored
Remove the redundant timer defined in tipc_sock structure, instead we can directly reuse the sk_timer defined in sock structure. Signed-off-by:
Ying Xue <ying.xue@windriver.com> Acked-by:
Erik Hugne <erik.hugne@ericsson.com> Reviewed-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
-
Shaohui Xie authored
Signed-off-by:
Shaohui Xie <Shaohui.Xie@freescale.com> Signed-off-by:
-
Shaohui Xie authored
There is a bug in xgmac_mdio_read when clear the bit MDIO_STAT_ENC, which '&' is missed in 'mdio_stat &= ~MDIO_STAT_ENC'. Signed-off-by:
-
Roopa Prabhu authored
net/bridge/br_netlink.c: In function ‘br_fill_ifinfo’: net/bridge/br_netlink.c:146:32: warning: ‘vid_range_flags’ may be used uninitialized in this function [-Wmaybe-uninitialized] err = br_fill_ifvlaninfo_range(skb, vid_range_start, ^ net/bridge/br_netlink.c:108:6: note: ‘vid_range_flags’ was declared here u16 vid_range_flags; Reported-by:Thomas Graf <tgraf@suug.ch> Signed-off-by:
Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by:
-
Willem de Bruijn authored
Patch 3b50d902 ("ipv6: fix redefinition of in6_pktinfo ...") fixed a libc compatibility issue in ipv6 structure definitions as described in include/uapi/linux/libc-compat.h. It relies on including linux/in6.h to include libc-compat.h itself. Include that file directly to clearly communicate the dependency (libc-compat.h: "This include must be as early as possible"). Signed-off-by:
Willem de Bruijn <willemb@google.com> ---- As discussed in http://patchwork.ozlabs.org/patch/427384/Acked-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-nextDavid S. Miller authored
Jeff Kirsher says: ==================== Intel Wired LAN Driver Updates 2015-01-13 This series contains updates to i40e and i40evf. Mitch provides a fix for i40e to move the call to pci_disable_sriov() so that it is called earlier to ensure that the PF driver won't free VF resources before the VF remove routine can complete. Also cleans up redundant and duplicate code in the i40evf. Refactors the i40evf shutdown code and let the watchdog take care of shutting things down. Fix a possible memory leak, if we are using VLANs and the communication with the PF fail during shutdown. On some versions of the firmware, the VF admin send queue may become stalled. In this case, the easiest solution is to place another descriptor on the queue and the firmware will then process both requests. Greg adds a warning when the NPAR enabled partitions detected a link speed less than 10 Gpbs. Vasu removes redundant VN2VN MAC address which were already added by the FCoE stack. Shannon adds code to find how many partitions there are per port and what is the current partition_id when in NPAR mode. In multifunction mode, make sure we only allow SR/IOV on the master PF of a port and only allow partition 1 to set WoL, speed and flow control. Kamil adds code to read the PBA block from shadow RAM and returns the part number in a string format. Catherine provides a fix to check if link state and link speed has changed before exiting link event v2: remove un-needed {} in patch #3 of the series based on feedback from Sergei Shtylyov ==================== Signed-off-by: -
Shannon Nelson authored
Make sure we only allow SR/IOV on the master PF of a port in multifunction mode. This should be the case anyway based on the num_vfs configured in the NVM, but this will help make sure there's no question. If we're not in multifunction mode the partition_id will always be 1. Change-ID: I8b2592366fe6782f15301bde2ebd1d4da240109d Signed-off-by:
Shannon Nelson <shannon.nelson@intel.com> Tested-by:
Jim Young <james.m.young@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Catherine Sullivan authored
Previously we were only checking if the link up state had changed, and if it hadn't exiting the link event routine early. We should also check if speed has changed, and if it has, stay and finish processing the link event. Change-ID: I9c8e0991b3f0279108a7858898c3c5ce0a9856b8 Signed-off-by:
Catherine Sullivan <catherine.sullivan@intel.com> Signed-off-by:
-
Shannon Nelson authored
When in multi-function mode, e.g. Dell's NPAR, only partition 1 of each MAC is allowed to set WoL, speed, and flow control. Change-ID: I87a9debc7479361c55a71f0120294ea319f23588 Signed-off-by:
-
Kamil Krawczyk authored
Function will read PBA Block from Shadow RAM and return it in a string format. Change-ID: I4ee7059f6e21bd0eba38687da15e772e0b4ab36e Signed-off-by:
Kamil Krawczyk <kamil.krawczyk@intel.com> Signed-off-by:
-
Shannon Nelson authored
When in NPAR mode the driver instance might be controlling the base partition or one of the other "fake" PFs. There are some things that can only be done by the base partition, aka partition_id 1. This code does a bit of work to find how many partitions are there per port and what is the current partition_id. Change-ID: Iba427f020a1983d02147d86f121b3627e20ee21d Signed-off-by:
-
Vasu Dev authored
These mac address already added by FCoE stack above netdev, therefore adding them here is redundant. Change-ID: Ia5b59f426f57efd20f8945f7c6cc5d741fbe06e5 Signed-off-by:
Vasu Dev <vasu.dev@intel.com> Signed-off-by:
-
Greg Rose authored
NPAR enabled partitions should warn the user when detected link speed is less than 10Gpbs. Change-ID: I7728bb8ce279bf0f4f755d78d7071074a4eb5f69 Signed-off-by:
Greg Rose <gregory.v.rose@intel.com> Signed-off-by:
-
Mitch A Williams authored
On some versions of the firmware, the VF admin send queue may become stalled. In this case, the easiest solution is to just place another descriptor on the queue; the firmware will then process both requests. The early init code already accounts for this, but the runtime code does not. In the watchdog task, check for the stall condition, and if it's found, send our API version to the PF. When the PF replies, just ignore the reply. Change-ID: I380d78185a4f284d649c44d263e648afc9b4d50c Signed-off-by:
Mitch Williams <mitch.a.williams@intel.com> Acked-by:
-
Mitch A Williams authored
Don't enable vector 0 in the ISR, just schedule the adminq task and let it enable the vector. This prevents the task from being called reentrantly. Make sure that the vector is enabled on all exit paths of the adminq task, including error exits. Change-ID: I53f3d14f91ed7a9e90291ea41c681122a5eca5b5 Signed-off-by:
-
Mitch A Williams authored
There is always a possibility that MSI-X interrupts can get lost. To keep this problem from stalling the driver, we fire all of our MSI-X vectors during the watchdog routine. However, we should not fire the traffic vectors when the interface is closed. In this case, just fire vector 0, which is used for admin queue events. As a result, we do not enable the interrupt cause for vector 0. This can cause the admin queue handler to be called reentrantly, which causes a scary "critical section violation" message to be logged, even though no real damage is done. Change-ID: Ic43a5184708ab2cb9a23fca7dedd808a46717795 Signed-off-by:
-
Mitch A Williams authored
If we're using VLANs and communications with the PF fail during shutdown, we will leak memory because not all of the VLAN filters will be removed. To eliminate this possibility, go through the list again right before the module is removed and delete any leftover entries. Change-ID: Id3b5315c47ca0a61ae123a96ff345d010bc41aed Signed-off-by:
-
Mitch A Williams authored
If the VF driver is running in the host, the shutdown code is completely broken. We cannot wait in our down routine for the PF to respond to our requests, as its admin queue task will never run while we hold the lock. Instead, we schedule operations, then let the watchdog take care of shutting things down. If the driver is being removed, then wait in the remove routine until the watchdog is done before continuing. Change-ID: I93a58d17389e8d6b58f21e430b56ed7b4590b2c5 Signed-off-by:
-
Syam Sidhardhan authored
version.h inclusion is not necessary as detected by versioncheck. Signed-off-by:
Syam Sidhardhan <s.syam@samsung.com> Acked-by:
Pravin B Shelar <pshelar@nicira.com> Signed-off-by:
-
Mitch A Williams authored
These messages may be triggered during normal init of the driver if the PF or FW take a long time to respond. There's nothing really wrong, so don't freak people out logging messages. If the communication channel really is dead, then we'll retry a few times and give up. This will log a different more scary message that should cause consternation. This allows the user to more easily detect a genuine failure. Change-ID: I6e2b758d4234a3a09c1015c82c8f2442a697cbdb Signed-off-by:
-
Mitch A Williams authored
These functions are redundant and duplicate functionality found in i40evf_free_all_[tx|rx]_resources. Change-ID: Ia199908926d7a1a4b8247f75f89b5da24c9b149c Signed-off-by:
-
Mitch A Williams authored
If VF drivers are loaded in the host OS, the call to pci_disable_sriov() will cause these drivers' remove routines to be called. If the PF driver has already freed VF resources before this happens, then the VF remove routine can't properly communicate with the PF driver causing all sorts of mayhem and error messages and hurt feelings. To fix this, we move the call to pci_disable_sriov() up to the top of the function and let it complete before freeing any VF resources. Change-ID: I397c3997a00f6408e32b7735273911e499600236 Signed-off-by:
-
Sébastien Barré authored
With TLP, the peer may reply to a probe with an ACK+D-SACK, with ack value set to tlp_high_seq. In the current code, such ACK+DSACK will be missed and only at next, higher ack will the TLP episode be considered done. Since the DSACK is not present anymore, this will cost a cwnd reduction. This patch ensures that this scenario does not cause a cwnd reduction, since receiving an ACK+DSACK indicates that both the initial segment and the probe have been received by the peer. The following packetdrill test, from Neal Cardwell, validates this patch: // Establish a connection. 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 +0 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7> +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 6> +.020 < . 1:1(0) ack 1 win 257 +0 accept(3, ..., ...) = 4 // Send 1 packet. +0 write(4, ..., 1000) = 1000 +0 > P. 1:1001(1000) ack 1 // Loss probe retransmission. // packets_out == 1 => schedule PTO in max(2*RTT, 1.5*RTT + 200ms) // In this case, this means: 1.5*RTT + 200ms = 230ms +.230 > P. 1:1001(1000) ack 1 +0 %{ assert tcpi_snd_cwnd == 10 }% // Receiver ACKs at tlp_high_seq with a DSACK, // indicating they received the original packet and probe. +.020 < . 1:1(0) ack 1001 win 257 <sack 1:1001,nop,nop> +0 %{ assert tcpi_snd_cwnd == 10 }% // Send another packet. +0 write(4, ..., 1000) = 1000 +0 > P. 1001:2001(1000) ack 1 // Receiver ACKs above tlp_high_seq, which should end the TLP episode // if we haven't already. We should not reduce cwnd. +.020 < . 1:1(0) ack 2001 win 257 +0 %{ assert tcpi_snd_cwnd == 10, tcpi_snd_cwnd }% Credits: -Gregory helped in finding that tcp_process_tlp_ack was where the cwnd got reduced in our MPTCP tests. -Neal wrote the packetdrill test above -Yuchung reworked the patch to make it more readable. Cc: Gregory Detal <gregory.detal@uclouvain.be> Cc: Nandita Dukkipati <nanditad@google.com> Tested-by:Neal Cardwell <ncardwell@google.com> Reviewed-by:
Yuchung Cheng <ycheng@google.com> Reviewed-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
Sébastien Barré <sebastien.barre@uclouvain.be> Acked-by:
Eric Dumazet <edumazet@google.com> Acked-by:
-
David S. Miller authored
Ying Xue says: ==================== remove nl_sk_hash_lock from netlink socket After tipc socket successfully avoids the involvement of an extra lock with rhashtable_lookup_insert(), it's possible for netlink socket to remove its hash socket lock now. But as netlink socket needs a compare function to look for an object, we first introduce a new function called rhashtable_lookup_compare_insert() in commit #1 which is implemented based on original rhashtable_lookup_insert(). We subsequently remove nl_sk_hash_lock from netlink socket with the new introduced function in commit #2. Lastly, as Thomas requested, we add commit #3 to indicate the implementation of what the grow and shrink decision function must enforce min/max shift. v2: As Thomas pointed out, there was a race between checking portid and then setting it in commit #2. Now use socket lock to make the process of both checking and setting portid atomic, and then eliminate the race. ==================== Signed-off-by: -
Ying Xue authored
As commit c0c09bfd ("rhashtable: avoid unnecessary wakeup for worker queue") moves condition statements of verifying whether hash table size exceeds its maximum threshold or reaches its minimum threshold from resizing functions to resizing decision functions, we should add a note in rhashtable.h to indicate the implementation of what the grow and shrink decision function must enforce min/max shift, otherwise, it's failed to take min/max shift's set watermarks into effect. Signed-off-by:
-
Ying Xue authored
As rhashtable_lookup_compare_insert() can guarantee the process of search and insertion is atomic, it's safe to eliminate the nl_sk_hash_lock. After this, object insertion or removal will be protected with per bucket lock on write side while object lookup is guarded with rcu read lock on read side. Signed-off-by:
-
Ying Xue authored
Introduce a new function called rhashtable_lookup_compare_insert() which is very similar to rhashtable_lookup_insert(). But the former makes use of users' given compare function to look for an object, and then inserts it into hash table if found. As the entire process of search and insertion is under protection of per bucket lock, this can help users to avoid the involvement of extra lock. Signed-off-by:
-
- 12 Jan, 2015 2 commits
-
-
David S. Miller authored
Pankaj Gupta says: ==================== Increase the limit of tuntap queues Networking under KVM works best if we allocate a per-vCPU rx and tx queue in a virtual NIC. This requires a per-vCPU queue on the host side. Modern physical NICs have multiqueue support for large number of queues. To scale vNIC to run multiple queues parallel to maximum number of vCPU's we need to increase number of queues support in tuntap. Changes from v4: PATCH2: Michael.S.Tsirkin - Updated change comment message. Changes from v3: PATCH1: Michael.S.Tsirkin - Some cleanups and updated commit message. Perf numbers on 10 Gbs NIC Changes from v2: PATCH 3: David Miller - flex array adds extra level of indirection for preallocated array.(dropped, as flow array is allocated using kzalloc with failover to zalloc). Changes from v1: PATCH 2: David Miller - sysctl changes to limit number of queues not required for unprivileged users(dropped). Changes from RFC PATCH 1: Sergei Shtylyov - Add an empty line after declarations. PATCH 2: Jiri Pirko - Do not introduce new module paramaters. Michael.S.Tsirkin- We can use sysctl for limiting max number of queues. This series is to increase the number of tuntap queues. Original work is being done by 'jasowang@redhat.com'. I am taking this 'https://lkml.org/lkml/2013/6/19/29' patch series as a reference. As per discussion in the patch series: There were two reasons which prevented us from increasing number of tun queues: - The netdev_queue array in netdevice were allocated through kmalloc, which may cause a high order memory allocation too when we have several queues. E.g. sizeof(netdev_queue) is 320, which means a high order allocation would happens when the device has more than 16 queues. - We store the hash buckets in tun_struct which results a very large size of tun_struct, this high order memory allocation fail easily when the memory is fragmented. The patch 60877a32 increases the number of tx queues. Memory allocation fallback to vzalloc() when kmalloc() fails. This series tries to address following issues: - Increase the number of netdev_queue queues for rx similarly its done for tx queues by falling back to vzalloc() when memory allocation with kmalloc() fails. - Increase number of queues to 256, maximum number is equal to maximum number of vCPUS allowed in a guest. I have also done testing with multiple parallel Netperf sessions for different combination of queues and CPU's. It seems to be working fine without much increase in cpu load with increase in number of queues. I also see good increase in throughput with increase in number of queues. Though i had limitation of 8 physical CPU's. For this test: Two Hosts(Host1 & Host2) are directly connected with cable Host1 is running Guest1. Data is sent from Host2 to Guest1 via Host1. Host kernel: 3.19.0-rc2+, AMD Opteron(tm) Processor 6320 NIC : Emulex Corporation OneConnect 10Gb NIC (be3) Patch Applied %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle throughput Single Queue, 2 vCPU's ------------- Before Patch :all 0.19 0.00 0.16 0.07 0.04 0.10 0.00 0.18 0.00 99.26 57864.18 After Patch :all 0.99 0.00 0.64 0.69 0.07 0.26 0.00 1.58 0.00 95.77 57735.77 With 2 Queues, 2 vCPU's --------------- Before Patch :all 0.19 0.00 0.19 0.10 0.04 0.11 0.00 0.28 0.00 99.08 63083.09 After Patch :all 0.87 0.00 0.73 0.78 0.09 0.35 0.00 2.04 0.00 95.14 62917.03 With 4 Queues, 4 vCPU's -------------- Before Patch :all 0.20 0.00 0.21 0.11 0.04 0.12 0.00 0.32 0.00 99.00 80865.06 After Patch :all 0.71 0.00 0.93 0.85 0.11 0.51 0.00 2.62 0.00 94.27 86463.19 With 8 Queues, 8 vCPU's -------------- Before Patch :all 0.19 0.00 0.18 0.09 0.04 0.11 0.00 0.23 0.00 99.17 86795.31 After Patch :all 0.65 0.00 1.18 0.93 0.13 0.68 0.00 3.38 0.00 93.05 89459.93 With 16 Queues, 8 vCPU's -------------- After Patch :all 0.61 0.00 1.59 0.97 0.18 0.92 0.00 4.32 0.00 91.41 120951.60 ==================== Signed-off-by: -
Pankaj Gupta authored
Networking under kvm works best if we allocate a per-vCPU RX and TX queue in a virtual NIC. This requires a per-vCPU queue on the host side. It is now safe to increase the maximum number of queues. Preceding patch: 'net: allow large number of rx queues' made sure this won't cause failures due to high order memory allocations. Increase it to 256: this is the max number of vCPUs KVM supports. Size of tun_struct changes from 8512 to 10496 after this patch. This keeps pages allocated for tun_struct before and after the patch to 3. Signed-off-by:
Pankaj Gupta <pagupta@redhat.com> Reviewed-by:
David Gibson <dgibson@redhat.com> Signed-off-by:
-
