- 22 Mar, 2016 16 commits
-
-
Kejian Yan authored
If trying to get receive flow hash indirection table by ethtool, it needs to call .get_rxnfc to get ring number first. So this patch implements the .get_rxnfc of ethtool. And the data type of rss_indir_table is u32, it has to be multiply by the width of data type when using memcpy. Signed-off-by: Kejian Yan <yankejian@huawei.com> Signed-off-by: Yisen Zhuang <Yisen.Zhuang@huawei.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kejian Yan authored
Both .get_rxfh and .set_rxfh are always return 0, it should return result from hardware when getting or setting rss. And the rss function should return the correct data type. Signed-off-by: Kejian Yan <yankejian@huawei.com> Signed-off-by: Yisen Zhuang <Yisen.Zhuang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Qianqian Xie authored
As the user manual of HNS V2 describs, XGE_DFX_CTRL_CFG.xge_dfx_ctrl_cfg should be configed as zero if we want xge statistic reg to be read only. But HNS V1 gets the other meanings. It needs to be identified the process and then config it rightly. Signed-off-by: Qianqian Xie <xieqianqian@huawei.com> Signed-off-by: Yisen Zhuang <Yisen.Zhuang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sheng Li authored
When sending a pause frame out from GMACs, the packets' source MAC address does not match the GMACs' MAC address. It causes by the condition before the mac address setting routine for GMACs, the mac address cannot be set into loacal mac table for service ports. It obviously the condition needs to be deleted. Signed-off-by: Sheng Li <lisheng011@huawei.com> Signed-off-by: Yisen Zhuang <Yisen.Zhuang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kejian Yan authored
Debug ports receives lots of packets with dest mac addr does not match local mac addr, because the filter is close, and it does not drop the useless packets. This patch adds ON/OFF switch of filtering the packets whose dest mac addr do not match the local addr in mac table. And the switch is ON in initialization. Signed-off-by: Kejian Yan <yankejian@huawei.com> Signed-off-by: Peng Li <lipeng321@huawei.com> Signed-off-by: Yisen Zhuang <Yisen.Zhuang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sheng Li authored
In chip V2, the default value of port id in tx BD is Zero. If it is not configurated to the other value, all management packets will be sent out from port0. So port_id in the tx BD needs to be updated when sending a management packet. In V2 chip, when sending mamagement packets, the driver should config the port id to BD descs. Signed-off-by: Sheng Li <lisheng011@huawei.com> Signed-off-by: Yisen Zhuang <Yisen.Zhuang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kejian Yan authored
The current upstreaming code fails to ping other IPv6 net device, because the enet receives the multicast packets with the src mac addr which is the same as its mac addr. These packets need to be dropped. Signed-off-by: Kejian Yan <yankejian@huawei.com> Signed-off-by: Yisen Zhuang <Yisen.Zhuang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Luis de Bethencourt authored
struct in6_addr isn't used anymore in inet6_connection_sock.h, removing the forward declaration. Fixes: 1b33bc3e ("ipv6: remove obsolete inet6 functions") Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David Decotigny authored
By returning -ENOIOCTLCMD, sock_do_ioctl() falls back to calling dev_ioctl(), which provides support for NIC driver ioctls, which includes ethtool support. This is similar to the way ioctls are handled in udp.c or tcp.c. This removes the requirement that ethtool for example be tied to the support of a specific L3 protocol (ethtool uses an AF_INET socket today). Signed-off-by: David Decotigny <decot@googlers.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David Decotigny authored
Updates: commit 793cf87d ("ethtool: Set cmd field in ETHTOOL_GLINKSETTINGS response to wrong nwords") Signed-off-by: David Decotigny <decot@googlers.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Deepa Dinamani authored
The millisecond timestamps returned by the function is converted to network byte order by making a call to htons(). htons() only returns __be16 while __be32 is required here. This was identified by the sparse warning from the buildbot: net/ipv4/af_inet.c:1405:16: sparse: incorrect type in return expression (different base types) net/ipv4/af_inet.c:1405:16: expected restricted __be32 net/ipv4/af_inet.c:1405:16: got restricted __be16 [usertype] <noident> Change the function to use htonl() to return the correct __be32 type instead so that the millisecond value doesn't get truncated. Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Cc: James Morris <jmorris@namei.org> Cc: Patrick McHardy <kaber@trash.net> Cc: Arnd Bergmann <arnd@arndb.de> Fixes: 822c8685 ("net: ipv4: Convert IP network timestamps to be y2038 safe") Reported-by: Fengguang Wu <fengguang.wu@intel.com> [0-day test robot] Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dave Jones authored
commit 911362c7 ("net: add dst_cache support") added a new kconfig option that gets selected by other networking options. It seems the intent wasn't to offer this as a user-selectable option given the lack of help text, so this patch converts it to a silent option. Signed-off-by: Dave Jones <davej@codemonkey.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Benjamin Poirier authored
.//include/linux/netdevice.h:1826: warning: No description found for parameter 'ptype_all' .//include/linux/netdevice.h:1826: warning: No description found for parameter 'ptype_specific' Introduced by commit 7866a621 ("dev: add per net_device packet type chains") Cc: Salam Noureddine <noureddine@arista.com> Signed-off-by: Benjamin Poirier <bpoirier@suse.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Luis de Bethencourt authored
The flags IFF_XMIT_DST_RELEASE_PERM, IFF_IPVLAN_MASTER and IFF_IPVLAN_SLAVE are missing descriptions for the Documentation. Adding them. Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com> Suggested-by: Benjamin Poirier <benjamin.poirier@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Benjamin Poirier authored
Signed-off-by: Benjamin Poirier <bpoirier@suse.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Benjamin Poirier authored
Commit d67ef35f ("clarify documentation for net.ipv4.igmp_max_memberships") mistakenly indented a block of documentation such that it now looks like it belongs to a specific sysctl. Restore that block's original position. Cc: Jeremy Eder <jeder@redhat.com> Signed-off-by: Benjamin Poirier <bpoirier@suse.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 21 Mar, 2016 8 commits
-
-
David S. Miller authored
Eric Dumazet says: ==================== net: propagate max_gso_segs and max_gso_size bridge code does not properly update max_gso_segs and max_gso_size. Since this was not really obvious, first patch adds two new rtnetlink attributes to help debugging this kind of issues (ip -d link) Second patch fixes bridge code. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
It can be useful to lower max_gso_segs on NIC with very low number of TX descriptors like bcmgenet. However, this is defeated by bridge since it does not propagate the lower value of max_gso_segs and max_gso_size. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Petri Gynther <pgynther@google.com> Cc: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
It can be useful to report dev->gso_max_segs and dev->gso_max_size so that "ip -d link" can display them to help debugging. For the moment, these attributes are read-only. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Petri Gynther <pgynther@google.com> Cc: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jiri Benc authored
vxlan_remcsum is called after iptunnel_pull_header and thus the skb has vxlan header already pulled. Don't include vxlan header again in the calculation. Signed-off-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jiri Benc authored
Sparse reports false positives for the header manipulation inlines. Annotate them correctly. Tested by sparse on a little endian and big endian machine. Fixes: 54bfd872 ("vxlan: keep flags and vni in network byte order") Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Luis de Bethencourt authored
When the function dev_get_phys_port_name was added it missed a description for it's len argument. Adding it. Fixes: db24a904 ("net: add support for phys_port_name") Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dan Carpenter authored
We could end up dereferencing an error pointer when we call regulator_disable(). Fixes: 4bdcb1dd ('net: Add MDIO bus driver for the Allwinner EMAC') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Arnd Bergmann authored
The change to use the generic DMA engine API in the smc911x driver has led to a harmless warning about unused local variables: smsc/smc911x.c: In function 'smc911x_probe': smsc/smc911x.c:1796:20: error: unused variable 'param' smsc/smc911x.c:1795:17: error: unused variable 'mask' smsc/smc911x.c:1794:26: error: unused variable 'config' This puts the variable declarations inside of the same #ifdef that protects their use. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 79d3b59a ("net: smc911x: convert pxa dma to dmaengine") Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 20 Mar, 2016 16 commits
-
-
David S. Miller authored
This reverts commit a59f8c5b. There are several bugs in this new code, for example: 1) Uses sleeping locks in get_stats64, which is not allowed, as the operation can be invoked in an atomic context. 2) Uses PM fields without CONFIG_PM or similar guards. 3) Does not synchronize HW stats when the device runtime suspends. Therefore this is being reverted until a correct version is implemented. Signed-off-by: David S. Miller <davem@davemloft.net>
-
Luis de Bethencourt authored
Commit 22e0f8b9 ("net: sched: make bstats per cpu and estimator RCU safe") added the argument cpu_bstats to functions gen_new_estimator and gen_replace_estimator and now the descriptions of these are missing for the documentation. Adding them. Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Luis de Bethencourt authored
Function gnet_stats_copy_basic is missing the description of the cpu argument in the documentation. Adding it. Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tina Ruchandani authored
'struct timeval' uses 32-bit representation for seconds which will overflow in year 2038 and beyond. mISDN/clock.c needs to compute and store elapsed time in intervals of 125 microseconds. This patch replaces the usage of 'struct timeval' with 64-bit ktime_t which is y2038 safe. The patch also replaces do_gettimeofday() (wall-clock time) with ktime_get() (monotonic time) since we only care about elapsed time here. Signed-off-by: Tina Ruchandani <ruchandani.tina@gmail.com> Suggested-by: Arnd Bergmnann <arnd@arndb.de> Suggested-by: David Miller <davem@davemloft.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jesse Gross says: ==================== Tunneling fixes This series fixes a problem that was reported where encapsulated packets do not have their encapsulation offload markers stripped off when being decapsulated. This causes a significant performance drop if the packets are later retransmitted. Fixing this revealed two other bugs which are also addressed as prerequisites: * GRO can aggregate packets for multiple layers of encapsulation which the stack cannot properly handle. * IPIP packets which are combined by GRO are not marked properly with their GSO type. Note that this is based off the net-next tree as the current target for bug fixes. v2: No code changes, just additional information in commit messages and a new cover letter. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jesse Gross authored
If a packet is either locally encapsulated or processed through GRO it is marked with the offloads that it requires. However, when it is decapsulated these tunnel offload indications are not removed. This means that if we receive an encapsulated TCP packet, aggregate it with GRO, decapsulate, and retransmit the resulting frame on a NIC that does not support encapsulation, we won't be able to take advantage of hardware offloads even though it is just a simple TCP packet at this point. This fixes the problem by stripping off encapsulation offload indications when packets are decapsulated. The performance impacts of this bug are significant. In a test where a Geneve encapsulated TCP stream is sent to a hypervisor, GRO'ed, decapsulated, and bridged to a VM performance is improved by 60% (5Gbps->8Gbps) as a result of avoiding unnecessary segmentation at the VM tap interface. Reported-by: Ramu Ramamurthy <sramamur@linux.vnet.ibm.com> Fixes: 68c33163 ("v4 GRE: Add TCP segmentation offload for GRE") Signed-off-by: Jesse Gross <jesse@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jesse Gross authored
When drivers express support for TSO of encapsulated packets, they only mean that they can do it for one layer of encapsulation. Supporting additional levels would mean updating, at a minimum, more IP length fields and they are unaware of this. No encapsulation device expresses support for handling offloaded encapsulated packets, so we won't generate these types of frames in the transmit path. However, GRO doesn't have a check for multiple levels of encapsulation and will attempt to build them. UDP tunnel GRO actually does prevent this situation but it only handles multiple UDP tunnels stacked on top of each other. This generalizes that solution to prevent any kind of tunnel stacking that would cause problems. Fixes: bf5a755f ("net-gre-gro: Add GRE support to the GRO stack") Signed-off-by: Jesse Gross <jesse@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jesse Gross authored
ipip encapsulated packets can be merged together by GRO but the result does not have the proper GSO type set or even marked as being encapsulated at all. Later retransmission of these packets will likely fail if the device does not support ipip offloads. This is similar to the issue resolved in IPv6 sit in feec0cb3 ("ipv6: gro: support sit protocol"). Reported-by: Patrick Boutilier <boutilpj@ednet.ns.ca> Fixes: 9667e9bb ("ipip: Add gro callbacks to ipip offload") Tested-by: Patrick Boutilier <boutilpj@ednet.ns.ca> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Jesse Gross <jesse@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Marcelo Ricardo Leitner authored
If the user supply a different fragmentation point or if there is a network header that cause it to not be aligned, force it to be aligned. Fragmentation point at a value that is not aligned is not optimal. It causes extra padding to be used and has just no pros. v2: - Make use of the new WORD_TRUNC macro Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Marcelo Ricardo Leitner authored
SCTP is a protocol that is aligned to a word (4 bytes). Thus using bare MTU can sometimes return values that are not aligned, like for loopback, which is 65536 but ipv4_mtu() limits that to 65535. This mis-alignment will cause the last non-aligned bytes to never be used and can cause issues with congestion control. So it's better to just consider a lower MTU and keep congestion control calcs saner as they are based on PMTU. Same applies to icmp frag needed messages, which is also fixed by this patch. One other effect of this is the inability to send MTU-sized packet without queueing or fragmentation and without hitting Nagle. As the check performed at sctp_packet_can_append_data(): if (chunk->skb->len + q->out_qlen >= transport->pathmtu - packet->overhead) /* Enough data queued to fill a packet */ return SCTP_XMIT_OK; with the above example of MTU, if there are no other messages queued, one cannot send a packet that just fits one packet (65532 bytes) and without causing DATA chunk fragmentation or a delay. v2: - Added WORD_TRUNC macro Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Marcelo Ricardo Leitner authored
Currently, if a chunk is scheduled to be sent through a transport that is currently unconfirmed, it will be leaked as it is dequeued from outq and is not re-queued nor freed. As I'm not aware of any situation that may lead to this situation, I'm fixing this by freeing the chunk and also logging a trace so that we can fix the other bug if it ever happens. Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Marcelo Ricardo Leitner authored
The SACK can be lost pretty much elsewhere, but if its allocation fail, we know we are not sending it, so it is better to revert a_rwnd to its previous value as this may give it a chance to issue a window update later. Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
TCP protocol is still used these days, and TCP uses clones in its transmit path. We can not optimize linux stack assuming it is mostly used in routers, or that TCP is dead. Fixes: 795bb1c0 ("net: bulk free infrastructure for NAPI context, use napi_consume_skb") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Colin Ian King authored
zero_gid is not used, so remove this redundant array. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Daniel Borkmann says: ==================== flowi6_tos fixes This set is a follow-up to address Jiri's recent feedback [1] on the flowi6_tos issue, that it is not used for IPv6 route lookups. The three patches fix all current users of flowi6_tos and remove the define to avoid any future confusion on this. Tested the vxlan and geneve ones with IPv6 routing rules. For details, please see individual patches. [ As fixes are currently applied against net-next tree, I've rebased it against that. ] Thanks! [1] http://patchwork.ozlabs.org/patch/592055/ ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daniel Borkmann authored
flowi6_tos of struct flowi6 is unused in IPv6, therefore dumping tos on that tracepoint will also give incorrect information wrt traffic class. If we want to fix it, we need to extract it via ip6_tclass(flp->flowlabel). While for the same test case I get a count of 0 non-zero tos values before the change, they now start to show up after the change: # ./perf record -e fib6:fib6_table_lookup -a sleep 10 # ./perf script | grep -v "tos 0" | wc -l 60 Since there's no user in the kernel tree anymore of flowi6_tos, remove the define to avoid any future confusion on this. Fixes: b811580d ("net: IPv6 fib lookup tracepoint") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-