summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Update qlge driver maintainers listHarish Patil2014-09-221-3/+3
| | | | | Signed-off-by: Harish Patil <harish.patil@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* qlge: Fix compilation warningHarish Patil2014-09-221-2/+2
| | | | | | | | Fix the below warning message: qlge_main.c:1754: warning: 'lbq_desc' may be used uninitialized in this function Signed-off-by: Harish Patil <harish.patil@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* am2150: Update nmclan_cs.c to use update PCMCIA APIJeff Kirsher2014-09-221-1/+1
| | | | | | | | | | | | | Resolves compile warning about use of a deprecated function call: drivers/net/ethernet/amd/nmclan_cs.c: In function ‘nmclan_config’: drivers/net/ethernet/amd/nmclan_cs.c:624:3: warning: ‘pcmcia_request_exclusive_irq’ is deprecated (declared at include/pcmcia/ds.h:213) [-Wdeprecated-declarations] ret = pcmcia_request_exclusive_irq(link, mace_interrupt); Updates pcmcia_request_exclusive_irq() to pcmcia_request_irq(). CC: Roger Pao <rpao@paonet.org> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* udp_tunnel: Only build ip6_udp_tunnel.c when IPV6 is selectedAndy Zhou2014-09-201-1/+4
| | | | | | | | | | | | | | | | | | | Functions supplied in ip6_udp_tunnel.c are only needed when IPV6 is selected. When IPV6 is not selected, those functions are stubbed out in udp_tunnel.h. ================================================================== net/ipv6/ip6_udp_tunnel.c:15:5: error: redefinition of 'udp_sock_create6' int udp_sock_create6(struct net *net, struct udp_port_cfg *cfg, In file included from net/ipv6/ip6_udp_tunnel.c:9:0: include/net/udp_tunnel.h:36:19: note: previous definition of 'udp_sock_create6' was here static inline int udp_sock_create6(struct net *net, struct udp_port_cfg *cfg, ================================================================== Fixes: fd384412e udp_tunnel: Seperate ipv6 functions into its own file Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Andy Zhou <azhou@nicira.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'master' of ↵David S. Miller2014-09-195-88/+83Star
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next Jeff Kirsher says: ==================== Intel Wired LAN Driver Updates 2014-09-18 This series contains updates to ixgbe and ixgbevf. Ethan Zhao cleans up ixgbe and ixgbevf by removing bd_number from the adapter struct because it is not longer useful. Mark fixes ixgbe where if a hardware transmit timestamp is requested, an uninitialized workqueue entry may be scheduled. Added a check for a PTP clock to avoid that. Jacob provides a number of cleanups for ixgbe. Since we may call ixgbe_acquire_msix_vectors() prior to registering our netdevice, we should not use the netdevice specific printk and use e_dev_warn() instead. Similar to how ixgbevf handles acquiring MSI-X vectors, we can return an error code instead of relying on the flag being set. This makes it more clear that we have failed to setup MSI-X mode and will make it easier to consolidate MSI-X related code into a single function. In the case of disabling DCB, it is not an error since we still can function, we just have to let the user know. So use e_dev_warn() instead of e_err(). Added warnings for other features that are disabled when we are without MSI-X support. Cleanup flags that are no longer used or needed. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * ixgbe: remove IXGBE_FLAG_MSI(X)_CAPABLE flagsJacob Keller2014-09-181-2/+0Star
| | | | | | | | | | | | | | | | | | They were not used, and we don't need them, so we shouldn't bother with keeping values in the flags field that could be misleading. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbe: add warnings for other disabled features without MSI-X supportJacob Keller2014-09-181-2/+5
| | | | | | | | | | | | | | | | | | When we can't get MSI-X vectors, we disable a few features which require MSI-X vectors. Print warnings just like we do when disabling DCB. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbe: use e_dev_warn instead of netif_printkJacob Keller2014-09-181-7/+5Star
| | | | | | | | | | | | | | | | | | | | | | Again, we should not be directly using netif_printk, as we have our own error print routines that we generate. In addition, instead of using an early return we can just use the else block of this one line if statement. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbe: use e_dev_warn instead of e_err for displaying warningJacob Keller2014-09-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | In this case, disabling DCB is not an error. We can still function, but we just have to let the user know. In addition, since we call this during probe before allocating our netdevice structure, we should use e_dev_warn instead of e_warn. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbe: determine vector count inside ixgbe_acquire_msix_vectorsJacob Keller2014-09-181-37/+37
| | | | | | | | | | | | | | | | | | | | | | Our calculated v_budget doesn't matter except if we allocate MSI-X vectors. We shouldn't need to calculate this outside of the function, so don't. Instead, only calculate it once we attempt to acquire MSI-X vectors. This helps collocate all of the MSI-X vector code together. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbe: move msix_entries allocation into ixgbe_acquire_msix_vectorsJacob Keller2014-09-181-11/+13
| | | | | | | | | | | | | | | | | | | | | | We already have to kfree this value if we fail, and this is only part of MSI-X mode, so we should simply allocate the value where we need it. This is cleaner, and makes it a lot more obvious why we are freeing it inside of ixgbe_acquire_msix_vectors. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbe: return integer from ixgbe_acquire_msix_vectorsJacob Keller2014-09-181-14/+18
| | | | | | | | | | | | | | | | | | | | | | Similar to how ixgbevf handles acquiring MSI-X vectors, we can return an error code instead of relying on the flag being set. This makes it more clear that we have failed to setup MSI-X mode, and also will make it easier to consolidate MSI-X related code all into the single function. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbe: use e_dev_warn instead of netif_printkJacob Keller2014-09-181-5/+5
| | | | | | | | | | | | | | | | | | | | The netif_printk relies on our netdevice structure to be registered already. We may call ixgbe_acquire_msix_vectors prior to registering our netdevice, so we should not use the netdevice specific printk. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbe: Do not schedule an uninitialized workqueue entryMark Rustad2014-09-181-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | If a hardware Tx timestamp is requested, an uninitialized workqueue entry may be scheduled, especially on an 82598 adapter. Add a check for a PTP clock to avoid that. Also only apply the unlikely to the first term of the conditional. That will make the rest of the checks be in the cold path. Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Acked-by: Matthew Vick <matthew.vick@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbe: remove useless bd_number from adapter structEthan Zhao2014-09-182-6/+0Star
| | | | | | | | | | | | | | | | | | | | Because bd_number is not useful anymore, so remove it from adapter struct, or if keep it, we have to fix the boards driven counter bug in ixgbe_remove() and ixgbe_probe() only for trivial debug purpose -- other output is enough. Signed-off-by: Ethan Zhao <ethan.zhao@oracle.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbevf: remove useless bd_number from struct ixgbevf_adapterEthan Zhao2014-09-182-5/+0Star
| | | | | | | | | | | | | | | | It is useless and buggy, just remove it. Signed-off-by: Ethan Zhao <ethan.zhao@oracle.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | Merge branch 'mlx4-next'David S. Miller2014-09-1910-22/+138
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Or Gerlitz says: ==================== mlx4: CQE/EQE stride support This series from Ido Shamay is intended for archs having cache line larger then 64 bytes. Since our CQE/EQEs are generally 64B in those systems, HW will write twice to the same cache line consecutively, causing pipe locks due to he hazard prevention mechanism. For elements in a cyclic buffer, writes are consecutive, so entries smaller than a cache line should be avoided, especially if they are written at a high rate. Reduce consecutive writes to same cache line in CQs/EQs, by allowing the driver to increase the distance between entries so that each will reside in a different cache line. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net/mlx4_en: Add mlx4_en_get_cqe helperIdo Shamay2014-09-194-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function derives the base address of the CQE from the CQE size, and calculates the real CQE context segment in it from the factor (this is like before). Before this change the code used the factor to calculate the base address of the CQE as well. The factor indicates in which segment of the cqe stride the cqe information is located. For 32-byte strides, the segment is 0, and for 64 byte strides, the segment is 1 (bytes 32..63). Using the factor was ok as long as we had only 32 and 64 byte strides. However, with larger strides, the factor is zero, and so cannot be used to calculate the base of the CQE. The helper uses the same method of CQE buffer pulling made by all other components that reads the CQE buffer (mlx4_ib driver and libmlx4). Signed-off-by: Ido Shamay <idos@mellanox.com> Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net/mlx4_core: Cache line EQE size supportIdo Shamay2014-09-191-11/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable mlx4 interrupt handler to work with EQE stride feature, The feature may be enabled when cache line is bigger than 64B. The EQE size will then be the cache line size, and the context segment resides in [0-31] offset. Signed-off-by: Ido Shamay <idos@mellanox.com> Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net/mlx4_core: Enable CQE/EQE stride supportIdo Shamay2014-09-195-7/+108
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This feature is intended for archs having cache line larger then 64B. Since our CQE/EQEs are generally 64B in those systems, HW will write twice to the same cache line consecutively, causing pipe locks due to he hazard prevention mechanism. For elements in a cyclic buffer, writes are consecutive, so entries smaller than a cache line should be avoided, especially if they are written at a high rate. Reduce consecutive writes to same cache line in CQs/EQs, by allowing the driver to increase the distance between entries so that each will reside in a different cache line. Until the introduction of this feature, there were two types of CQE/EQE: 1. 32B stride and context in the [0-31] segment 2. 64B stride and context in the [32-63] segment This feature introduces two additional types: 3. 128B stride and context in the [0-31] segment (128B cache line) 4. 256B stride and context in the [0-31] segment (256B cache line) Modify the mlx4_core driver to query the device for the CQE/EQE cache line stride capability and to enable that capability when the host cache line size is larger than 64 bytes (supported cache lines are 128B and 256B). The mlx4 IB driver and libmlx4 need not be aware of this change. The PF context behaviour is changed to require this change in VF drivers running on such archs. Signed-off-by: Ido Shamay <idos@mellanox.com> Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: fix sparse warnings in SNMP_UPD_PO_STATS(_BH)Sabrina Dubroca2014-09-191-6/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ptr used to be a non __percpu pointer (result of a this_cpu_ptr assignment, 7d720c3e4f0c4 ("percpu: add __percpu sparse annotations to net")). Since d25398df59b56 ("net: avoid reloads in SNMP_UPD_PO_STATS"), that's no longer the case, SNMP_UPD_PO_STATS uses this_cpu_add and ptr is now __percpu. Silence sparse warnings by preserving the original type and annotation, and remove the out-of-date comment. warning: incorrect type in initializer (different address spaces) expected unsigned long long *ptr got unsigned long long [noderef] <asn:3>*<noident> warning: incorrect type in initializer (different address spaces) expected void const [noderef] <asn:3>*__vpp_verify got unsigned long long *<noident> warning: incorrect type in initializer (different address spaces) expected void const [noderef] <asn:3>*__vpp_verify got unsigned long long *<noident> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch 'fou-next'David S. Miller2014-09-1914-20/+802
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tom Herbert says: ==================== net: foo-over-udp (fou) This patch series implements foo-over-udp. The idea is that we can encapsulate different IP protocols in UDP packets. The rationale for this is that networking devices such as NICs and switches are usually implemented with UDP (and TCP) specific mechanims for processing. For instance, many switches and routers will implement a 5-tuple hash for UDP packets to perform Equal Cost Multipath Routing (ECMP) or RSS (on NICs). Many NICs also only provide rudimentary checksum offload (basic TCP and UDP packet), with foo-over-udp we may be able to leverage these NICs to offload checksums of tunneled packets (using checksum unnecessary conversion and eventually remote checksum offload) An example encapsulation of IPIP over FOU is diagrammed below. As illustrated, the packet overhead for FOU is the 8 byte UDP header. +------------------+ | IPv4 hdr | +------------------+ | UDP hdr | +------------------+ | IPv4 hdr | +------------------+ | TCP hdr | +------------------+ | TCP payload | +------------------+ Conceptually, FOU should be able to encapsulate any IP protocol. The FOU header (UDP hdr.) is essentially an inserted header between the IP header and transport, so in the case of TCP or UDP encapsulation the pseudo header would be based on the outer IP header and its length field must not include the UDP header. * Receive In this patch set the RX path for FOU is implemented in a new fou module. To enable FOU for a particular protocol, a UDP-FOU socket is opened to the port to receive FOU packets. The socket is mapped to the IP protocol for the packets. The XFRM mechanism used to receive encapsulated packets (udp_encap_rcv) for the port. Upon reception, the UDP is removed and packet is reinjected in the stack for the corresponding protocol associated with the socket (return -protocol from udp_encap_rcv function). GRO is provided with the appropriate fou_gro_receive and fou_gro_complete. These routines need to know the encapsulation protocol so we save that in udp_offloads structure with the port and pass it in the napi_gro_cb structure. * TX This patch series implements FOU transmit encapsulation for IPIP, GRE, and SIT. This done by some common infrastructure in ip_tunnel including an ip_tunnel_encap to perform FOU encapsulation and common configuration to enable FOU on IP tunnels. FOU is configured on existing tunnels and does not create any new interfaces. The transmit and receive paths are independent, so use of FOU may be assymetric between tunnel endpoints. * Configuration The fou module using netlink to configure FOU receive ports. The ip command can be augmented with a fou subcommand to support this. e.g. to configure FOU for IPIP on port 5555: ip fou add port 5555 ipproto 4 GRE, IPIP, and SIT have been modified with netlink commands to configure use of FOU on transmit. The "ip link" command will be augmented with an encap subcommand (for supporting various forms of secondary encapsulation). For instance, to configure an ipip tunnel with FOU on port 5555: ip link add name tun1 type ipip \ remote 192.168.1.1 local 192.168.1.2 ttl 225 \ encap fou encap-sport auto encap-dport 5555 * Notes - This patch set does not implement GSO for FOU. The UDP encapsulation code assumes TEB, so that will need to be reimplemented. - When a packet is received through FOU, the UDP header is not actually removed for the skbuf, pointers to transport header and length in the IP header are updated (like in ESP/UDP RX). A side effect is the IP header will now appear to have an incorrect checksum by an external observer (e.g. tcpdump), it will be off by sizeof UDP header. If necessary we could adjust the checksum to compensate. - Performance results are below. My expectation is that FOU should entail little overhead (clearly there is some work to do :-) ). Optimizing UDP socket lookup for encapsulation ports should help significantly. - I really don't expect/want devices to have special support for any of this. Generic checksum offload mechanisms (NETIF_HW_CSUM and use of CHECKSUM_COMPLETE) should be sufficient. RSS and flow steering is provided by commonly implemented UDP hashing. GRO/GSO seem fairly comparable with LRO/TSO already. * Performance Ran netperf TCP_RR and TCP_STREAM tests across various configurations. This was performed on bnx2x and I disabled TSO/GSO on sender to get fair comparison for FOU versus non-FOU. CPU utilization is reported for receive in TCP_STREAM. GRE IPv4, FOU, UDP checksum enabled TCP_STREAM 24.85% CPU utilization 9310.6 Mbps TCP_RR 94.2% CPU utilization 155/249/460 90/95/99% latencies 1.17018e+06 tps IPv4, FOU, UDP checksum disabled TCP_STREAM 31.04% CPU utilization 9302.22 Mbps TCP_RR 94.13% CPU utilization 154/239/419 90/95/99% latencies 1.17555e+06 tps IPv4, no FOU TCP_STREAM 23.13% CPU utilization 9354.58 Mbps TCP_RR 90.24% CPU utilization 156/228/360 90/95/99% latencies 1.18169e+06 tps IPIP FOU, UDP checksum enabled TCP_STREAM 24.13% CPU utilization 9328 Mbps TCP_RR 94.23 149/237/429 90/95/99% latencies 1.19553e+06 tps FOU, UDP checksum disabled TCP_STREAM 29.13% CPU utilization 9370.25 Mbps TCP_RR 94.13% CPU utilization 149/232/398 90/95/99% latencies 1.19225e+06 tps No FOU TCP_STREAM 10.43% CPU utilization 5302.03 Mbps TCP_RR 51.53% CPU utilization 215/324/475 90/95/99% latencies 864998 tps SIT FOU, UDP checksum enabled TCP_STREAM 30.38% CPU utilization 9176.76 Mbps TCP_RR 96.9% CPU utilization 170/281/581 90/95/99% latencies 1.03372e+06 tps FOU, UDP checksum disabled TCP_STREAM 39.6% CPU utilization 9176.57 Mbps TCP_RR 97.14% CPU utilization 167/272/548 90/95/99% latencies 1.03203e+06 tps No FOU TCP_STREAM 11.2% CPU utilization 4636.05 Mbps TCP_RR 59.51% CPU utilization 232/346/489 90/95/99% latencies 813199 tps v2: - Removed encap IP tunnel ioctls, configuration is done by netlink only. - Don't export fou_create and fou_destroy, they are currently intended to be called within fou module only. - Filled on tunnel netlink structures and functions for new values. v3: - Fixed change logs for some of the patches. - Remove inline from fou_gro_receive and fou_gro_complete, let compiler decide on these. v4: - Don't need to cast void in fou_from_sock - Removed incorrest htons for port in fou_destroy - Some minor cleanup for readability ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * | gre: Setup and TX path for gre/UDP foo-over-udp encapsulationTom Herbert2014-09-192-5/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added netlink attrs to configure FOU encapsulation for GRE, netlink handling of these flags, and properly adjust MTU for encapsulation. ip_tunnel_encap is called from ip_tunnel_xmit to actually perform FOU encapsulation. Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | ipip: Setup and TX path for ipip/UDP foo-over-udp encapsulationTom Herbert2014-09-191-1/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add netlink handling for IP tunnel encapsulation parameters and and adjustment of MTU for encapsulation. ip_tunnel_encap is called from ip_tunnel_xmit to actually perform FOU encapsulation. Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | sit: Setup and TX path for sit/UDP foo-over-udp encapsulationTom Herbert2014-09-191-10/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | Added netlink handling of IP tunnel encapulation paramters, properly adjust MTU for encapsulation. Added ip_tunnel_encap call to ipip6_tunnel_xmit to actually perform FOU encapsulation. Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: Changes to ip_tunnel to support foo-over-udp encapsulationTom Herbert2014-09-193-2/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes IP tunnel to support (secondary) encapsulation, Foo-over-UDP. Changes include: 1) Adding tun_hlen as the tunnel header length, encap_hlen as the encapsulation header length, and hlen becomes the grand total of these. 2) Added common netlink define to support FOU encapsulation. 3) Routines to perform FOU encapsulation. Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | fou: Add GRO supportTom Herbert2014-09-193-2/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement fou_gro_receive and fou_gro_complete, and populate these in the correponsing udp_offloads for the socket. Added ipproto to udp_offloads and pass this from UDP to the fou GRO routine in proto field of napi_gro_cb structure. Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | fou: Support for foo-over-udp RX pathTom Herbert2014-09-194-0/+322
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch provides a receive path for foo-over-udp. This allows direct encapsulation of IP protocols over UDP. The bound destination port is used to map to an IP protocol, and the XFRM framework (udp_encap_rcv) is used to receive encapsulated packets. Upon reception, the encapsulation header is logically removed (pointer to transport header is advanced) and the packet is reinjected into the receive path with the IP protocol indicated by the mapping. Netlink is used to configure FOU ports. The configuration information includes the port number to bind to and the IP protocol corresponding to that port. This should support GRE/UDP (http://tools.ietf.org/html/draft-yong-tsvwg-gre-in-udp-encap-02), as will as the other IP tunneling protocols (IPIP, SIT). Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: Export inet_offloads and inet6_offloadsTom Herbert2014-09-192-0/+2
|/ / | | | | | | | | | | | | Want to be able to use these in foo-over-udp offloads, etc. Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: sched: cls_u32: rcu can not be last nodeJohn Fastabend2014-09-191-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | tc_u32_sel 'sel' in tc_u_knode expects to be the last element in the structure and pads the structure with tc_u32_key fields for each key. kzalloc(sizeof(*n) + s->nkeys*sizeof(struct tc_u32_key), GFP_KERNEL) CC: Eric Dumazet <edumazet@google.com> Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: sched: use __skb_queue_head_init() where applicableEric Dumazet2014-09-192-2/+2
| | | | | | | | | | | | | | | | | | | | | | pfifo_fast and htb use skb lists, without needing their spinlocks. (They instead use the standard qdisc lock) We can use __skb_queue_head_init() instead of skb_queue_head_init() to be consistent. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch 'bnx2x-next'David S. Miller2014-09-198-81/+296
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Yuval Mintz says: ==================== bnx2x: Support new Multi-function modes This patch series adds support for 2 new Multi-function modes - Unified Fabric Port [UFP] as well as nic partitioning 1.5 [NPAR1.5]. With the addition of the new multi-function modes, the series also revises some of the storage-related multi-function macros. [Do notice this series has several small issues with checkpatch] ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * | bnx2x: Add a fallback multi-function mode NPAR1.5Yuval Mintz2014-09-193-21/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using new Multi-function modes it's possible that due to incompatible configuration management FW will fallback into an existing mode. Notice that at the moment this fallback is exactly the same as the already existing switch-independent multi-function mode, but we still use existing infrastructure to hold this information [in case some small differences will arise in the future]. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: Dmitry Kravkov <Dmitry.Kravkov@qlogic.com> Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | bnx2x: New multi-function mode: UFPYuval Mintz2014-09-196-18/+200
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for a new multi-function mode based on the Unified Fabric Port system specifications. Support includes configuration of: 1. Outer vlan tags. 2. Bandwidth settings. 3. Virtual link enable/disable. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: Dmitry Kravkov <Dmitry.Kravkov@qlogic.com> Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | bnx2x: Changes with storage & MAC macrosDmitry Kravkov2014-09-195-42/+54
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | Rearrange macros to query for storage-only modes in different MF environment. Improves the readibility and maintainability of the code. E.g.: - if (IS_MF_STORAGE_SD(bp) || IS_MF_FCOE_AFEX(bp)) + if (IS_MF_STORAGE_ONLY(bp)) In addition, this removes the need for bnx2x_is_valid_ether_addr(). Signed-off-by: Dmitry Kravkov <Dmitry.Kravkov@qlogic.com> Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch 'fec-next'David S. Miller2014-09-1911-22/+62
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Florian Fainelli says: ==================== net: phy: Broadcom BCM7xxx PHY workaround update This patch sets the change to of_phy_connect() that you have seen before, this time with the full context of why it is useful and applicable here. Due to some design decision, the internal PHY on Broadcom BCM7xxx chips is not entirely self contained and does not report its internal revision through MII_PHYSID2, that is left to external PHY designs. This forces us to get the PHY revision from the GENET and SF2 switch drivers because those two peripherals integrate such a PHY and do contain the PHY revision in their registers. The approach taken here is hopefully easy to extend to similar needs for other chips/ as well. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: phy: bcm7xxx: utilize PHY revision in config_initFlorian Fainelli2014-09-191-6/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that the GENET and SF2 drivers have been updated to communicate us what is the revision of the BCM7xxx integrated PHY, utilize that information in the config_init() callback to call into the appropriate workaround function based on our revision. While at it, we also print the revision and patch level to help debug new chips. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: dsa: bcm_sf2: communicate integrated PHY revision to PHY driverFlorian Fainelli2014-09-193-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The integrated BCM7xxx PHY contains no useful revision information in its MII_PHYSID2 bits 3:0, that information is instead contained in the SWITCH_REG_PHY_REVISION register. Read this register, store its value, and return it by implementing the dsa_switch::get_phy_flags() callback accordingly. The register layout is already matching what the BCM7xxx PHY driver is expecting to find. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: dsa: allow switch drivers to specify phy_device::dev_flagsFlorian Fainelli2014-09-192-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some switch drivers (e.g: bcm_sf2) may have to communicate specific workarounds or flags towards the PHY device driver. Allow switches driver to be delegated that task by introducing a get_phy_flags() callback which will do just that. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: bcmgenet: communicate integrated PHY revision to PHY driverFlorian Fainelli2014-09-193-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The integrated BCM7xxx PHY contains no useful revision information in its MII_PHYSID2 bits 3:0, that information is instead contained in the GENET hardware block. We already read the GENET 32-bit revision register, so store the integrated PHY revision in the driver private structure, and then communicate this revision value to the PHY driver by overriding the phy_flags value. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: bcmgenet: remove PHY_BRCM_100MBPS_WARFlorian Fainelli2014-09-192-11/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we have removed the need for the PHY_BRCM_100MBPS_WAR flag, we can remove it from the GENET driver and the broadcom shared header file. The PHY driver checks the PHY supported bitmask instead. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: phy: bcm7xxx: do not use PHY_BRCM_100MBPS_WARFlorian Fainelli2014-09-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | There is no need for the PHY driver to check PHY_BRCM_100MBPS_WAR since that is redundant with checking the PHY device supported features. Get rid of that workaround flag. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net: phy: broadcom: add helper for PHY revision and patch levelFlorian Fainelli2014-09-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Broadcom BCM7xxx internal PHYs do not contain any useful revision information in the low 4-bits of their MII_PHYSID2 (MII register 3) which could allow us to properly identify them. As a result, we need the actual hardware block integrating these PHYs: GENET or the SF2 switch to tell us what revision they are built with. To assist with that, add two helper macros for fetching the the PHY revision and patch level from the struct phy_device::dev_flags. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | of: mdio: honor flags passed to of_phy_connectFlorian Fainelli2014-09-191-0/+2
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit f9a8f83b04e0 ("net: phy: remove flags argument from phy_{attach, connect, connect_direct}") removed the flags argument to the PHY library calls to: phy_{attach,connect,connect_direct}. Most Device Tree aware drivers call of_phy_connect() with the flag argument set to 0, but some of them might want to set a different value there in order for the PHY driver to key a specific behavior based on the phy_device::phy_flags value. Allow such drivers to set custom phy_flags as part of the of_phy_connect() call since of_phy_connect() does start the PHY state machine, it will call into the PHY driver config_init() callback which is usually where a specific phy_flags value is important. Fixes: f9a8f83b04e0 ("net: phy: remove flags argument from phy_{attach, connect, connect_direct}") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: add alloc_skb_with_frags() helperEric Dumazet2014-09-193-63/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | Extract from sock_alloc_send_pskb() code building skb with frags, so that we can reuse this in other contexts. Intent is to use it from tcp_send_rcvq(), tcp_collapse(), ... We also want to replace some skb_linearize() calls to a more reliable strategy in pathological cases where we need to reduce number of frags. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | tcp: do not fake tcp headers in tcp_send_rcvq()Eric Dumazet2014-09-191-9/+4Star
| | | | | | | | | | | | | | | | | | Now we no longer rely on having tcp headers for skbs in receive queue, tcp repair do not need to build fake ones. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch 'udp-tunnel-common'David S. Miller2014-09-196-164/+294
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Andy Zhou says: ==================== Refactor vxlan and l2tp to use new common UDP tunnel APIs This patch series add a few more UDP tunnel APIs and refactoring current UDP tunnel based protocols, vxlan and l2tp to make use of the new APIs. The added APIs are setup_udp_tunnel_sock(), udp_tunnel_xmit_skb() and udp_tunnel_sock_release(). Those implementation logics already exist in current vxlan and l2tp implementation. Move them to common APIs to reduce code duplications. Also split udp_tunnel.c into net/ipv4/udp_tunnel.c and net/ipv6/ip6_udp_tunnel.c to maintain proper IP protocol separation. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * | l2tp: Refactor l2tp core driver to make use of the common UDP tunnel functionsAndy Zhou2014-09-191-14/+10Star
| | | | | | | | | | | | | | | | | | | | | Simplify l2tp implementation using common UDP tunnel APIs. Signed-off-by: Andy Zhou <azhou@nicira.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | vxlan: Refactor vxlan driver to make use of the common UDP tunnel functions.Andy Zhou2014-09-191-83/+22Star
| | | | | | | | | | | | | | | | | | | | | Simplify vxlan implementation using common UDP tunnel APIs. Signed-off-by: Andy Zhou <azhou@nicira.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | udp-tunnel: Add a few more UDP tunnel APIsAndy Zhou2014-09-193-1/+151
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added a few more UDP tunnel APIs that can be shared by UDP based tunnel protocol implementation. The main ones are highlighted below. setup_udp_tunnel_sock() configures UDP listener socket for receiving UDP encapsulated packets. udp_tunnel_xmit_skb() and upd_tunnel6_xmit_skb() transmit skb using UDP encapsulation. udp_tunnel_sock_release() closes the UDP tunnel listener socket. Signed-off-by: Andy Zhou <azhou@nicira.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-06-30 04:25:21 +0200