- 28 May, 2015 13 commits
-
-
Jesse Brandeburg authored
The driver doesn't use the time_stamp member to determine if there is a tx_hang any more. There really isn't any point to the variable at all so just remove it. It was left over from a previous tx_hang design. Change-ID: I4c814827e1bcb46e45118fe37acdcfa814fb62a0 Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by:
Jim Young <james.m.young@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Jesse Brandeburg authored
Inlining these functions gives us about 15% more 64 byte packets per second when using pktgen. 13.3 million to 15 million with a single queue. Also fix the function names in i40evf to i40evf not i40e while we are touching the function header. Change-ID: I3294ae9b085cf438672b6db5f9af122490ead9d0 Signed-off-by:
Catherine Sullivan <catherine.sullivan@intel.com> Tested-by:
-
Jesse Brandeburg authored
Eric added support for skb->xmit_more in i40e, this ports that into i40evf as well. Support skb->xmit_more in i40evf is straightforward; we need to move around i40e_maybe_stop_tx() call to correctly test netif_xmit_stopped() before taking the decision to not kick the NIC. Change-ID: Idddda6a2e4a7ab335631c91ced51f55b25eb8468 Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Signed-off-by:
-
Anjali Singhai Jain authored
These are not useful unless SV is happening as there is a FD flush counter that tracks this. Change-ID: If2655b5a29687247d03a51d35f69854bbeb711ce Signed-off-by:
Anjali Singhai Jain <anjali.singhai@intel.com> Tested-by:
-
Vasu Dev authored
Because i40e_fcoe_ctxt_eof should never be called without i40e_fcoe_eof_is_supported being called first, the EOF in fcoe_ctxt_eof should always be valid and therefore we do not need to print an error if it is not valid. However, a WARN ON to easily catch any calls to i40e_fcoe_ctxt_eof that aren't preceded with a call to i40e_fcoe_eof_is_supported is helpful. Change-ID: I3b536b1981ec0bce80576a74440b7dea3908bdb9 Signed-off-by:
Vasu Dev <vasu.dev@intel.com> Tested-by:
-
Greg Rose authored
There's no need for a counter so remove the TODO comment. Change-ID: I3321dda04934c4f5fda9b279ab666192bda44214 Signed-off-by:
Greg Rose <gregory.v.rose@intel.com> Tested-by:
-
Anjali Singhai Jain authored
We can use the stat index macro directly, a variable is not required. Change-ID: I19f08ac16353dc0cd87a1a8248d714e15a54aa8a Signed-off-by:
-
Anjali Singhai Jain authored
Add a 3rd dynamic filter counter to track Tunneled ATR hits separately. Ethtool port stat "fdir_atr_tunnel_match" Change-ID: Idd978b6db2a462b5722397cd2ffd04ef055f8655 Signed-off-by:
-
Anjali Singhai Jain authored
Without this, RSS would have done inner header load balancing. Now we can get the benefits of ATR for tunneled packets to better align TX and RX queues with the right core/interrupt. Change-ID: I07d0e0a192faf28fdd33b2f04c32b2a82ff97ddd Signed-off-by:
-
Greg Rose authored
Require the user to disable virtual functions before running the device offline diagnostics. The offline diagnostics are intended to ensure basic operation of the device - it is beyond the scope of the diagnostic test to handle the additional complexity of bringing all the virtual functions offline and then back online for each test run. Change-ID: Ic0b854851a09fc85df0c9e82c220e45885457c30 Signed-off-by:
-
Neerav Parikh authored
When PFC is enabled for any UP in single TC configuration the driver didn't collect the PFC XOFF RX stats. Though a single TC with PFC enabled is not a common scenario do not prevent the driver from collecting stats if firmware indicates that PFC is enabled. Change-ID: Ie20bd58b07608b528f3c6d95894c9ae56b00077a Signed-off-by:
Neerav Parikh <neerav.parikh@intel.com> Tested-by:
-
John Fastabend authored
Flow director is exported to user space using the ethtool ntuple support. However, currently it only supports steering traffic to a subset of the queues in use by the hardware. This change allows flow director to specify queues that have been assigned to virtual functions by partitioning the ring_cookie into a 8bit VF specifier followed by 32bit queue index. At the moment we don't have any ethernet drivers with more than 2^32 queues on a single function as best I can tell and nor do I expect this to happen anytime soon. This way the ring_cookie's normal use for specifying a queue on a specific PCI function continues to work as expected. CC: Alex Duyck <alexander.h.duyck@redhat.com> Signed-off-by:
John Fastabend <john.r.fastabend@intel.com> Tested-by:
Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by:
-
John Fastabend authored
The ring_cookie is 64 bits wide which is much larger than can be used for actual queue index values. So provide some helper routines to pack a VF index into the cookie. This is useful to steer packets to a VF ring without having to know the queue layout of the device. CC: Alex Duyck <alexander.h.duyck@redhat.com> Signed-off-by:
-
- 27 May, 2015 24 commits
-
-
Eric Dumazet authored
After commit 07f4c900 ("tcp/dccp: try to not exhaust ip_local_port_range in connect()") it is advised to have an even number of ports described in /proc/sys/net/ipv4/ip_local_port_range This means start/end values should have a different parity. Let's warn sysadmins of this, so that they can update their settings if they want to. Suggested-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Eric Dumazet authored
__inet_hash_connect() does not use its third argument (port_offset) if socket was already bound to a source port. No need to perform useless but expensive md5 computations. Reported-by:
Crestez Dan Leonard <cdleonard@gmail.com> Signed-off-by:
-
David S. Miller authored
Hariprasad Shenai says: ==================== cxgb4/cxgb4vf: Adds FL starvation support and cleanup This patch series adds the following. Adds debugfs entry to inject freelist starvation and some function and argument cleanup This patch series has been created against net-next tree and includes patches on cxgb4 and cxgb4vf driver. We have included all the maintainers of respective drivers. Kindly review the change and let us know in case of any review comments. Thanks V2: Skipping patch "cxgb4: Add support for loopback between VI of same port". This needs some major code change, since module param is not recommended. ==================== Signed-off-by: -
Hariprasad Shenai authored
This patch changes variable name 'fn' to 'pf' of structure adapter. A 'fn' usually stands for PCI function which could be a PF or a VF. However, the use of this particular variable is explicitly limited to PF only. So, be specific about it in the variable name. Also corrects arguments passed for fn t4_ofld_eq_free, t4_ctrl_eq_free, t4_eth_eq_free, t4_iq_free, t4_alloc_vi, t4_fw_hello, t4_wr_mbox and t4_cfg_pfvf function. Also renames cxgb4_t4_bar2_sge_qregs to t4_bar2_sge_qregs and renames the latter function name in cxgb4vf driver to t4vf_bar2_sge_qregs to avoid conflicts. Also fixes alignment for these function. Signed-off-by:
Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by:
-
Hariprasad Shenai authored
Add debugfs entry to inject Freelist starvation, used only for debugging purpose. Signed-off-by:
-
Eric Dumazet authored
vmalloc.h used to be included from include/net/inet_hashtables.h but it is no longer the case. Fixes: 095dc8e0 ("tcp: fix/cleanup inet_ehash_locks_alloc()") Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
Eric Dumazet <edumzet@google.com> Signed-off-by:
-
David S. Miller authored
Aleksey Makarov says: ==================== Adding support for Cavium ThunderX network controller This patchset adds support for the Cavium ThunderX network controller. changes in v6: * unused preprocessor symbols were removed * reduce no of atomic operations in SQ maintenance * support for TCP segmentation at driver level * reset RBDR if fifo state is FAIL * fixed an issue with link state mailbox message changes in v5: * __packed were removed. now we rely on C language ABI * nic_dbg() -> netdev_dbg() * fixes for a typo, constant spelling and using BIT_ULL * use print_hex_dump() * unnecessary conditions in a long if() chain were removed changes in v4: * the patch "pci: Add Cavium PCI vendor id" was attributed correctly * a note that Cavium id is used in many drivers was added * the license comments now match MODULE_LICENSE * a comment explaining usage of writeq_relaxed()/readq_relaxed() was added changes in v3: * code cleanup * issues discovered by reviewers were addressed changes in v2: * non-generic module parameters removed * ethtool support added (nicvf_set_rxnfc()) v5: https://lkml.kernel.org/g/<1432344498-17131-1-git-send-email-aleksey.makarov@caviumnetworks.com> v4: https://lkml.kernel.org/g/<1432000757-28700-1-git-send-email-aleksey.makarov@auriga.com> v3: https://lkml.kernel.org/g/<1431747401-20847-1-git-send-email-aleksey.makarov@auriga.com> v2: https://lkml.kernel.org/g/<1415596445-10061-1-git-send-email-rric@kernel.org> v1: https://lkml.kernel.org/g/<20141030165434.GW20170@rric.localhost> ==================== Signed-off-by:
-
Sunil Goutham authored
This patch adds support for the Cavium ThunderX network controller. The driver is on the pci bus and thus requires the Thunder PCIe host controller driver to be enabled. Signed-off-by:
Maciej Czekaj <mjc@semihalf.com> Signed-off-by:
David Daney <david.daney@cavium.com> Signed-off-by:
Sunil Goutham <sgoutham@cavium.com> Signed-off-by:
Ganapatrao Kulkarni <ganapatrao.kulkarni@caviumnetworks.com> Signed-off-by:
Aleksey Makarov <aleksey.makarov@caviumnetworks.com> Signed-off-by:
Tomasz Nowicki <tomasz.nowicki@linaro.org> Signed-off-by:
Robert Richter <rrichter@cavium.com> Signed-off-by:
Kamil Rytarowski <kamil@semihalf.com> Signed-off-by:
Thanneeru Srinivasulu <tsrinivasulu@caviumnetworks.com> Signed-off-by:
Sruthi Vangala <svangala@cavium.com> Signed-off-by:
-
Sunil Goutham authored
This vendor id will be used by network (vNIC), USB (xHCI), SATA (AHCI), GPIO, I2C, MMC and maybe other drivers for ThunderX SoC. Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Daniel Borkmann authored
While 3b529602 ("test_bpf: add more eBPF jump torture cases") added the int3 bug test case only for eBPF, which needs exactly 11 passes to converge, here's a version for classic BPF with 11 passes, and one that would need 70 passes on x86_64 to actually converge for being successfully JITed. Effectively, all jumps are being optimized out resulting in a JIT image of just 89 bytes (from originally max BPF insns), only returning K. Might be useful as a receipe for folks wanting to craft a test case when backporting the fix in commit 3f7352bf ("x86: bpf_jit: fix compilation of large bpf programs") while not having eBPF. The 2nd one is delegated to the interpreter as the last pass still results in shrinking, in other words, this one won't be JITed on x86_64. Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Alexei Starovoitov <ast@plumgrid.com> Signed-off-by:
-
David S. Miller authored
Edward Cree says: ==================== sfc: add MCDI tracing This patchset adds support for logging MCDI (Management-Controller-to- Driver Interface) interactions between the sfc driver and a bound device, to aid in debugging. Solarflare has a tool to decode the resulting traces and will look to open-source this if there is any external interest, but the protocol is already detailed in drivers/net/ethernet/sfc/mcdi_pcol.h. The logging buffer we allocate per MCDI context is a work area for constructing each individual message before logging it with netif_info. The reason the buffer is long-lived is simply to avoid the overhead of allocating and freeing it every MCDI call, since MCDIs are already known to be serialised for other reasons. -- v4: remove patch #4, which has already been applied via sshah v3: add some explanations to cover letter and patch #4 v2: avoid long lines in cover letter; fix multiline comment style ==================== Signed-off-by: -
Edward Cree authored
As many issues are encountered at probe time, where MCDI logging can't be enabled through the sysfs node, this change adds a module parameter 'mcdi_logging_default', which defaults to false. When set to true, newly- probed functions will have MCDI logging enabled. The setting can subsequently be changed as normal through the sysfs node. Signed-off-by:
Edward Cree <ecree@solarflare.com> Signed-off-by:
-
Edward Cree authored
MCDI tracing is enabled per-function with a sysfs file /sys/class/net/<NET_DEV>/device/mcdi_logging Signed-off-by: -
Edward Cree authored
MCDI tracing is conditional on CONFIG_SFC_MCDI_LOGGING, which is enabled by default. Each MCDI command will produce a console line like sfc dom:bus:dev:fn ifname: MCDI RPC REQ: xxxxxxxx [yyyyyyyy...] where xxxxxxxx etc. are the raw MCDI payload in 32-bit hex chunks. The response will then produce a similar line with "RESP" instead of "REQ", and containing the MCDI response payload (if any). Signed-off-by: -
Sorin Dumitru authored
We're seeing some softlockups from this function when there are a lot fdb entries on a vxlan device. Taking the lock for each bucket instead of the whole table is enough to fix that. Signed-off-by:
Sorin Dumitru <sdumitru@ixiacom.com> Signed-off-by:
-
Eric Dumazet authored
A long standing problem on busy servers is the tiny available TCP port range (/proc/sys/net/ipv4/ip_local_port_range) and the default sequential allocation of source ports in connect() system call. If a host is having a lot of active TCP sessions, chances are very high that all ports are in use by at least one flow, and subsequent bind(0) attempts fail, or have to scan a big portion of space to find a slot. In this patch, I changed the starting point in __inet_hash_connect() so that we try to favor even [1] ports, leaving odd ports for bind() users. We still perform a sequential search, so there is no guarantee, but if connect() targets are very different, end result is we leave more ports available to bind(), and we spread them all over the range, lowering time for both connect() and bind() to find a slot. This strategy only works well if /proc/sys/net/ipv4/ip_local_port_range is even, ie if start/end values have different parity. Therefore, default /proc/sys/net/ipv4/ip_local_port_range was changed to 32768 - 60999 (instead of 32768 - 61000) There is no change on security aspects here, only some poor hashing schemes could be eventually impacted by this change. [1] : The odd/even property depends on ip_local_port_range values parity Signed-off-by:
-
David S. Miller authored
Florian Westphal says: ==================== net: force refragmentation for DF reassembed skbs output path tests: if (skb->len > mtu) ip_fragment() This breaks connectivity in one corner case: If the skb was reassembled, but has the DF bit set and .. .. its reassembled size is <= outdev mtu .. .. we will forward a DF packet larger than what the sender transmitted on wire. If a router later in the path can't forward this packet, it will send an icmp error in response to an mtu that the original sender never exceeded. This changes ipv4 defrag/output path to a) force refragmentation for DF reassembled skbs and b) set DF bit on all fragments when refragmenting if it was set on original frags. tested via: from scapy.all import * dip="10.23.42.2" payload="A"*1400 packet=IP(dst=dip,id=12345,flags='DF')/UDP(sport=42,dport=42)/payload frags=fragment(packet,fragsize=1200) for fragment in frags: send(fragment) Without this patch, we generate fragments without df bit set based on the outgoing device mtu when fragmenting after forwarding, ie. IP (ttl 64, id 12345, offset 0, flags [+, DF], proto UDP (17), length 1204) 192.168.7.1.42 > 10.23.42.2.42: UDP, length 1400 IP (ttl 64, id 12345, offset 1184, flags [DF], proto UDP (17), length 244) 192.168.7.1 > 10.23.42.2: ip-proto-17 on ingress will either turn into IP (ttl 63, id 12345, offset 0, flags [+], proto UDP (17), length 1396) 192.168.7.1.42 > 10.23.42.2.42: UDP, length 1400 IP (ttl 63, id 12345, offset 1376, flags [none], proto UDP (17), length 52) (mtu 1400: We strip df and send larger fragment), or IP (ttl 63, id 12345, offset 0, flags [DF], proto UDP (17), length 1428) 192.168.7.1.42 > 10.23.42.2.42: [udp sum ok] UDP, length 1400 if mtu is 1500. And in this case things break; router with a smaller mtu will send icmp error, but original sender only sent packets <= 1204 byte. With patch, we keep intent of such fragments and will emit DF-fragments that won't exceed 1204 byte in size. Joint work with Hannes Frederic Sowa. Changes since v2: - split unrelated patches from series - rework changelog of patch #2 to better illustrate breakage ==================== Signed-off-by: -
Florian Westphal authored
We currently always send fragments without DF bit set. Thus, given following setup: mtu1500 - mtu1500:1400 - mtu1400:1280 - mtu1280 A R1 R2 B Where R1 and R2 run linux with netfilter defragmentation/conntrack enabled, then if Host A sent a fragmented packet _with_ DF set to B, R1 will respond with icmp too big error if one of these fragments exceeded 1400 bytes. However, if R1 receives fragment sizes 1200 and 100, it would forward the reassembled packet without refragmenting, i.e. R2 will send an icmp error in response to a packet that was never sent, citing mtu that the original sender never exceeded. The other minor issue is that a refragmentation on R1 will conceal the MTU of R2-B since refragmentation does not set DF bit on the fragments. This modifies ip_fragment so that we track largest fragment size seen both for DF and non-DF packets, and set frag_max_size to the largest value. If the DF fragment size is larger or equal to the non-df one, we will consider the packet a path mtu probe: We set DF bit on the reassembled skb and also tag it with a new IPCB flag to force refragmentation even if skb fits outdev mtu. We will also set DF bit on each fragment in this case. Joint work with Hannes Frederic Sowa. Reported-by:
Jesse Gross <jesse@nicira.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Acked-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Florian Westphal authored
ip_skb_dst_mtu is small inline helper, but its called in several places. before: 17061 44 0 17105 42d1 net/ipv4/ip_output.o after: 16805 44 0 16849 41d1 net/ipv4/ip_output.o Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: phy: phy_interface_is_rgmii helper As you suggested, here is the helper function to avoid missing some RGMII interface checks. Had to wait for net to be merged in net-next to avoid submitting the same patch/commit. Dan, you might want to rebase your dp83867 submission to use that helper when you this patchset gets merged into net-next, thanks! ==================== Signed-off-by: -
Florian Fainelli authored
Update all open-coded tests for all 4 PHY_INTERFACE_MODE_RGMII* values to use the newly introduced helper: phy_interface_is_rgmii. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Florian Fainelli authored
RGMII interfaces come in 4 different flavors that the PHY library needs to care about: regular RGMII (no delays), RGMII with either RX or TX delay, and both. In order to avoid errors of checking only for one type of RGMII interface and miss the 3 others, introduce a convenience function which tests for all values. Suggested-by:
-
David S. Miller authored
We used to get this indirectly I supposed, but no longer do. Either way, an explicit include should have been done in the first place. net/ipv4/fib_trie.c: In function '__node_free_rcu': >> net/ipv4/fib_trie.c:293:3: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration] vfree(n); ^ net/ipv4/fib_trie.c: In function 'tnode_alloc': >> net/ipv4/fib_trie.c:312:3: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration] return vzalloc(size); ^ >> net/ipv4/fib_trie.c:312:3: warning: return makes pointer from integer without a cast cc1: some warnings being treated as errors Reported-by: -
Eric Dumazet authored
By making sure sk->sk_gso_max_segs minimal value is one, and sysctl_tcp_min_tso_segs minimal value is one as well, tcp_tso_autosize() will return a non zero value. We can then revert 843925f3 ("tcp: Do not apply TSO segment limit to non-TSO packets") and save few cpu cycles in fast path. Signed-off-by:
Neal Cardwell <ncardwell@google.com> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
- 26 May, 2015 3 commits
-
-
Eric Dumazet authored
If tcp ehash table is constrained to a very small number of buckets (eg boot parameter thash_entries=128), then we can crash if spinlock array has more entries. While we are at it, un-inline inet_ehash_locks_alloc() and make following changes : - Budget 2 cache lines per cpu worth of 'spinlocks' - Try to kmalloc() the array to avoid extra TLB pressure. (Most servers at Google allocate 8192 bytes for this hash table) - Get rid of various #ifdef Signed-off-by:
-
Jon Paul Maloy authored
In commit dd3f9e70 ("tipc: add packet sequence number at instant of transmission") we made a change with the consequence that packets in the link backlog queue don't contain valid sequence numbers. However, when we create a link protocol message, we still use the sequence number of the first packet in the backlog, if there is any, as "next_sent" indicator in the message. This may entail unnecessary retransissions or stale packet transmission when there is very low traffic on the link. This commit fixes this issue by only using the current value of tipc_link::snd_nxt as indicator. Signed-off-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
-
Eric Dumazet authored
make C=2 CF=-D__CHECK_ENDIAN__ net/core/utils.o ... net/core/utils.c:307:72: warning: incorrect type in argument 2 (different base types) net/core/utils.c:307:72: expected restricted __wsum [usertype] addend net/core/utils.c:307:72: got restricted __be32 [usertype] from net/core/utils.c:308:34: warning: incorrect type in argument 2 (different base types) net/core/utils.c:308:34: expected restricted __wsum [usertype] addend net/core/utils.c:308:34: got restricted __be32 [usertype] to net/core/utils.c:310:70: warning: incorrect type in argument 2 (different base types) net/core/utils.c:310:70: expected restricted __wsum [usertype] addend net/core/utils.c:310:70: got restricted __be32 [usertype] from net/core/utils.c:310:77: warning: incorrect type in argument 2 (different base types) net/core/utils.c:310:77: expected restricted __wsum [usertype] addend net/core/utils.c:310:77: got restricted __be32 [usertype] to net/core/utils.c:312:72: warning: incorrect type in argument 2 (different base types) net/core/utils.c:312:72: expected restricted __wsum [usertype] addend net/core/utils.c:312:72: got restricted __be32 [usertype] from net/core/utils.c:313:35: warning: incorrect type in argument 2 (different base types) net/core/utils.c:313:35: expected restricted __wsum [usertype] addend net/core/utils.c:313:35: got restricted __be32 [usertype] to Note we can use csum_replace4() helper Fixes: 58e3cac5 ("net: optimise inet_proto_csum_replace4()") Signed-off-by:
-
