- 17 Mar, 2014 5 commits
-
-
Eric W. Biederman authored
Today netpoll depends on setting NETPOLL_RX_DROP before networking drivers receive packets in interrupt context so that the packets can be dropped. Move this setting into netpoll_poll_dev from poll_one_napi so that if ndo_poll_controller happens to receive packets we will drop the packets on the floor instead of letting the packets bounce through the networking stack and potentially cause problems. Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-nextDavid S. Miller authored
Pablo Neira Ayuso says: ==================== Netfilter/IPVS updates for net-next The following patchset contains Netfilter/IPVS updates for net-next, most relevantly they are: * cleanup to remove double semicolon from stephen hemminger. * calm down sparse warning in xt_ipcomp, from Fan Du. * nf_ct_labels support for nf_tables, from Florian Westphal. * new macros to simplify rcu dereferences in the scope of nfnetlink and nf_tables, from Patrick McHardy. * Accept queue and drop (including reason for drop) to verdict parsing in nf_tables, also from Patrick. * Remove unused random seed initialization in nfnetlink_log, from Florian Westphal. * Allow to attach user-specific information to nf_tables rules, useful to attach user comments to rule, from me. * Return errors in ipset according to the manpage documentation, from Jozsef Kadlecsik. * Fix coccinelle warnings related to incorrect bool type usage for ipset, from Fengguang Wu. * Add hash:ip,mark set type to ipset, from Vytas Dauksa. * Fix message for each spotted by ipset for each netns that is created, from Ilia Mirkin. * Add forceadd option to ipset, which evicts a random entry from the set if it becomes full, from Josh Hunt. * Minor IPVS cleanups and fixes from Andi Kleen and Tingwei Liu. * Improve conntrack scalability by removing a central spinlock, original work from Eric Dumazet. Jesper Dangaard Brouer took them over to address remaining issues. Several patches to prepare this change come in first place. * Rework nft_hash to resolve bugs (leaking chain, missing rcu synchronization on element removal, etc. from Patrick McHardy. * Restore context in the rule deletion path, as we now release rule objects synchronously, from Patrick McHardy. This gets back event notification for anonymous sets. * Fix NAT family validation in nft_nat, also from Patrick. * Improve scalability of xt_connlimit by using an array of spinlocks and by introducing a rb-tree of hashtables for faster lookup of accounted objects per network. This patch was preceded by several patches and refactorizations to accomodate this change including the use of kmem_cache, from Florian Westphal. ==================== Signed-off-by: -
Florian Westphal authored
With current match design every invocation of the connlimit_match function means we have to perform (number_of_conntracks % 256) lookups in the conntrack table [ to perform GC/delete stale entries ]. This is also the reason why ____nf_conntrack_find() in perf top has > 20% cpu time per core. This patch changes the storage to rbtree which cuts down the number of ct objects that need testing. When looking up a new tuple, we only test the connections of the host objects we visit while searching for the wanted host/network (or the leaf we need to insert at). The slot count is reduced to 32. Increasing slot count doesn't speed up things much because of rbtree nature. before patch (50kpps rx, 10kpps tx): + 20.95% ksoftirqd/0 [nf_conntrack] [k] ____nf_conntrack_find + 20.50% ksoftirqd/1 [nf_conntrack] [k] ____nf_conntrack_find + 20.27% ksoftirqd/2 [nf_conntrack] [k] ____nf_conntrack_find + 5.76% ksoftirqd/1 [nf_conntrack] [k] hash_conntrack_raw + 5.39% ksoftirqd/2 [nf_conntrack] [k] hash_conntrack_raw + 5.35% ksoftirqd/0 [nf_conntrack] [k] hash_conntrack_raw after (90kpps, 51kpps tx): + 17.24% swapper [nf_conntrack] [k] ____nf_conntrack_find + 6.60% ksoftirqd/2 [nf_conntrack] [k] ____nf_conntrack_find + 2.73% swapper [nf_conntrack] [k] hash_conntrack_raw + 2.36% swapper [xt_connlimit] [k] count_tree Obvious disadvantages to previous version are the increase in code complexity and the increased memory cost. Partially based on Eric Dumazets fq scheduler. Reviewed-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org>
-
Florian Westphal authored
currently returns 1 if they're the same. Make it work like mem/strcmp so it can be used as rbtree search function. Reviewed-by:
-
Florian Westphal authored
connlimit currently suffers from spinlock contention, example for 4-core system with rps enabled: + 20.84% ksoftirqd/2 [kernel.kallsyms] [k] _raw_spin_lock_bh + 20.76% ksoftirqd/1 [kernel.kallsyms] [k] _raw_spin_lock_bh + 20.42% ksoftirqd/0 [kernel.kallsyms] [k] _raw_spin_lock_bh + 6.07% ksoftirqd/2 [nf_conntrack] [k] ____nf_conntrack_find + 6.07% ksoftirqd/1 [nf_conntrack] [k] ____nf_conntrack_find + 5.97% ksoftirqd/0 [nf_conntrack] [k] ____nf_conntrack_find + 2.47% ksoftirqd/2 [nf_conntrack] [k] hash_conntrack_raw + 2.45% ksoftirqd/0 [nf_conntrack] [k] hash_conntrack_raw + 2.44% ksoftirqd/1 [nf_conntrack] [k] hash_conntrack_raw May allow parallel lookup/insert/delete if the entry is hashed to another slot. With patch: + 20.95% ksoftirqd/0 [nf_conntrack] [k] ____nf_conntrack_find + 20.50% ksoftirqd/1 [nf_conntrack] [k] ____nf_conntrack_find + 20.27% ksoftirqd/2 [nf_conntrack] [k] ____nf_conntrack_find + 5.76% ksoftirqd/1 [nf_conntrack] [k] hash_conntrack_raw + 5.39% ksoftirqd/2 [nf_conntrack] [k] hash_conntrack_raw + 5.35% ksoftirqd/0 [nf_conntrack] [k] hash_conntrack_raw + 2.00% ksoftirqd/1 [kernel.kallsyms] [k] __rcu_read_unlock Improved rx processing rate from ~35kpps to ~50 kpps. Reviewed-by:
-
- 15 Mar, 2014 35 commits
-
-
David S. Miller authored
Eric W. Biederman says: ==================== Don't receive packets when the napi budget == 0 After reading through all 120 drivers supporting netpoll I have found 16 more that process at least received packet when the napi budget == 0. Processing more packets than your budget has always been a bug but we haven't cared before so it looks like these drivers slipped through, and need fixes. As netpoll will shortly be using a budget of 0 to get the tx queue processing with the rx queue processing we now care. ==================== Signed-off-by: -
Eric W. Biederman authored
Processing any incoming packets with a with a napi budget of 0 is incorrect driver behavior. This matters as netpoll will shortly call drivers with a budget of 0 to avoid receive packet processing happening in hard irq context. Signed-off-by:
-
Eric W. Biederman authored
Processing any incoming packets with a with a napi budget of 0 is incorrect driver behavior. This matters as netpoll will shortly call drivers with a budget of 0 to avoid receive packet processing happening in hard irq context. Signed-off-by:
-
Eric W. Biederman authored
Processing any incoming packets with a with a napi budget of 0 is incorrect driver behavior. This matters as netpoll will shortly call drivers with a budget of 0 to avoid receive packet processing happening in hard irq context. Signed-off-by:
-
Eric W. Biederman authored
Processing any incoming packets with a with a napi budget of 0 is incorrect driver behavior. This matters as netpoll will shortly call drivers with a budget of 0 to avoid receive packet processing happening in hard irq context. Signed-off-by:
-
Eric W. Biederman authored
Processing any incoming packets with a with a napi budget of 0 is incorrect driver behavior. This matters as netpoll will shortly call drivers with a budget of 0 to avoid receive packet processing happening in hard irq context. Signed-off-by:
-
Eric W. Biederman authored
Processing any incoming packets with a with a napi budget of 0 is incorrect driver behavior. This matters as netpoll will shortly call drivers with a budget of 0 to avoid receive packet processing happening in hard irq context. Signed-off-by:
-
Eric W. Biederman authored
Processing any incoming packets with a with a napi budget of 0 is incorrect driver behavior. This matters as netpoll will shortly call drivers with a budget of 0 to avoid receive packet processing happening in hard irq context. Signed-off-by:
-
Eric W. Biederman authored
Processing any incoming packets with a with a napi budget of 0 is incorrect driver behavior. This matters as netpoll will shortly call drivers with a budget of 0 to avoid receive packet processing happening in hard irq context. Signed-off-by:
-
Eric W. Biederman authored
Processing any incoming packets with a with a napi budget of 0 is incorrect driver behavior. This matters as netpoll will shortly call drivers with a budget of 0 to avoid receive packet processing happening in hard irq context. Signed-off-by:
-
Eric W. Biederman authored
Processing any incoming packets with a with a napi budget of 0 is incorrect driver behavior. This matters as netpoll will shortly call drivers with a budget of 0 to avoid receive packet processing happening in hard irq context. Signed-off-by:
-
Eric W. Biederman authored
Processing any incoming packets with a with a napi budget of 0 is incorrect driver behavior. This matters as netpoll will shortly call drivers with a budget of 0 to avoid receive packet processing happening in hard irq context. Signed-off-by:
-
Eric W. Biederman authored
Processing any incoming packets with a with a napi budget of 0 is incorrect driver behavior. This matters as netpoll will shortly call drivers with a budget of 0 to avoid receive packet processing happening in hard irq context. Signed-off-by:
-
Eric W. Biederman authored
Processing any incoming packets with a with a napi budget of 0 is incorrect driver behavior. This matters as netpoll will shortly call drivers with a budget of 0 to avoid receive packet processing happening in hard irq context. Signed-off-by:
-
Eric W. Biederman authored
Processing any incoming packets with a with a napi budget of 0 is incorrect driver behavior. This matters as netpoll will shortly call drivers with a budget of 0 to avoid receive packet processing happening in hard irq context. Signed-off-by:
-
Eric W. Biederman authored
Processing any incoming packets with a with a napi budget of 0 is incorrect driver behavior. This matters as netpoll will shortly call drivers with a budget of 0 to avoid receive packet processing happening in hard irq context. Signed-off-by:
-
Eric W. Biederman authored
Processing any incoming packets with a with a napi budget of 0 is incorrect driver behavior. This matters as netpoll will shortly call drivers with a budget of 0 to avoid receive packet processing happening in hard irq context. Signed-off-by:
-
David S. Miller authored
Hariprasad Shenai says: ==================== Doorbell drop Avoidance Bug fix for iw_cxgb4 This patch series provides fixes for Chelsio T4/T5 adapters related to DB Drop avoidance and other small fix related to keepalive on iw-cxgb4. The patches series is created against David Miller's 'net-next' tree. And includes patches on cxgb4 and iw_cxgb4 driver. We would like to request this patch series to get merged via David Miller's 'net-next' tree. We have included all the maintainers of respective drivers. Kindly review the change and let us know in case of any review comments. ==================== Signed-off-by: -
Steve Wise authored
The current logic suffers from a slow response time to disable user DB usage, and also fails to avoid DB FIFO drops under heavy load. This commit fixes these deficiencies and makes the avoidance logic more optimal. This is done by more efficiently notifying the ULDs of potential DB problems, and implements a smoother flow control algorithm in iw_cxgb4, which is the ULD that puts the most load on the DB fifo. Design: cxgb4: Direct ULD callback from the DB FULL/DROP interrupt handler. This allows the ULD to stop doing user DB writes as quickly as possible. While user DB usage is disabled, the LLD will accumulate DB write events for its queues. Then once DB usage is reenabled, a single DB write is done for each queue with its accumulated write count. This reduces the load put on the DB fifo when reenabling. iw_cxgb4: Instead of marking each qp to indicate DB writes are disabled, we create a device-global status page that each user process maps. This allows iw_cxgb4 to only set this single bit to disable all DB writes for all user QPs vs traversing the idr of all the active QPs. If the libcxgb4 doesn't support this, then we fall back to the old approach of marking each QP. Thus we allow the new driver to work with an older libcxgb4. When the LLD upcalls iw_cxgb4 indicating DB FULL, we disable all DB writes via the status page and transition the DB state to STOPPED. As user processes see that DB writes are disabled, they call into iw_cxgb4 to submit their DB write events. Since the DB state is in STOPPED, the QP trying to write gets enqueued on a new DB "flow control" list. As subsequent DB writes are submitted for this flow controlled QP, the amount of writes are accumulated for each QP on the flow control list. So all the user QPs that are actively ringing the DB get put on this list and the number of writes they request are accumulated. When the LLD upcalls iw_cxgb4 indicating DB EMPTY, which is in a workq context, we change the DB state to FLOW_CONTROL, and begin resuming all the QPs that are on the flow control list. This logic runs on until the flow control list is empty or we exit FLOW_CONTROL mode (due to a DB DROP upcall, for example). QPs are removed from this list, and their accumulated DB write counts written to the DB FIFO. Sets of QPs, called chunks in the code, are removed at one time. The chunk size is 64. So 64 QPs are resumed at a time, and before the next chunk is resumed, the logic waits (blocks) for the DB FIFO to drain. This prevents resuming to quickly and overflowing the FIFO. Once the flow control list is empty, the db state transitions back to NORMAL and user QPs are again allowed to write directly to the user DB register. The algorithm is designed such that if the DB write load is high enough, then all the DB writes get submitted by the kernel using this flow controlled approach to avoid DB drops. As the load lightens though, we resume to normal DB writes directly by user applications. Signed-off-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
-
Steve Wise authored
Based on original work by Anand Priyadarshee <anandp@chelsio.com>. Signed-off-by:
-
Eric W. Biederman authored
Replace the bh safe variant with the hard irq safe variant. We need a hard irq safe variant to deal with netpoll transmitting packets from hard irq context, and we need it in most if not all of the places using the bh safe variant. Except on 32bit uni-processor the code is exactly the same so don't bother with a bh variant, just have a hard irq safe variant that everyone can use. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller authored
Conflicts: drivers/net/usb/r8152.c drivers/net/xen-netback/netback.c Both the r8152 and netback conflicts were simple overlapping changes. Signed-off-by: -
David S. Miller authored
Veaceslav Falico says: ==================== bonding: use correct ether type for alb There have been reports that, while using the ETH_P_LOOP ether type (0x0060), the ether type is treated as its packet length. To avoid that and to not break already existing apps - add new ether type ETH_P_LOOPBACK that contains the correct id - 0x9000. ==================== Signed-off-by:Veaceslav Falico <vfalico@redhat.com>
-
Veaceslav Falico authored
Currently it's using the wrong ETH_P_LOOP type, which is sometimes treated as packet length instead of ether type (because it's 0x0060). Use the new ETH_P_LOOPBACK type. CC: Jay Vosburgh <fubar@us.ibm.com> CC: Andy Gospodarek <andy@greyhouse.net> Signed-off-by:
-
Veaceslav Falico authored
Per IEEE 802.3*, the correct packet type for loopback 0x9000. There's already one ETH_P_LOOP 0x0060, which has been there for ages, however it's plainly wrong as anything that small is considered a length field. We can't remove it because legacy, so add a new type which corresponds to the correct id. http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml CC: "David S. Miller" <davem@davemloft.net> CC: Stefan Richter <stefanr@s5r6.in-berlin.de> CC: Simon Wunderlich <sw@simonwunderlich.de> CC: Neil Jerram <Neil.Jerram@metaswitch.com> CC: Simon Horman <horms@verge.net.au> CC: Arvid Brodin <Arvid.Brodin@xdin.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-nextDavid S. Miller authored
Jeff Kirsher says: ==================== Intel Wired LAN Driver Updates This series contains updates to igb, i40e and i40evf. I provide a code comment fix which David Miller noticed in the last series of patches I submitted. Shannon provides a patch to cleanup the NAPI structs when deleting the netdev. Anjali provides several patches for i40e, first fixes a bug in the update filter logic which was causing a kernel panic. Then provides a fix to rename an error bit to correctly indicate the error. Adds a definition for a new state variable to keep track of features automatically disabled due to hardware resource limitations versus user enforced feature disabled. Anjali provides a patch to add code to handle when there is a filter programming error due to a full table, which also resolves a previous compile warning about an unused "*pf" variable introduced in the last i40e series patch submission. Jesse provides three i40e patches to cleanup strings to make more consistent and to align with other Intel drivers. Akeem cleans up a misleading function header comment for i40e. Mitch provides a fix for i40e/i40evf to use the correctly reported number of MSI-X vectors in the PF an VF. Then provides a patch to use dma_set_mask_and_coherent() which was introduced in v3.13 and simplifies the DMA mapping code a bit. v2: - dropped the 2 ixgbe patches from Emil based on feedback from David Miller, where the 2 fixes should be handled in the net core to fix all drivers ==================== Signed-off-by: -
David S. Miller authored
Phoebe Buckheister says: ==================== ieee802154: fix endianness and header handling This patch set enforces network byte order on all internal operations and fields of the 802.15.4 stack and adds a general representation of 802.15.4 headers with operations to create and parse those headers. This reduces code duplication in the current stack and also allows for upper layers to read headers of packets they have just received; it is also necessary for 802.15.4 link layer security, which requires header mangling. Changes since v1: * fixed lowpan packet rx after reassembly. Control blocks were used to retrieve source/dest addresses, but the CB is clobbered by reassembly. Instead, parse the header anew in lowpan. ==================== Signed-off-by: -
Phoebe Buckheister authored
Have mac802154 header_ops.create fail with -EMSGSIZE if the length passed will be too large to fit a frame. Since 6lowpan will ensure that no packet payload will be too large, pass a length of 0 there. 802.15.4 dgram sockets will also return -EMSGSIZE on payloads larger than the device MTU instead of -EINVAL. Signed-off-by:
Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de> Signed-off-by:
-
Phoebe Buckheister authored
Fragmentation and reassembly information for 6lowpan is independent from the 802.15.4 stack and used only by the 6lowpan reassembly process. Move the ieee802154_frag_info struct to a private are, it needn't be in the 802.15.4 skb control block. Signed-off-by:
-
Phoebe Buckheister authored
Change all internal uses of ieee802154_addr_sa to ieee802154_addr, except for those instances that communicate directly with userspace. Signed-off-by:
-
Phoebe Buckheister authored
Use the operations on 802.15.4 header structs introduced in a previous patch to create and parse all headers in the mac802154 stack. This patch reduces code duplication between different parts of the mac802154 stack that needed information from headers, and also fixes a few bugs that seem to have gone unnoticed until now: * 802.15.4 dgram sockets would return a slightly incorrect value for the SIOCINQ ioctl * mac802154 would not drop frames with the "security enabled" bit set, even though it does not support security, in violation of the standard Signed-off-by:
-
Phoebe Buckheister authored
This patch provides a set of structures to represent 802.15.4 MAC headers, and a set of operations to push/pull/peek these structs from skbs. We cannot simply pointer-cast the skb MAC header pointer to these structs, because 802.15.4 headers are wildly variable - depending on the first three bytes, virtually all other fields of the header may be present or not, and be present with different lengths. The new header creation/parsing routines also support 802.15.4 security headers, which are currently not supported by the mac802154 implementation of the protocol. Signed-off-by:
-
Phoebe Buckheister authored
Enable sparse warnings about endianness, replace the remaining fields regarding network operations without explicit endianness annotations with such that are annotated, and propagate this through the entire stack. Uses of ieee802154_addr_sa are not changed yet, this patch is only concerned with all other fields (such as address filters, operation parameters and the likes). Signed-off-by:
-
Phoebe Buckheister authored
Add a replacement ieee802154_addr struct with proper endianness on fields. Short address fields are stored as __le16 as on the network, extended (EUI64) addresses are __le64 as opposed to the u8[8] format used previously. This disconnect with the netdev address, which is stored as big-endian u8[8], is intentional. Signed-off-by:
-
Phoebe Buckheister authored
The struct as currently defined uses host byte order for some fields, and most big endian/EUI display byte order for other fields. Inside the stack, endianness should ideally match network byte order where possible to minimize the number of byteswaps done in critical paths, but this patch does not address this; it is only preparatory. Signed-off-by:
-
