- 06 Mar, 2015 40 commits
-
-
David S. Miller authored
Alexander Duyck says: ==================== The rest of the FIB patches (add key_vector to fib_table) This patch series is the rest of what I had originally planned for this kernel release. It adds a structure called key_vector which is embedded within every tnode, leaf, and the trie root itself. By doing this we can navigate from any point within the trie to any other point fairly quickly and avoiding NULL pointer checks in the case of a backtrace. As a result we can pipeline things a bit further since we don't have to worry about dereferencing NULL in a backtrace. This can amount to significant savings on a long backtrace. I decided to drop the up-level code as that conflicts with combining the main and local tries. I have one patch as an RFC that currently combines the tries however it still needs some work as we have to split the local and main tries in the event of custom rules being defined. As such we are probably going to be doing some more hacking on fib_table_flush_external as that will also need to flush the local entries from the main trie and place them back in the local trie. v2: Rebased on the switchdev FIB offload work ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Alexander Duyck authored
This change makes it so that the root of the trie contains a key_vector, by doing this we make room to essentially collapse the entire trie by at least one cache line as we can store the information about the tnode or leaf that is pointed to in the root. Signed-off-by:
Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by:
-
Alexander Duyck authored
This change pulls the parent pointer from the key_vector and places it in the tnode structure. Signed-off-by:
-
Alexander Duyck authored
This pulls the information about the child array out of the key_vector and places it in the tnode since that is where it is needed. Signed-off-by:
-
Alexander Duyck authored
RCU is only needed once for the entire node, not once per key_vector so we can pull that out and move it to the tnode structure. In addition add accessors to be used inside the RCU functions so that we can more easily get from the key vector to either the tnode or the trie pointers. Signed-off-by:
-
Alexander Duyck authored
This change pulls the fields not explicitly needed in the key_vector and placed them in the new tnode structure. By doing this we will eventually be able to reduce the key_vector down to 16 bytes on 64 bit systems, and 12 bytes on 32 bit systems. Signed-off-by:
-
Alexander Duyck authored
We are now checking the length of a key_vector instead of a tnode so it makes sense to probably just rename this to child_length since it would probably even be applicable to a leaf. Signed-off-by:
-
Alexander Duyck authored
I am replacing the tnode_get_child call with get_child since we are techically pulling the child out of a key_vector now and not a tnode. Signed-off-by:
-
Alexander Duyck authored
Rename the tnode to key_vector. The key_vector will be the eventual container for all of the information needed by either a leaf or a tnode. The final result should be much smaller than the 40 bytes currently needed for either one. This also updates the trie struct so that it contains an array of size 1 of tnode pointers. This is to bring the structure more inline with how an actual tnode itself is configured. Signed-off-by:
-
Alexander Duyck authored
Resize related functions now all return a pointer to the pointer that references the object that was resized. Signed-off-by:
-
Alexander Duyck authored
This change just does a couple of minor cleanups on fib_table_flush_external. Specifically it addresses the fact that resize was being called even though nothing was being removed from the table, and it drops an unecessary indent since we could just call continue on the inverse of the fi && flag check. Signed-off-by:
-
Punnaiah Choudary Kalluri authored
ZynqMP soc has single interrupt for all the queue events. So, passing the IRQF_SHARED flag for interrupt registration call. Signed-off-by:
Punnaiah Choudary Kalluri <punnaia@xilinx.com> Signed-off-by:
Michal Simek <michal.simek@xilinx.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Punnaiah Choudary Kalluri authored
Include multi queue support for the ethernet IP version in xilinx ZynqMP SoC. Signed-off-by:
-
David S. Miller authored
Merge tag 'wireless-drivers-next-for-davem-2015-03-06' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Major changes: brcmfmac: * sdio improvements * add a debugfs file so users can provide us all the revinfo we could ask for iwlwifi: * add triggers for firmware dump collection * remove support for -9.ucode * new statitics API * rate control improvements ath9k: * add per-vif TX power capability * BT coexistance fixes ath10k: * qca6174: enable STA transmit beamforming (TxBF) support * disable multi-vif power save by default bcma: * enable support for PCIe Gen 2 host devices Signed-off-by:
-
Willem de Bruijn authored
When building without CONFIG_NET_SWITCHDEV, netdev_switch_fib_ipv4_abort is defined in the header file. It must be static inline to avoid build failure at link time. Fixes: 8e05fd71 ("fib: hook IPv4 fib for hardware offload") Signed-off-by:
Willem de Bruijn <willemb@google.com> Acked-by:
Scott Feldman <sfeldma@gmail.com> Signed-off-by:
-
Robert Shearman authored
If the nla length is less than 2 then the nla data could be accessed beyond the accessible bounds. So ensure that the nla is big enough to at least read the via_family before doing so. Replace magic value of 2. Fixes: 03c05665 ("mpls: Basic support for adding and removing routes") Cc: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
Robert Shearman <rshearma@brocade.com> Acked-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
David S. Miller authored
Petri Gynther says: ==================== net: bcmgenet: preparation for multiple Rx queues Three small patches in preparation for supporting multiple Rx queues: 1. set hw_params->rx_queues = 0 2. adjust the call to alloc_etherdev_mqs() 3. add GENET_Q16_RX_BD_CNT and hw_params->rx_bds_per_q ==================== Signed-off-by: -
Petri Gynther authored
In preparation for supporting multiple Rx queues, add GENET_Q16_RX_BD_CNT and hw_params->rx_bds_per_q. Signed-off-by:
Petri Gynther <pgynther@google.com> Signed-off-by:
-
Petri Gynther authored
In preparation for supporting multiple Rx queues, adjust the call to alloc_etherdev_mqs() to allow max GENET_MAX_MQ_CNT + 1 Rx queues. The actual number of Rx queues in use is correctly adjusted with: netif_set_real_num_rx_queues(priv->dev, priv->hw_params->rx_queues + 1); Signed-off-by:
-
Petri Gynther authored
bcmgenet driver doesn't yet support multiple Rx queues. Set hw_params->rx_queues = 0 accordingly. The default Rx queue (Q16) is still created and operational. 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-03-06 This series contains updates to e1000, e1000e and igb. Yanir provides updates to e1000e based on the patches provided by John Linville. First updates the code comment to better describe the changes and the impact on the driver. Second removed calls to ioremap/unmap for i219 since this is only relevant to older hardware only. Starting with i219, the NVM will not be mapped to its one BAR but to a address region in another bar. Alex Duyck provides two fixes for igb, first fixes a compile warning where a variable may be used uninitialized, so Alex initializes it. Second fixes an issue where all of the pin register values were having to be pushed onto the stack each time the function was called, so to avoid this, Alex made them static const so that they should only need to be allocated once and we can avoid all the instructions to get them onto the stack. Eliezer found an issue in e1000 where we needed to be calling netif_carrier_off earlier in the down() to prevent the stack from queuing more packets to the interface. Sabrina Dubroca resolved a potential race condition by adding a dummy allocator. There was a race condition between e1000_change_mtu() cleanups and netpoll, when changing the MTU across jumbo sizes. ==================== Signed-off-by: -
David S. Miller authored
Fan Du says: ==================== Improvements for TCP PMTU This patchset performs some improvements and enhancement for current TCP PMTU as per RFC4821 with the aim to find optimal mms size quickly, and also be adaptive to route changes like enlarged path MTU. Then TCP PMTU could be used to probe a effective pmtu in absence of ICMP message for tunnels(e.g. vxlan) across different networking stack. Patch1/4: Set probe mss base to 1024 Bytes per RFC4821 Patch2/4: Do not double probe_size for each probing, use a simple binary search to gain maximum performance. mss for next probing. Patch3/4: Create a probe timer to detect enlarged path MTU. Patch4/4: Update ip-sysctl.txt for new sysctl knobs. Changelog: v5: - Zero probe_size before resetting search range. - Update ip-sysctl.txt for new sysctl knobs. v4: - Convert probe_size to mss, not directly from search_low/high - Clamp probe_threshold - Don't adjust search_high in blackhole probe, so drop orignal patch3 v3: - Update commit message for patch2 - Fix pseudo timer delta calculation in patch4 v2: - Introduce sysctl_tcp_probe_threshold to control when probing will stop, as suggested by John Heffner. - Add patch3 to shrink current mss value for search low boundary. - Drop cannonical timer usages, implements pseudo timer based on 32bits jiffies tcp_time_stamp, as suggested by Eric Dumazet. ==================== Signed-off-by: -
Fan Du authored
Namely tcp_probe_interval to control how often to restart a probe. And tcp_probe_threshold to control when stop the probing in respect to the width of search range in bytes Signed-off-by:
Fan Du <fan.du@intel.com> Signed-off-by:
-
Fan Du authored
As per RFC4821 7.3. Selecting Probe Size, a probe timer should be armed once probing has converged. Once this timer expired, probing again to take advantage of any path PMTU change. The recommended probing interval is 10 minutes per RFC1981. Probing interval could be sysctled by sysctl_tcp_probe_interval. Eric Dumazet suggested to implement pseudo timer based on 32bits jiffies tcp_time_stamp instead of using classic timer for such rare event. Signed-off-by:
-
Fan Du authored
Current probe_size is chosen by doubling mss_cache, the probing process will end shortly with a sub-optimal mss size, and the link mtu will not be taken full advantage of, in return, this will make user to tweak tcp_base_mss with care. Use binary search to choose probe_size in a fine granularity manner, an optimal mss will be found to boost performance as its maxmium. In addition, introduce a sysctl_tcp_probe_threshold to control when probing will stop in respect to the width of search range. Test env: Docker instance with vxlan encapuslation(82599EB) iperf -c 10.0.0.24 -t 60 before this patch: 1.26 Gbits/sec After this patch: increase 26% 1.59 Gbits/sec Signed-off-by:
John Heffner <johnwheffner@gmail.com> Signed-off-by:
-
Fan Du authored
Quotes from RFC4821 7.2. Selecting Initial Values It is RECOMMENDED that search_low be initially set to an MTU size that is likely to work over a very wide range of environments. Given today's technologies, a value of 1024 bytes is probably safe enough. The initial value for search_low SHOULD be configurable. Moreover, set a small value will introduce extra time for the search to converge. So set the initial probe base mss size to 1024 Bytes. Signed-off-by:
-
Eric W. Biederman authored
Other users users of the neighbour table use neigh->output as the method to decided when and which link-layer header to place on a packet. DECnet has been using neigh->output to decide which DECnet headers to place on a packet depending which neighbour the packet is destined for. The DECnet usage isn't totally wrong but it can run into problems if the neighbour output function is run for a second time as the teql driver and the bridge netfilter code can do. Therefore to avoid pathologic problems later down the line and make the neighbour code easier to understand by refactoring the decnet output code to only use a neighbour method to add a link layer header to a packet. This is done by moving the neigbhour operations lookup from dn_to_neigh_output to dn_neigh_output_packet. Signed-off-by:
-
Mahesh Bandewar authored
This patches implements the poll_controller support for all bonding driver. If the slaves have poll_controller net_op defined, this implementation calls them. This is mode agnostic implementation and iterates through all slaves (based on mode) and calls respective handler. Signed-off-by:
Mahesh Bandewar <maheshb@google.com> Signed-off-by:
-
Scott Feldman authored
Signed-off-by:
Jiri Pirko <jiri@resnulli.us> Signed-off-by:
-
Scott Feldman authored
Signed-off-by:
-
Sabrina Dubroca authored
There is a race condition between e1000_change_mtu's cleanups and netpoll, when we change the MTU across jumbo size: Changing MTU frees all the rx buffers: e1000_change_mtu -> e1000_down -> e1000_clean_all_rx_rings -> e1000_clean_rx_ring Then, close to the end of e1000_change_mtu: pr_info -> ... -> netpoll_poll_dev -> e1000_clean -> e1000_clean_rx_irq -> e1000_alloc_rx_buffers -> e1000_alloc_frag And when we come back to do the rest of the MTU change: e1000_up -> e1000_configure -> e1000_configure_rx -> e1000_alloc_jumbo_rx_buffers alloc_jumbo finds the buffers already != NULL, since data (shared with page in e1000_rx_buffer->rxbuf) has been re-alloc'd, but it's garbage, or at least not what is expected when in jumbo state. This results in an unusable adapter (packets don't get through), and a NULL pointer dereference on the next call to e1000_clean_rx_ring (other mtu change, link down, shutdown): BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff81194d6e>] put_compound_page+0x7e/0x330 [...] Call Trace: [<ffffffff81195445>] put_page+0x55/0x60 [<ffffffff815d9f44>] e1000_clean_rx_ring+0x134/0x200 [<ffffffff815da055>] e1000_clean_all_rx_rings+0x45/0x60 [<ffffffff815df5e0>] e1000_down+0x1c0/0x1d0 [<ffffffff811e2260>] ? deactivate_slab+0x7f0/0x840 [<ffffffff815e21bc>] e1000_change_mtu+0xdc/0x170 [<ffffffff81647050>] dev_set_mtu+0xa0/0x140 [<ffffffff81664218>] do_setlink+0x218/0xac0 [<ffffffff814459e9>] ? nla_parse+0xb9/0x120 [<ffffffff816652d0>] rtnl_newlink+0x6d0/0x890 [<ffffffff8104f000>] ? kvm_clock_read+0x20/0x40 [<ffffffff810a2068>] ? sched_clock_cpu+0xa8/0x100 [<ffffffff81663802>] rtnetlink_rcv_msg+0x92/0x260 By setting the allocator to a dummy version, netpoll can't mess up our rx buffers. The allocator is set back to a sane value in e1000_configure_rx. Fixes: edbbb3ca ("e1000: implement jumbo receive with partial descriptors") Signed-off-by:Sabrina Dubroca <sd@queasysnail.net> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Eliezer Tamir authored
When bringing down an interface netif_carrier_off() should be one the first things we do, since this will prevent the stack from queuing more packets to this interface. This operation is very fast, and should make the device behave much nicer when trying to bring down an interface under load. Also, this would Do The Right Thing (TM) if this device has some sort of fail-over teaming and redirect traffic to the other IF. Move netif_carrier_off as early as possible. Signed-off-by:
Eliezer Tamir <eliezer.tamir@linux.intel.com> Tested-by:
-
Alexander Duyck authored
While addressing the pin problem I noticed that all of the pin register values where having to be pushed onto the stack each time the function was called. To avoid that I am making them static const so that they should only need to be allocated once and we can avoid all the instructions to get them onto the stack.. size before: text data bss dec hex filename 161477 10512 8 171997 29fdd drivers/net/ethernet/intel/igb/igb.ko size after: text data bss dec hex filename 161205 10512 8 171725 29ecd drivers/net/ethernet/intel/igb/igb.ko Signed-off-by:
-
Alexander Duyck authored
When building the kernel using the gcc 4.8.3 compiler included in Fedora 20 I was repeatedly seeing the warning: drivers/net/ethernet/intel/igb/igb_ptp.c: In function ‘igb_ptp_feature_enable_i210’: drivers/net/ethernet/intel/igb/igb_ptp.c:395:21: warning: ‘pin’ may be used uninitialized in this function [-Wmaybe-uninitialized] tssdp &= ~ts_sdp_en[pin]; ^ drivers/net/ethernet/intel/igb/igb_ptp.c:471:6: note: ‘pin’ was declared here int pin; ^ To resolve it I am assigning the pin a value of -1 when it is instantiated. Signed-off-by: -
Yanir Lubetkin authored
Starting I219, the NVM will not be mapped to its own BAR, but to an address region in another bar. The mapping/unmapping is relevant to older HW only. CC: John W Linville <linville@tuxdriver.com> Reported-by:
John W Linville <linville@tuxdriver.com> Signed-off-by:
Yanir Lubetkin <yanirx.lubetkin@intel.com> Tested-by:
-
Yanir Lubetkin authored
The interface to the device flash was modified in i219 and later HW. This patch better describes the change and the impact on the driver. CC: John W Linville <linville@tuxdriver.com> Reported-by:
-
David S. Miller authored
net/ipv4/fib_trie.c: In function ‘fib_table_flush_external’: net/ipv4/fib_trie.c:1572:6: warning: unused variable ‘found’ [-Wunused-variable] int found = 0; ^ net/ipv4/fib_trie.c:1571:16: warning: unused variable ‘slen’ [-Wunused-variable] unsigned char slen; ^ Signed-off-by: -
David S. Miller authored
Scott Feldman says: ==================== switchdev: add IPv4 routing offload v4: - Add NETIF_F_NETNS_LOCAL to rocker port feature list to keep rocker ports in the default netns. Rocker hardware can't be partitioned to support multiple namespaces, currently. It would be interesting to add netns support to rocker device by basically adding another match field to each table to match on some unique netns ID, with a port knowing it's netns ID. Future work TDB. - Up-level the RTNH_F_EXTERNAL marking of routes installed to offload device from driver to switchdev common code. Now driver can't skip routes. Either it can install the route or it cannot. Yes or No. If no on any route, all offloading is aborted by removing routes from offload device and setting ipv4.fib_offload_disabled so no more routes can be offloaded. This is harsh, but it's our starting point. We can refine the policies in follow-up work. - Add new net.ipv4.fib_offload_disabled bool that is set if anything goes wrong with route offloading. We can refine this later to make the setting per-device or per-device-port-netdev, but let's start here simple and refine in follow-up work. - Rebase against Alex's latest FIB changes. I think I did everything correctly, and didn't run into any issues with testing, but I'd like Alex to look over the changes and maybe follow-up with any cleanups. v3: Changes based on v2 review comments: - Move check for custom rules up earlier in patch set, to keep git bisect safe. - Simplify the route add/modify failure handling to simple try until failure, and then on failure, undo everything. The switchdev driver will return err when route can normally be installed to device, but the install fails for one reason or another (no space left on device, etc). If a failure happens, uninstall all routes from the device, punting forwarding for all routes back to the kernel. - Scan route's full nexthop list, ensuring all nexthop devs belong to the same switchdev device, otherwise don't try to install route to device. v2: Changes based on v1 review comments and discussions at netconf: - Allow route modification, but use same ndo op used for adding route. Driver/device is expected to modify route in-place, if it can, to avoid interruption of service. - Add new RTNH_F_EXTERNAL flag to mark FIB entries offloaded externally. - Don't offload routes if using custom IP rules. If routes are already offloaded, and custom IP rules are turned on, flush routes from offload device. (Offloaded routes are marked with RTNH_F_EXTERNAL). - Use kernel's neigh resolution code to resolve route's nexthops' neigh MAC addrs. (Thanks davem, works great!). - Use fib->fib_priority in rocker driver to give priorities to routes in OF-DPA unicast route table. v1: This patch set adds L3 routing offload support for IPv4 routes. The idea is to mirror routes installed in the kernel's FIB down to a hardware switch device to offload the data forwarding path for L3. Only the data forwarding path is intercepted. Control and management of the kernel's FIB remains with the kernel. ==================== Signed-off-by: -
Scott Feldman authored
The driver implements ndo_switch_fib_ipv4_add/del ops to add/del/mod IPv4 routes to/from switchdev device. Once a route is added to the device, and the route's nexthops are resolved to neighbor MAC address, the device will forward matching pkts rather than the kernel. This offloads the L3 forwarding path from the kernel to the device. Note that control and management planes are still mananged by Linux; only the data plane is offloaded. Standard routing control protocols such as OSPF and BGP run on Linux and manage the kernel's FIB via standard rtm netlink msgs...nothing changes here. A new hash table is added to rocker to track neighbors. The driver listens for neighbor updates events using netevent notifier NETEVENT_NEIGH_UPDATE. Any ARP table updates for ports on this device are recorded in this table. Routes installed to the device with nexthops that reference neighbors in this table are "qualified". In the case of a route with nexthops not resolved in the table, the kernel is asked to resolve the nexthop. The driver uses fib_info->fib_priority for the priority field in rocker's unicast routing table. The device can only forward to pkts matching route dst to resolved nexthops. Currently, the device only supports single-path routes (i.e. routes with one nexthop). Equal Cost Multipath (ECMP) route support will be added in followup patches. This patch is driver support for unicast IPv4 routing only. Followup patches will add driver and infrastructure for IPv6 routing and multicast routing. Signed-off-by:
-
Scott Feldman authored
Call into the switchdev driver any time an IPv4 fib entry is added/modified/deleted from the kernel's FIB. The switchdev driver may or may not install the route to the offload device. In the case where the driver tries to install the route and something goes wrong (device's routing table is full, etc), then all of the offloaded routes will be flushed from the device, route forwarding falls back to the kernel, and no more routes are offloading. We can refine this logic later. For now, use the simplist model of offloading routes up to the point of failure, and then on failure, undo everything and mark IPv4 offloading disabled. Signed-off-by:
-
