- 20 Jul, 2018 1 commit
-
-
Benedict Wong authored
In order to remove performance impact of having the extra u32 in every single flowi, this change removes the flowi_xfrm struct, prefering to take the if_id as a method parameter where needed. In the inbound direction, if_id is only needed during the __xfrm_check_policy() function, and the if_id can be determined at that point based on the skb. As such, xfrmi_decode_session() is only called with the skb in __xfrm_check_policy(). In the outbound direction, the only place where if_id is needed is the xfrm_lookup() call in xfrmi_xmit2(). With this change, the if_id is directly passed into the xfrm_lookup_with_ifid() call. All existing callers can still call xfrm_lookup(), which uses a default if_id of 0. This change does not change any behavior of XFRMIs except for improving overall system performance via flowi size reduction. This change has been tested against the Android Kernel Networking Tests: https://android.googlesource.com/kernel/tests/+/master/net/testSigned-off-by: Benedict Wong <benedictwong@google.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
-
- 19 Jul, 2018 1 commit
-
-
Shannon Nelson authored
The offload_handle should be an opaque data cookie for the driver to use, much like the data cookie for a timer or alarm callback. Thus, the XFRM stack should not be checking for non-zero, because the driver might use that to store an array reference, which could be zero, or some other zero but meaningful value. We can remove the checks for non-zero because there are plenty other attributes also being checked to see if there is an offload in place for the SA in question. Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
-
- 11 Jul, 2018 2 commits
-
-
Arnd Bergmann authored
get_seconds() is deprecated because it can overflow on 32-bit architectures. For the xfrm_state->lastused member, we treat the data as a 64-bit number already, so we just need to use the right accessor that works on both 32-bit and 64-bit machines. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
-
Arnd Bergmann authored
The lifetime managment uses '__u64' timestamps on the user space interface, but 'unsigned long' for reading the current time in the kernel with get_seconds(). While this is probably safe beyond y2038, it will still overflow in 2106, and the get_seconds() call is deprecated because fo that. This changes the xfrm time handling to use time64_t consistently, along with reading the time using the safer ktime_get_real_seconds(). It still suffers from problems that can happen from a concurrent settimeofday() call or (to a lesser degree) a leap second update, but since the time stamps are part of the user API, there is nothing we can do to prevent that. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
-
- 01 Jul, 2018 1 commit
-
-
Nathan Harold authored
Allow UPDSA to change "set mark" to permit policy separation of packet routing decisions from SA keying in systems that use mark-based routing. The set mark, used as a routing and firewall mark for outbound packets, is made update-able which allows routing decisions to be handled independently of keying/SA creation. To maintain consistency with other optional attributes, the set mark is only updated if sent with a non-zero value. The per-SA lock and the xfrm_state_lock are taken in that order to avoid a deadlock with xfrm_timer_handler(), which also takes the locks in that order. Signed-off-by: Nathan Harold <nharold@google.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
-
- 25 Jun, 2018 1 commit
-
-
Florian Westphal authored
Kristian Evensen says: In a project I am involved in, we are running ipsec (Strongswan) on different mt7621-based routers. Each router is configured as an initiator and has around ~30 tunnels to different responders (running on misc. devices). Before the flow cache was removed (kernel 4.9), we got a combined throughput of around 70Mbit/s for all tunnels on one router. However, we recently switched to kernel 4.14 (4.14.48), and the total throughput is somewhere around 57Mbit/s (best-case). I.e., a drop of around 20%. Reverting the flow cache removal restores, as expected, performance levels to that of kernel 4.9. When pcpu xdst exists, it has to be validated first before it can be used. A negative hit thus increases cost vs. no-cache. As number of tunnels increases, hit rate decreases so this pcpu caching isn't a viable strategy. Furthermore, the xdst cache also needs to run with BH off, so when removing this the bh disable/enable pairs can be removed too. Kristian tested a 4.14.y backport of this change and reported increased performance: In our tests, the throughput reduction has been reduced from around -20% to -5%. We also see that the overall throughput is independent of the number of tunnels, while before the throughput was reduced as the number of tunnels increased. Reported-by: Kristian Evensen <kristian.evensen@gmail.com> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
-
- 23 Jun, 2018 25 commits
-
-
Steffen Klassert authored
This patch adds support for virtual xfrm interfaces. Packets that are routed through such an interface are guaranteed to be IPsec transformed or dropped. It is a generic virtual interface that ensures IPsec transformation, no need to know what happens behind the interface. This means that we can tunnel IPv4 and IPv6 through the same interface and support all xfrm modes (tunnel, transport and beet) on it. Co-developed-by: Lorenzo Colitti <lorenzo@google.com> Co-developed-by: Benedict Wong <benedictwong@google.com> Signed-off-by: Lorenzo Colitti <lorenzo@google.com> Signed-off-by: Benedict Wong <benedictwong@google.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Acked-by: Shannon Nelson <shannon.nelson@oracle.com> Tested-by: Benedict Wong <benedictwong@google.com> Tested-by: Antony Antony <antony@phenome.org> Reviewed-by: Eyal Birger <eyal.birger@gmail.com>
-
Steffen Klassert authored
This patch adds the xfrm interface id as a lookup key for xfrm states and policies. With this we can assign states and policies to virtual xfrm interfaces. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Acked-by: Shannon Nelson <shannon.nelson@oracle.com> Acked-by: Benedict Wong <benedictwong@google.com> Tested-by: Benedict Wong <benedictwong@google.com> Tested-by: Antony Antony <antony@phenome.org> Reviewed-by: Eyal Birger <eyal.birger@gmail.com>
-
Steffen Klassert authored
Add a new flowi_xfrm structure with informations needed to do a xfrm lookup. At the moment it keeps the informations about the new xfrm interface id needed to lookup xfrm interfaces that are introduced with a followup patch. We need this new lookup key as other possible keys, like the ifindex is already part of the xfrm selector and used as a key to enforce the output device after the transformation in the policy/state lookup. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Acked-by: Shannon Nelson <shannon.nelson@oracle.com> Acked-by: Benedict Wong <benedictwong@google.com> Tested-by: Benedict Wong <benedictwong@google.com> Tested-by: Antony Antony <antony@phenome.org> Reviewed-by: Eyal Birger <eyal.birger@gmail.com>
-
Steffen Klassert authored
We already support setting an output mark at the xfrm_state, unfortunately this does not support the input direction and masking the marks that will be applied to the skb. This change adds support applying a masked value in both directions. The existing XFRMA_OUTPUT_MARK number is reused for this purpose and as it is now bi-directional, it is renamed to XFRMA_SET_MARK. An additional XFRMA_SET_MARK_MASK attribute is added for setting the mask. If the attribute mask not provided, it is set to 0xffffffff, keeping the XFRMA_OUTPUT_MARK existing 'full mask' semantics. Co-developed-by: Tobias Brunner <tobias@strongswan.org> Co-developed-by: Eyal Birger <eyal.birger@gmail.com> Co-developed-by: Lorenzo Colitti <lorenzo@google.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Tobias Brunner <tobias@strongswan.org> Signed-off-by: Eyal Birger <eyal.birger@gmail.com> Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
-
David S. Miller authored
Heiner Kallweit says: ==================== r8169: enable ASPM on RTL8168E-VL This patch series enables ASPM for the RTL8168E-VL and aligns ASPM entry latency handling with the vendor driver before. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Let's enable ASPM also on the RTL8168E-VL (chip version 34). Works fine on my Zotac Mini PC with this chip. Temperature when being idle is significantly lower than before due to reaching deeper PC states. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
The r8168 vendor driver always uses value 0x27. In r8169 we have few chips where 0x17 is used. So far this didn't matter because ASPM was disabled anyway. Now that ASPM was re-enabled let's also use 0x27 only. One of the chips affected by this change is RTL8168E-VL, on my system with this chip value 0x27 works fine. In addition rename rtl_csi_access_enable_2() to rtl_set_def_aspm_entry_latency() to make clear that we set the default ASPM entry latency. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Paul Burton says: ==================== net: pch_gbe: Cleanups This series begins the process of cleaning up the pch_gbe network driver. Whilst my ultimate goal is to add support for using this driver on the MIPS Boston development board, this series sets that aside in favor of making some more general cleanups. My hope is that this will both make the driver a little more maleable & reduce the probability of me gouging out my eyes. Applies cleanly atop net-next as of 5424ea27 ("netns: get more entropy from net_hash_mix()"). ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paul Burton authored
Refactor pch_gbe_set_multi in order to avoid unnecessary indentation & make it clearer what the code is doing. The one behavioral change from this patch is that we'll no longer configure the MAC address registers for multicast addresses when the IFF_PROMISC or IFF_ALLMULTI flags are set. In these cases, just as when we want to monitor more multicast addresses than we have MAC address registers, we disable multicast filtering so the MAC address registers are unused. Signed-off-by: Paul Burton <paul.burton@mips.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paul Burton authored
The pch_gbe driver sets up multicast address filters using a convoluted mechanism by which pch_gbe_set_multi allocates an array to hold multicast addresses, copies desired addresses into that array, calls a pch_gbe_mac_mc_addr_list_update function which copies addresses out of that array into MAC registers, then frees the array. This patch simplifies this somewhat by inlining pch_gbe_mac_mc_addr_list_update into pch_gbe_set_multi, and removing the requirement for the MAC addresses to stored consecutively in a single array. Signed-off-by: Paul Burton <paul.burton@mips.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paul Burton authored
Make use of the module_pci_driver() macro to remove some needless boilerplate code from the pch_gbe driver. This does have the side effect of removing the print of the driver's version during probe, but this is pretty useless information anyway - the version has changed only once whilst the driver has been in mainline, despite many changes being made to it before and since. Signed-off-by: Paul Burton <paul.burton@mips.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paul Burton authored
The pch_gbe driver includes some code which appears to be an attempt to work around a problem with the pch_gbe_free_rx_resources & pch_gbe_free_tx_resources functions that no longer exists. Remove the code guarded by the never-defined RINGFREE preprocessor macro. Signed-off-by: Paul Burton <paul.burton@mips.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paul Burton authored
The pch_gbe driver currently presumes that the PHY is connected using RGMII, and would need further work to support other buses. It includes a define which is always set that conditionalises some of the RGMII-specific code regardless. Remove it. If we do ever support different MII buses then preprocessor defines won't be the best way to select between them anyway. Signed-off-by: Paul Burton <paul.burton@mips.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paul Burton authored
The pch_gbe driver calls a pch_gbe_hal_setup_init_funcs function which ultimately sets the value of one field in struct pch_gbe_phy_info in a convoluted way. This patch removes pch_gbe_hal_setup_init_funcs in favor of inlining it, and in turn its callee pch_gbe_plat_init_function_pointers, into the single caller pch_gbe_sw_init. With this pch_gbe_api.c & pch_gbe_api.h are essentially empty, so they are removed & inclusions of the latter replaced with pch_gbe_phy.h which was previously being included via pch_gbe_api.h. Signed-off-by: Paul Burton <paul.burton@mips.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paul Burton authored
For some reason the pch_gbe driver contains a struct pch_gbe_functions with pointers used by a HAL abstraction layer, even though there is only one implementation of each function. This patch removes the get_bus_info abstraction. Its single implementation (pch_gbe_plat_get_bus_info) only sets values within a struct pch_gbe_bus_info which is never used, so we simply remove the call to it in pch_gbe_probe & remove struct pch_gbe_bus_info entirely. Now that struct pch_gbe_functions is empty we remove it entirely too. Signed-off-by: Paul Burton <paul.burton@mips.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paul Burton authored
For some reason the pch_gbe driver contains a struct pch_gbe_functions with pointers used by a HAL abstraction layer, even though there is only one implementation of each function. This patch removes the init_hw abstraction in favor of inlining its single implementation (pch_gbe_plat_init_hw) into its single caller (pch_gbe_reset). Signed-off-by: Paul Burton <paul.burton@mips.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paul Burton authored
For some reason the pch_gbe driver contains a struct pch_gbe_functions with pointers used by a HAL abstraction layer, even though there is only one implementation of each function. This patch removes the read_phy_reg & write_phy_reg abstractions in favor of calling pch_gbe_phy_read_reg_miic & pch_gbe_phy_write_reg_miic directly. Signed-off-by: Paul Burton <paul.burton@mips.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paul Burton authored
For some reason the pch_gbe driver contains a struct pch_gbe_functions with pointers used by a HAL abstraction layer, even though there is only one implementation of each function. This patch removes the reset_phy abstraction in favor of calling pch_gbe_phy_hw_reset directly. Signed-off-by: Paul Burton <paul.burton@mips.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paul Burton authored
For some reason the pch_gbe driver contains a struct pch_gbe_functions with pointers used by a HAL abstraction layer, even though there is only one implementation of each function. This patch removes the sw_reset_phy abstraction, which it turns out is never even used. Its one implementation, which is already called directly within the same translation unit, can therefore be made static and removed from the pch_gbe_phy.h header. Signed-off-by: Paul Burton <paul.burton@mips.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paul Burton authored
For some reason the pch_gbe driver contains a struct pch_gbe_functions with pointers used by a HAL abstraction layer, even though there is only one implementation of each function. This patch removes the read_mac_addr abstraction in favor of calling pch_gbe_mac_read_mac_addr directly. Since this is defined in the same translation unit as all of its callers, we can make it static & remove it from the pch_gbe.h header. Signed-off-by: Paul Burton <paul.burton@mips.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paul Burton authored
For some reason the pch_gbe driver contains a struct pch_gbe_functions with pointers used by a HAL abstraction layer, even though there is only one implementation of each function. This patch removes the power_up_phy & power_down_phy abstractions in favor of calling pch_phy_power_up & pch_phy_power_down directly. Signed-off-by: Paul Burton <paul.burton@mips.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paul Burton authored
The pch_gbe driver includes a 'copybreak' parameter which appears to have been copied from the e1000e driver but is entirely unused. Remove the dead code. Signed-off-by: Paul Burton <paul.burton@mips.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
struct net are effectively allocated from order-1 pages on x86, with one object per slab, meaning that the 13 low order bits of their addresses are zero. Once shifted by L1_CACHE_SHIFT, this leaves 7 zero-bits, meaning that net_hash_mix() does not help spreading objects on various hash tables. For example, TCP listen table has 32 buckets, meaning that all netns use the same bucket for port 80 or port 443. Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Maciej Żenczykowski <maze@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joe Perches authored
random_ether_addr is a #define for eth_random_addr which is generally preferred in kernel code by ~3:1 Convert the uses of random_ether_addr to enable removing the #define Miscellanea: o Convert &vfmac[0] to equivalent vfmac and avoid unnecessary line wrap Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Geert Uytterhoeven authored
The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer functionality only, can still be compiled if GPIOLIB is not enabled. Relax the dependency on GPIOLIB if COMPILE_TEST is enabled, where appropriate. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 22 Jun, 2018 9 commits
-
-
Kai-Heng Feng authored
On Intel platforms (Skylake and newer), ASPM support in r8169 is the last missing puzzle to let CPU's Package C-State reaches PC8. Without ASPM support, the CPU cannot reach beyond PC3. PC8 can save additional ~3W in comparison with PC3 on a Coffee Lake platform, Dell G3 3779. This is based on the work from Chunhao Lin <hau@realtek.com>. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kai-Heng Feng authored
Enable or disable ASPM should be done in PCI core instead of in the device driver. Commit ba04c7c9 ("r8169: disable ASPM") uses pci_disable_link_state() to disable ASPM, but it's not the best way to do it. If the device really wants to disable ASPM, we can use a quirk in PCI core to prevent the PCI core from setting ASPM before probe. Let's remove pci_disable_link_state() for now. Use PCI core quirks if any regression happens. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
This commit makes BBR use only the MSS (without any headers) to calculate pacing rates when internal TCP-layer pacing is used. This is necessary to achieve the correct pacing behavior in this case, since tcp_internal_pacing() uses only the payload length to calculate pacing delays. Signed-off-by: Kevin Yang <yyd@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Sebastian Andrzej Siewior says: ==================== net/usb: Use irqsave in USB's complete callback This is about using _irqsave() primitives in the completion callback in order to get rid of local_irq_save() in __usb_hcd_giveback_urb(). ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sebastian Andrzej Siewior authored
The USB completion callback does not disable interrupts while acquiring the lock. We want to remove the local_irq_disable() invocation from __usb_hcd_giveback_urb() and therefore it is required for the callback handler to disable the interrupts while acquiring the lock. The callback may be invoked either in IRQ or BH context depending on the USB host controller. Use the _irqsave() variant of the locking primitives. Cc: Petko Manolov <petkan@nucleusys.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sebastian Andrzej Siewior authored
The USB completion callback does not disable interrupts while acquiring the lock. We want to remove the local_irq_disable() invocation from __usb_hcd_giveback_urb() and therefore it is required for the callback handler to disable the interrupts while acquiring the lock. The callback may be invoked either in IRQ or BH context depending on the USB host controller. Use the _irqsave() variant of the locking primitives. Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sebastian Andrzej Siewior authored
The USB completion callback does not disable interrupts while acquiring the lock. We want to remove the local_irq_disable() invocation from __usb_hcd_giveback_urb() and therefore it is required for the callback handler to disable the interrupts while acquiring the lock. The callback may be invoked either in IRQ or BH context depending on the USB host controller. Use the _irqsave() variant of the locking primitives. Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sebastian Andrzej Siewior authored
The USB completion callback does not disable interrupts while acquiring the lock. We want to remove the local_irq_disable() invocation from __usb_hcd_giveback_urb() and therefore it is required for the callback handler to disable the interrupts while acquiring the lock. The callback may be invoked either in IRQ or BH context depending on the USB host controller. Use the _irqsave() variant of the locking primitives. Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sebastian Andrzej Siewior authored
The USB completion callback does not disable interrupts while acquiring the lock. We want to remove the local_irq_disable() invocation from __usb_hcd_giveback_urb() and therefore it is required for the callback handler to disable the interrupts while acquiring the lock. The callback may be invoked either in IRQ or BH context depending on the USB host controller. Use the _irqsave() variant of the locking primitives. Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-