- 30 Sep, 2015 9 commits
-
-
David Ahern authored
Change CONFIG dependency to CONFIG_NET_L3_MASTER_DEV as well. Signed-off-by:
David Ahern <dsa@cumulusnetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David Ahern authored
Move remaining structs to VRF driver and delete the vrf header file. Signed-off-by:
-
David Ahern authored
Signed-off-by:
-
David Ahern authored
Replace calls to vrf_dev_get_rth with l3mdev_get_rtable. The check on the flow flags is handled in the l3mdev operation. Signed-off-by:
-
David Ahern authored
Replace calls to vrf_dev_table and friends with l3mdev_fib_table and kin. Signed-off-by:
-
David Ahern authored
Replace calls to vrf_master_ifindex_rcu and vrf_master_ifindex with either l3mdev_master_ifindex_rcu or l3mdev_master_ifindex. The pattern: oif = vrf_master_ifindex(dev) ? : dev->ifindex; is replaced with oif = l3mdev_fib_oif(dev); And remove the now unused vrf macros. Signed-off-by: -
David Ahern authored
Signed-off-by:
-
David Ahern authored
L3 master devices allow users of the abstraction to influence FIB lookups for enslaved devices. Current API provides a means for the master device to return a specific FIB table for an enslaved device, to return an rtable/custom dst and influence the OIF used for fib lookups. Signed-off-by:
-
David Ahern authored
Rename IFF_VRF_MASTER to IFF_L3MDEV_MASTER and update the name of the netif_is_vrf and netif_index_is_vrf macros. Signed-off-by:
-
- 29 Sep, 2015 31 commits
-
-
David S. Miller authored
Eric Dumazet says: ==================== tcp: listener refactoring preparations This patch series makes changes to TCP/DCCP stacks so that we can switch listener code to lockless mode. This is done by marking const the listener socket in all appropriate paths. FastOpen code had to be changed to not dynamically allocate a very small structure to make code simpler for following changes. ==================== Signed-off-by: -
Eric Dumazet authored
While auditing TCP stack for upcoming 'lockless' listener changes, I found I had to change fastopen_init_queue() to properly init the object before publishing it. Otherwise an other cpu could try to lock the spinlock before it gets properly initialized. Instead of adding appropriate barriers, just remove dynamic memory allocations : - Structure is 28 bytes on 64bit arches. Using additional 8 bytes for holding a pointer seems overkill. - Two listeners can share same cache line and performance would suffer. If we really want to save few bytes, we would instead dynamically allocate whole struct request_sock_queue in the future. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Eric Dumazet authored
tcp_syn_flood_action() will soon be called with unlocked socket. In order to avoid SYN flood warning being emitted multiple times, use xchg(). Extend max_qlen_log and synflood_warned fields in struct listen_sock to u32 Signed-off-by:
-
Eric Dumazet authored
These functions do not change the listener socket. Goal is to make sure tcp_conn_request() is not messing with listener in a racy way. Signed-off-by:
-
Eric Dumazet authored
Some common IPv4/IPv6 code can be factorized. Also constify cookie_init_sequence() socket argument. Signed-off-by:
-
Eric Dumazet authored
We'll soon no longer hold listener socket lock, these functions do not modify the socket in any way. Signed-off-by:
-
Eric Dumazet authored
This method does not touch the listener socket. Signed-off-by:
-
Eric Dumazet authored
socket no longer needs to be read/write Signed-off-by:
-
Eric Dumazet authored
Signed-off-by:
-
Eric Dumazet authored
socket is not touched, make it const. Signed-off-by:
-
Eric Dumazet authored
The socket points to the (shared) listener. Signed-off-by:
-
Eric Dumazet authored
Before changing dccp_v6_request_recv_sock() sock argument to const, we need to get rid of security_sk_classify_flow(), and it seems doable by reusing inet6_csk_route_req() helper. We need to add a proto parameter to inet6_csk_route_req(), not assume it is TCP. Signed-off-by:
-
Eric Dumazet authored
Factorize code to get tcp header from skb. It makes no sense to duplicate code in callers. Signed-off-by:
-
Eric Dumazet authored
Once we realize tcp_rcv_synsent_state_process() does not use its 'len' argument and we get rid of it, then it becomes clear this argument is no longer used in tcp_rcv_state_process() Signed-off-by:
-
Eric Dumazet authored
None of these functions need to change the socket, make it const. Signed-off-by:
-
David S. Miller authored
Alexander Duyck says: ==================== Minor IPv4 routing cleanups These patches just contain some minor cleanups to address a few minor issues. The first and the third mostly just improve readability. The second patch should improve the performance for multicast destination addresses that do not have a localhost source IP address by avoiding some unnecessary dereferences. ==================== Signed-off-by: -
David Ahern authored
err is initialized to -EINVAL when it is declared. It is not reset until fib_lookup which is well after the 3 users of the martian_source jump. So resetting err to -EINVAL at martian_source label is not needed. Removing that line obviates the need for the martian_source_keep_err label so delete it. Signed-off-by:
Alexander Duyck <aduyck@mirantis.com> Signed-off-by:
-
Alexander Duyck authored
This patch just swaps the ordering of one of the conditional tests in ip_route_input_mc. Specifically it swaps the testing for the source address to see if it is loopback, and the test to see if we allow a loopback source address. The reason for swapping these two tests is because it is much faster to test if an address is loopback than it is to dereference several pointers to get at the net structure to see if the use of loopback is allowed. Signed-off-by:
-
Alexander Duyck authored
This patch updates ip_check_mc_rcu so that protocol is passed as a u8 instead of a u16. The motivation is just to avoid any unneeded type transitions since some systems will require an instruction to zero extend a u8 field to a u16. Also it makes it a bit more readable as to the fact that protocol is a u8 so there are no byte ordering changes needed to pass it. Signed-off-by:
-
Liviu Dudau authored
On some embedded systems the EEPROM does not contain a valid MAC address. In that case it is better to fallback to a generated mac address and let init scripts fix the value later. Reported-by:
Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by:
Stephen Hemminger <stephen@networkplumber.org> [Changed handcoded setup to use eth_hw_addr_random() and to save new address into HW] Signed-off-by:
-
Alexander Duyck authored
For some reason we were carrying the budget value around between the various calls to napi->poll. If for example one of the drivers called had a bug in which it returned a non-zero value for work this could result in the budget value becoming negative. Rather than carry around a value of budget that is 0 or less we can instead just loop through and pass 0 to each napi->poll call. If any driver returns a value for work done that is non-zero then we can report that driver and continue rather than allowing a bad actor to make the budget value negative and pass that negative value to napi->poll. Note, the only actual change here is that instead of letting budget become negative we are keeping it at 0 regardless of the value returned for work since it should not be possible for the polling routine to do any actual work with a budget of 0. So if the polling routine returns a non-0 value we are just reporting it and continuing with a budget of 0 rather than letting that work value be subtracted from the budget of 0. Signed-off-by:
-
Nikolay Aleksandrov authored
This patch changes the bridge vlan implementation to use rhashtables instead of bitmaps. The main motivation behind this change is that we need extensible per-vlan structures (both per-port and global) so more advanced features can be introduced and the vlan support can be extended. I've tried to break this up but the moment net_port_vlans is changed and the whole API goes away, thus this is a larger patch. A few short goals of this patch are: - Extensible per-vlan structs stored in rhashtables and a sorted list - Keep user-visible behaviour (compressed vlans etc) - Keep fastpath ingress/egress logic the same (optimizations to come later) Here's a brief list of some of the new features we'd like to introduce: - per-vlan counters - vlan ingress/egress mapping - per-vlan igmp configuration - vlan priorities - avoid fdb entries replication (e.g. local fdb scaling issues) The structure is kept single for both global and per-port entries so to avoid code duplication where possible and also because we'll soon introduce "port0 / aka bridge as port" which should simplify things further (thanks to Vlad for the suggestion!). Now we have per-vlan global rhashtable (bridge-wide) and per-vlan port rhashtable, if an entry is added to a port it'll get a pointer to its global context so it can be quickly accessed later. There's also a sorted vlan list which is used for stable walks and some user-visible behaviour such as the vlan ranges, also for error paths. VLANs are stored in a "vlan group" which currently contains the rhashtable, sorted vlan list and the number of "real" vlan entries. A good side-effect of this change is that it resembles how hw keeps per-vlan data. One important note after this change is that if a VLAN is being looked up in the bridge's rhashtable for filtering purposes (or to check if it's an existing usable entry, not just a global context) then the new helper br_vlan_should_use() needs to be used if the vlan is found. In case the lookup is done only with a port's vlan group, then this check can be skipped. Things tested so far: - basic vlan ingress/egress - pvids - untagged vlans - undef CONFIG_BRIDGE_VLAN_FILTERING - adding/deleting vlans in different scenarios (with/without global ctx, while transmitting traffic, in ranges etc) - loading/removing the module while having/adding/deleting vlans - extracting bridge vlan information (user ABI), compressed requests - adding/deleting fdbs on vlans - bridge mac change, promisc mode - default pvid change - kmemleak ON during the whole time Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
David S. Miller authored
Gregory CLEMENT says: ==================== net: mvneta: Switch to per-CPU irq and make rxq_def useful As stated in the first version: "this patchset reworks the Marvell neta driver in order to really support its per-CPU interrupts, instead of faking them as SPI, and allow the use of any RX queue instead of the hardcoded RX queue 0 that we have currently." Following the review which has been done, Maxime started adding the CPU hotplug support. I continued his work a few weeks ago and here is the result. Since the 1st version the main change is this CPU hotplug support, in order to validate it I powered up and down the CPUs while performing iperf. I ran the tests during hours: the kernel didn't crash and the network interfaces were still usable. Of course it impacted the performance, but continuously power down and up the CPUs is not something we usually do. I also reorganized the series, the 3 first patches should go through the irq subsystem, whereas the 4 others should go to the network subsystem. However, there is a runtime dependency between the two parts. Patch 5 depend on the patch 3 to be able to use the percpu irq. Thanks, Gregory PS: Thanks to Willy who gave me some pointers on how to deal with the NAPI. ==================== Signed-off-by: -
Maxime Ripard authored
Since the switch to per-CPU interrupts, we lost the ability to set which CPU was going to receive our RX interrupt, which was now only the CPU on which the mvneta_open function was run. We can now assign our queues to their respective CPUs, and make sure only this CPU is going to handle our traffic. This also paves the road to be able to change that at runtime, and later on to support RSS. [gregory.clement@free-electrons.com]: hardened the CPU hotplug support. Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
Maxime Ripard authored
The mvneta driver allows to change the default RX queue trough the rxq_def kernel parameter. However, the current code doesn't allow to have any value but 0. It is actively checked for in the driver's probe because the drivers makes a number of assumption and takes a number of shortcuts in order to just use that RX queue. Remove these limitations in order to be able to specify any available queue. Signed-off-by:
-
Maxime Ripard authored
Now that our interrupt controller is allowing us to use per-CPU interrupts, actually use it in the mvneta driver. This involves obviously reworking the driver to have a CPU-local NAPI structure, and report for incoming packet using that structure. Signed-off-by:
-
Maxime Ripard authored
The CPU_MAP register is duplicated for each CPUs at different addresses, each instance being at a different address. However, the code so far was using CONFIG_NR_CPUS to initialise the CPU_MAP registers for each registers, while the SoCs embed at most 4 CPUs. This is especially an issue with multi_v7_defconfig, where CONFIG_NR_CPUS is currently set to 16, resulting in writes to registers that are not CPU_MAP. Fixes: c5aff182 ("net: mvneta: driver for Marvell Armada 370/XP network unit") Signed-off-by:
-
Maxime Ripard authored
The MPIC driver currently has a list of interrupts to handle as per-cpu. Since the timer, fabric and neta interrupts were the only per-cpu interrupts in the system, we can now remove the switch and just check for the hardware irq number to determine whether a given interrupt is per-cpu or not. Signed-off-by:
-
Maxime Ripard authored
Some drivers might use the per-cpu interrupts and still might be built as a module. Export request_percpu_irq an free_percpu_irq to these user, which also make it consistent with enable/disable_percpu_irq that were exported. Reported-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
-
Maxime Ripard authored
The documentation of request_percpu_irq is confusing and suggest that the interrupt is not enabled at all, while it is actually enabled on the local CPU. Clarify that. Signed-off-by:
-
Jesper Dangaard Brouer authored
Noticed that the compiler (gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC)) generated suboptimal assembler code in eth_get_headlen(). This early return coding style is usually not an issue, on super scalar CPUs, but the compiler choose to put the return statement after this very unlikely branch, thus creating larger jump down to the likely code path. Performance wise, I could measure slightly less L1-icache-load-misses and less branch-misses, and an improvement of 1 nanosec with an IP-forwarding use-case with 257 bytes packets with ixgbe (CPU i7-4790K @ 4.00GHz). Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
-
