- 27 Apr, 2018 40 commits
-
-
Marcelo Ricardo Leitner authored
As noticed by Xin Long, the if() here is always true as PMTU can never be 0. Reported-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Marcelo Ricardo Leitner authored
There was only one case that sctp_assoc_add_peer couldn't handle, which is when SPP_PMTUD_DISABLE is set and pathmtu not initialized. So add this situation to sctp_transport_route and reuse what was already in there. Signed-off-by:
-
Marcelo Ricardo Leitner authored
This value is not used anywhere in the code. In essence it is a duplicate of SCTP_DEFAULT_MINSEGMENT, which is used by the stack. SCTP_MIN_PMTU value makes more sense, but we should not change to it now as it would risk breaking applications. So this patch removes SCTP_MIN_PMTU and adjust the comment above it. Signed-off-by:
-
Stefano Brivio authored
A vti6 interface can carry IPv4 packets too. Signed-off-by:
Stefano Brivio <sbrivio@redhat.com> Reviewed-by:
-
Wei Wang authored
In tcp_select_initial_window(), we only set rcv_wnd to tcp_default_init_rwnd() if current mss > (1 << wscale). Otherwise, rcv_wnd is kept at the full receive space of the socket which is a value way larger than tcp_default_init_rwnd(). With larger initial rcv_wnd value, receive buffer autotuning logic takes longer to kick in and increase the receive buffer. In a TCP throughput test where receiver has rmem[2] set to 125MB (wscale is 11), we see the connection gets recvbuf limited at the beginning of the connection and gets less throughput overall. Signed-off-by:
Wei Wang <weiwan@google.com> Acked-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Soheil Hassas Yeganeh <soheil@google.com> Acked-by:
Yuchung Cheng <ycheng@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
-
David S. Miller authored
Ursula Braun says: ==================== smc fixes from 2018-04-17 - v3 in the mean time we challenged the benefit of these CLC handshake optimizations for the sockopts TCP_NODELAY and TCP_CORK. We decided to give up on them for now, since SMC still works properly without. There is now version 3 of the patch series with patches 2-4 implementing sockopts that require special handling in SMC. Version 3 changes * no deferring of setsockopts TCP_NODELAY and TCP_CORK anymore * allow fallback for some sockopts eliminating SMC usage * when setting TCP_NODELAY always enforce data transmission (not only together with corked data) Version 2 changes of Patch 2/4 (and 3/4): * return error -EOPNOTSUPP for TCP_FASTOPEN sockopts * fix a kernel_setsockopt() usage bug by switching parameter variable from type "u8" to "int" * add return code validation when calling kernel_setsockopt() * propagate a setsockopt error on the internal CLC socket to the SMC socket. ==================== Signed-off-by: -
Ursula Braun authored
If sockopt TCP_DEFER_ACCEPT is set, the accept is delayed till data is available. Signed-off-by:
Ursula Braun <ubraun@linux.ibm.com> Signed-off-by:
-
Ursula Braun authored
Setting sockopt TCP_NODELAY or resetting sockopt TCP_CORK triggers data transfer. For a corked SMC socket RDMA writes are deferred, if there is still sufficient send buffer space available. Signed-off-by:
-
Ursula Braun authored
Several TCP sockopts do not work for SMC. One example are the TCP_FASTOPEN sockopts, since SMC-connection setup is based on the TCP three-way-handshake. If the SMC socket is still in state SMC_INIT, such sockopts trigger fallback to TCP. Otherwise an error is returned. Signed-off-by:
-
Karsten Graul authored
The struct smc_cdc_msg must be defined as packed so the size is 44 bytes. And change the structure size check so sizeof is checked. Signed-off-by:
Karsten Graul <kgraul@linux.ibm.com> Signed-off-by:
-
Jeff Kirsher authored
After many years of having a ~30 line copyright and license header to our source files, we are finally able to reduce that to one line with the advent of the SPDX identifier. Also caught a few files missing the SPDX license identifier, so fixed them up. Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Acked-by:
Shannon Nelson <shannon.nelson@oracle.com> Acked-by:
Richard Cochran <richardcochran@gmail.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
-
Kirill Tkhai authored
kbuild test robot says: >coccinelle warnings: (new ones prefixed by >>) >>> net/core/dev.c:1588:2-3: Unneeded semicolon So, let's remove it. Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by:
-
Tobias Regnery authored
Commit c40e89fd ("geneve: configure MTU based on a lower device") added an IS_ENABLED(CONFIG_IPV6) to geneve, leading to the following link error with CONFIG_GENEVE=y and CONFIG_IPV6=m: drivers/net/geneve.o: In function `geneve_link_config': geneve.c:(.text+0x14c): undefined reference to `rt6_lookup' Fix this by adding a Kconfig dependency and forcing GENEVE to be a module when IPV6 is a module. Fixes: c40e89fd ("geneve: configure MTU based on a lower device") Signed-off-by:
Tobias Regnery <tobias.regnery@gmail.com> Signed-off-by:
-
David S. Miller authored
Julian Wiedmann says: ==================== s390/net: updates 2018-04-26 please apply the following patches to net-next. There's the usual cleanups & small improvements, and Kittipon adds HW offload support for IPv6 checksumming. ==================== Signed-off-by: -
Julian Wiedmann authored
If READ MAC fails to fetch a valid MAC address, allow some more device types (IQD and z/VM OSD) to fall back to a random address. Also use eth_hw_addr_random(), for indicating to userspace that the address type is NET_ADDR_RANDOM. Note that while z/VM has various protection schemes to prohibit custom addresses on its NICs, they are all optional. So we should at least give it a try. Signed-off-by:
Julian Wiedmann <jwi@linux.vnet.ibm.com> Signed-off-by:
-
Kittipon Meesompop authored
Check if a qeth device supports IPv6 RX checksum offload, and hook it up into the existing NETIF_F_RXCSUM support. As NETIF_F_RXCSUM is now backed by a combination of HW Assists, we need to be a little smarter when dealing with errors during a configuration change: - switching on NETIF_F_RXCSUM only makes sense if at least one HW Assist was enabled successfully. - for switching off NETIF_F_RXCSUM, all available HW Assists need to be deactivated. Signed-off-by:
Kittipon Meesompop <kmeesomp@linux.vnet.ibm.com> Signed-off-by:
-
Kittipon Meesompop authored
Check if a qeth device supports IPv6 TX checksum offload, and advertise NETIF_F_IPV6_CSUM accordingly. Add support for setting the relevant bits in IPv6 packet descriptors. Currently this has only limited use (ie. UDP, or Jumbo Frames). For any TCP traffic with a standard MSS, the TCP checksum gets calculated as part of the linear GSO segmentation. Signed-off-by:
-
Kittipon Meesompop authored
Add some wrappers to make the protocol-specific Assist code a little more generic, and use them for sending protocol-agnostic commands in the Checksum Offload Assist code. Signed-off-by:
-
Kittipon Meesompop authored
For new functionality, the L2 subdriver will start using IPv6 assists. So move the query from the L3 subdriver into the common setup path. Signed-off-by:
-
Kittipon Meesompop authored
This matches the statistics we gather for the TX offload path. Signed-off-by:
-
Julian Wiedmann authored
The kernel does its own validation of the IPv4 header checksum, drivers/HW are not required to handle this. Signed-off-by:
-
Julian Wiedmann authored
This consolidates the checksum offload code that was duplicated over the two qeth subdrivers. Signed-off-by:
-
Kittipon Meesompop authored
Trivial cleanup, in preparation for a subsequent patch. Signed-off-by:
-
Ursula Braun authored
struct net_device contains a dev_port field. Store the OSA port number in this field. Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by:
-
Julian Wiedmann authored
When removing a VLAN ID on a L3 device, the driver currently attempts to walk and unregister the VLAN device's IP addresses. This can be safely removed - before qeth_l3_vlan_rx_kill_vid() even gets called, we receive an inet[6]addr event for each IP on the device and qeth_l3_handle_ip_event() unregisters the address accordingly. Signed-off-by:
-
Julian Wiedmann authored
As the vid_list is only accessed from process context, there's no need to protect it with a spinlock. Signed-off-by:
-
Julian Wiedmann authored
Both qeth sub drivers use the same QDIO queue handlers, there's no need to expose them via the driver's discipline. No functional change. Signed-off-by:
-
YueHaibing authored
Use hlist_entry_safe() instead of open-coding it. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Reviewed-by:
Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
-
David S. Miller authored
Pradeep Nalla says: ==================== liquidio: add support for ndo_get_stats64 Support ndo_get_stats64 instead of ndo_get_stats. Also add stats for multicast and broadcast packets. ==================== Signed-off-by: -
Pradeep Nalla authored
Support ndo_get_stats64 instead of ndo_get_stats. Also add stats for multicast and broadcast packets. Signed-off-by:
Pradeep Nalla <pradeep.nalla@cavium.com> Acked-by:
Raghu Vatsavayi <raghu.vatsavayi@cavium.com> Signed-off-by:
Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by:
-
Pradeep Nalla authored
To support the next patch in this series which has code that calls octnet_get_link_stats from two different .c files, move that function (and its dependency octnet_nic_stats_callback) to lio_core.c. Remove octnet_get_link_stats's static declaration and add its function prototype in octeon_network.h. Signed-off-by:
-
David S. Miller authored
Make PHYLIB boolean, because we reference phylib provided symbols now from net/core/ethtool.c and therefore 'm' doesn't work. Signed-off-by: -
David S. Miller authored
Florian Fainelli says: ==================== net: Extend availability of PHY statistics This patch series adds support for retrieving PHY statistics with DSA switches when the CPU port uses a PHY to PHY connection (as opposed to MAC to MAC). To get there a number of things are done: - first we move the code dealing with PHY statistics outside of net/core/ethtool.c and create helper functions since the same code will be reused - then we allow network device drivers to provide an ethtool_get_phy_stats callback when the standard PHY library helpers are not suitable - we update the DSA functions dealing with ethtool operations to get passed a stringset instead of assuming ETH_SS_STATS like they currently do - then we provide a set of standard helpers within DSA as a framework and add the plumbing to allow retrieving the PHY statistics of the CPU port(s) - finally plug support for retrieving such PHY statistics with the b53 driver Changes in v3: - retrict the b53 change to 539x and 531x5 series of switches - added a change to dsa_loop.c to help test the feature Changes in v2: - got actual testing when the DSA master network device has a PHY that already provides statistics (thanks Nikita!) - fixed the kbuild error reported when CONFIG_PHYLIB=n - removed the checking of ops which is redundant and not needed ==================== Signed-off-by: -
Florian Fainelli authored
We just return the same statistics through ethtool_get_stats() and ethtool_get_phy_stats() for simplicity since this is just a mock-up driver. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Florian Fainelli authored
Allow the b53 driver to return PHY statistics when the CPU port used is different than 5, 7 or 8, because those are typically PHY-less on most devices. This is useful for debugging link problems between the switch and an external host when using a non standard CPU port number (e.g: 4). Signed-off-by:
-
Florian Fainelli authored
Implement the same type of ethtool diversion that we have for ETH_SS_STATS and make it work with ETH_SS_PHY_STATS. This allows providing PHY level statistics for CPU ports that are directly connecting to a PHY device. Signed-off-by:
-
Florian Fainelli authored
In preparation for having more call sites attempting to obtain a reference against a PHY device corresponding to a particular port, introduce a helper function for that purpose. Signed-off-by:
-
Florian Fainelli authored
Up until now we largely assumed that we were interested in ETH_SS_STATS type of strings for all ethtool operations, this is about to change with the introduction of additional string sets, e.g: ETH_SS_PHY_STATS. Update all functions to take an appropriate stringset argument and act on it when it is different than ETH_SS_STATS for now. Signed-off-by:
-
Florian Fainelli authored
This is completely redundant with what netdev_set_default_ethtool_ops() does, we are always guaranteed to have a valid dev->ethtool_ops pointer, however, within that structure, not all function calls may be populated, so we still have to check them individually. Signed-off-by:
-
Florian Fainelli authored
Add a new callback: get_ethtool_phy_stats() which allows network device drivers not making use of the PHY library to return PHY statistics. Update ethtool_get_phy_stats(), __ethtool_get_sset_count() and __ethtool_get_strings() accordingly to interogate the network device about ETH_SS_PHY_STATS. Signed-off-by:
-
