- 01 Mar, 2016 19 commits
-
-
John Fastabend authored
The offload decision was originally very basic and tied to if the dev implemented the appropriate ndo op hook. The next step is to allow the user to more flexibly define if any paticular rule should be offloaded or not. In order to have this logic in one function lift the current check into a helper routine tc_should_offload(). Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Paolo Abeni says: ==================== bridge/ovs: avoid skb head copy on frame forwarding Currently, while when an OVS or Linux bridge is used to forward frames towards some tunnel device, a skb_head_copy() may occur if the ingress device do not provide enough headroom for the tx encapsulation. This patch series tries to address the issue implementing a new ndo operation to allow the master device to control the headroom used when allocating the skb on frame reception. Said operation is used by the Linux bridge to notify the bridged ports of needed_headroom changes, and similar bookkeeping and behaviour is also added to openvswitch, on a per datapath basis. Finally, the operation is implemented for veth and tun device, which give performance improvement in the 6-12% range when forwarding frames from said devices towards a vxlan tunnel. v2: - fix netdev_get_fwd_headroom() behaviour - remove some code duplication with the netdev_set_rx_headroom() and netdev_reset_rx_headroom() helpers - handle headroom reset on [v]port removal/deletion - initialize tun align to the old default value v3: - fix a comment typo ==================== Acked-by: Pravin B Shelar <pshelar@ovn.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paolo Abeni authored
The rx headroom for veth dev is the peer device needed_headroom. Avoid ping-pong updates setting the private flag IFF_PHONY_HEADROOM. This avoids skb head reallocation when forwarding from a veth dev towards a device adding some kind of encapsulation. When transmitting frames below the MTU size towards a vxlan device, this gives about 10% performance speed-up when OVS is used to connect the veth and the vxlan device and a little more when using a plain Linux bridge. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paolo Abeni authored
ndo_set_rx_headroom controls the align value used by tun devices to allocate skbs on frame reception. When the xmit device adds a large encapsulation, this avoids an skb head reallocation on forwarding. The measured improvement when forwarding towards a vxlan dev with frame size below the egress device MTU is as follow: vxlan over ipv6, bridged: +6% vxlan over ipv6, ovs: +7% In case of ipv4 tunnels there is no improvement, since the tun device default alignment provides enough headroom to avoid the skb head reallocation. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paolo Abeni authored
This patch implements bookkeeping support to compute the maximum headroom for all the devices in each datapath. When said value changes, the underlying devs are notified via the ndo_set_rx_headroom method. This also increases the internal vports xmit performance. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paolo Abeni authored
On bridge needed_headroom changes, the enslaved devices are notified via the ndo_set_rx_headroom method Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paolo Abeni authored
This method allows the controlling device (i.e. the bridge) to specify additional headroom to be allocated for skb head on frame reception. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Michael Chan says: ==================== bnxt_en: updates for net-next. Miscellaneous updates covering SRIOV, IRQ coalescing, firmware logging and package version for net-next. Thanks. v2: Updated description and added more comments for patch 1. Fixed function parameters formatting for patch 4. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Michael Chan authored
This is used to send NVM_FIND_DIR_ENTRY messages which can return error if the entry is not found. This is normal and the error message will cause unnecessary alarm, so silence it. Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Michael Chan authored
Add a new function bnxt_do_send_msg() to do essentially the same thing with an additional paramter to silence error response messages. All current callers will set silent to false. Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Rob Swindell authored
For everything to fit, we remove the PHY microcode version and replace it with the firmware package version in the fw_version string. Signed-off-by: Rob Swindell <swindell@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Michael Chan authored
Use appropriate firmware request header structure to prepare the firmware messages. This avoids the unnecessary conversion of the fields to 32-bit fields. Add appropriate endian conversion when printing out the message fields in dmesg so that they appear correct in the log. Reported-by: Rob Swindell <swindell@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Michael Chan authored
Before this patch, we used a hardcoded value of 500 msec as the default value for firmware message response timeout. For better portability with future hardware or debug platforms, use the value provided by firmware in the first response and store it for all susequent messages. Redefine the macro HWRM_CMD_TIMEOUT to the stored value. Since we don't have the value yet in the first message, use the 500 ms default if the stored value is zero. Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Michael Chan authored
When tx and rx rings don't share the same completion ring, tx coalescing parameters can be set differently from the rx coalescing parameters. Otherwise, use rx coalescing parameters on shared completion rings. Adjust rx coalescing default values to lower interrupt rate. Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Michael Chan authored
Add a function to set all the coalescing parameters. The function can be used later to set both rx and tx coalescing parameters. v2: Fixed function parameters formatting requested by DaveM. Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Michael Chan authored
Don't convert these to internal hardware tick values before storing them. This avoids the confusion of ethtool -c returning slightly different values than the ones set using ethtool -C when we convert hardware tick values back to micro seconds. Add better comments for the hardware settings. Also, rename the current set of coalescing fields with rx_ prefix. The next patch will add support of tx coalescing values. Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jeffrey Huang authored
During remove_one() when SRIOV is enabled, the PF driver should broadcast PF driver unload notification to all VFs that are attached to VMs. Upon receiving the PF driver unload notification, the VF driver should print a warning message to message log. Certain operations on the VF may not succeed after the PF has unloaded. Signed-off-by: Jeffrey Huang <huangjw@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jeffrey Huang authored
Allow the VF to setup its own MAC address if the PF has not administratively set it for the VF. To do that, we should always store the MAC address from the firmware. There are 2 cases: 1. The MAC address is valid. This MAC address is assigned by the PF and it needs to override the current VF MAC address. 2. The MAC address is zero. The VF will use a random MAC address by default. By storing this 0 MAC address in the VF structure, it will allow the VF user to change the MAC address later using ndo_set_mac_address() when it sees that the stored MAC address is 0. v2: Expanded descriptions and added more comments. Signed-off-by: Jeffrey Huang <huangjw@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Merge tag 'linux-can-next-for-4.6-20160226' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2016-02-26 this is a pull request of 3 patch for net-next/master. There are two patches by Simon Horman, in which the device tree support for the rcar_can driver is improved. One patch by me fixes the bad coding style of the ems_usb driver which was introduced recently. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 29 Feb, 2016 12 commits
-
-
David S. Miller authored
Woojung Huh says: ==================== lan78xx: driver update This patch series add new ethtool functions of set_pauseparam & get_pauseparam and MAINTAINERS entry. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Woojung.Huh@microchip.com authored
Add maintainers for Microchip LAN78XX. UNGLinuxDriver@microchip.com is alias email which goes to current developers work for Microchip Network related products. Signed-off-by: Woojung Huh <woojung.huh@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Woojung.Huh@microchip.com authored
Add ethtool operations of set_pauseram and get_pauseparm. Signed-off-by: Woojung Huh <woojung.huh@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Woojung.Huh@microchip.com authored
It is not required after commit cd772de3 ("phy: keep pause flags in phy driver features") Signed-off-by: Woojung Huh <woojung.huh@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Woojung.Huh@microchip.com authored
Replace devid to chipid & chiprev for easy access. Signed-off-by: Woojung Huh <woojung.huh@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
sixiao@microsoft.com authored
This patch allows the user to set and retrieve speed and duplex of the hv_netvsc device via ethtool. Example: $ ethtool eth0 Settings for eth0: ... Speed: Unknown! Duplex: Unknown! (255) ... $ ethtool -s eth0 speed 1000 duplex full $ ethtool eth0 Settings for eth0: ... Speed: 1000Mb/s Duplex: Full ... This is based on patches by Roopa Prabhu and Nikolay Aleksandrov. Signed-off-by: Simon Xiao <sixiao@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Cong Wang says: ==================== net_sched: update backlog for hierarchical qdisc's For hierarchical qdisc like HTB, we currently only update its qlen but leave its backlog as zero: qdisc htb 1: dev eth0 root refcnt 2 r2q 10 default 1 direct_packets_stat 0 ver 3.17 Sent 172680457356 bytes 222469449 pkt (dropped 0, overlimits 123575834 requeues 0) backlog 0b 72p requeues 0 This patchset makes backlog as accurate as qlen. v3: rebase and fix the n==0 case for qdisc_tree_reduce_backlog() v2: rebase and update changelog, not code change ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
WANG Cong authored
Similarly, we need to update backlog too when we update qlen. Cc: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
WANG Cong authored
We saw qlen!=0 but backlog==0 on our production machine: qdisc htb 1: dev eth0 root refcnt 2 r2q 10 default 1 direct_packets_stat 0 ver 3.17 Sent 172680457356 bytes 222469449 pkt (dropped 0, overlimits 123575834 requeues 0) backlog 0b 72p requeues 0 The problem is we only count qlen for HTB qdisc but not backlog. We need to update backlog too when we update qlen, so that we can at least know the average packet length. Cc: Jamal Hadi Salim <jhs@mojatatu.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
WANG Cong authored
When the bottom qdisc decides to, for example, drop some packet, it calls qdisc_tree_decrease_qlen() to update the queue length for all its ancestors, we need to update the backlog too to keep the stats on root qdisc accurate. Cc: Jamal Hadi Salim <jhs@mojatatu.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
WANG Cong authored
Remove nearly duplicated code and prepare for the following patch. Cc: Jamal Hadi Salim <jhs@mojatatu.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stafford Horne authored
In commit 5b6490de ("3c59x: Use setup_timer()") Amitoj removed add_timer which sets up the epires timer. In this patch the behavior is restore but it uses mod_timer which is a bit more compact. Signed-off-by: Stafford Horne <shorne@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 27 Feb, 2016 1 commit
-
-
Dan Carpenter authored
We intended to return PTR_ERR() here instead of 1. Fixes: 1f9993f6 ('rocker: fix a neigh entry leak issue') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 26 Feb, 2016 8 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 1GbE Intel Wired LAN Driver Updates 2016-02-24 This series contains updates to e1000e, igb and igbvf. Raanan provides updates for e1000e, first increases the ULP timer since it now takes longer for the ULP exit to complete on Skylake. Fixes the configuration of the internal hardware PHY clock gating mechanism, which was causing packet loss due to mis configuring. Fixed additional ULP configuration settings which were not being properly cleared after cable connect in V-Pro capable systems. Added support for more i219 devices. Takuma Ueba provides a fix for I210 where IPv6 autoconf test sometimes fails due to DAD NS for link-local is not transmitted. To avoid this issue, we need to wait until 1000BASE-T status register "Remote receiver status OK". Todd provides a patch to override EEPROM WoL settings for specific OEM devices. Then renamed igb defines to be more generic, since the define E1000_MRQC_ENABLE_RSS_4Q enables 4 and 8 queues depending on the part. Roland Hii fixes an issue where only the half cycle time of less than or equal to 70 millisecond uses the I210 clock output function. His patch adds additional conditions when half cycle time is equal to 125 or 250 or 500 millisecond to use the clock output function. Alex Duyck adds support for generic transmit checksums for igb and igbvf. Jon Maxwell fixes an issues where customer applications are registering and un-registering multicast addresses every few seconds which is leading to many "Link is up" messages in the logs as a result of the netif_carrier_off(netdev) in igbvf_msix_other(). So remove the link is up message when registering multicast addresses. Corinna Vinschen provides a fix for when switching off VLAN offloading on i350, the VLAN interface becomes unusable. Stefan Assmann updates the driver to use ndo_stop() instead of dev_close() when running ethtool offline self test. Since dev_close() causes IFF_UP to be cleared which will remove the interfaces routes and some addresses. v2: Dropped patches 6-10 in the original series. Patch 6-7 added support for character device for AVB and based on community feedback, we do not want to do this. Patches 8-10 provided fixes to the problematic code added in patches 6 & 7. So all of them must go! ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Duyck authored
On reviewing the code I realized that GRE and UDP tunnels could cause a kernel panic if we used GSO to segment a large UDP frame that was sent through the tunnel with an outer checksum and hardware offloads were not available. In order to correct this we need to update the feature flags that are passed to the skb_segment function so that in the event of UDP fragmentation being requested for the inner header the segmentation function will correctly generate the checksum for the payload if we cannot segment the outer header. Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
David Ahern says: ==================== net: l3mdev: Fix source address for unnumbered deployments David Lamparter noted a use case where the source address selection fails to pick an address from a VRF interface - unnumbered interfaces. The use case has the VRF device as the VRF local loopback with addresses and interfaces enslaved without an address themselves. e.g, ip addr add 9.9.9.9/32 dev lo ip link set lo up ip link add name vrf0 type vrf table 101 ip rule add oif vrf0 table 101 ip rule add iif vrf0 table 101 ip link set vrf0 up ip addr add 10.0.0.3/32 dev vrf0 ip link add name dummy2 type dummy ip link set dummy2 master vrf0 up --> note dummy2 has no address - unnumbered device ip route add 10.2.2.2/32 dev dummy2 table 101 ip neigh add 10.2.2.2 dev dummy2 lladdr 02:00:00:00:00:02 ping to the 10.2.2.2 through the L3 domain: $ ping -I vrf0 -c1 10.2.2.2 ping: Warning: source address might be selected on device other than vrf0. PING 10.2.2.2 (10.2.2.2) from 9.9.9.9 vrf0: 56(84) bytes of data. picks up the wrong address -- the one from 'lo' not vrf0. And from tcpdump: 12:57:29.449128 IP 9.9.9.9 > 10.2.2.2: ICMP echo request, id 2491, seq 1, length 64 This patch series changes address selection to only consider devices in the same L3 domain and to use the VRF device as the L3 domains loopback. $ ping -I vrf0 -c1 10.2.2.2 PING 10.2.2.2 (10.2.2.2) from 10.0.0.3 vrf0: 56(84) bytes of data. From tcpdump: 12:59:25.096426 IP 10.0.0.3 > 10.2.2.2: ICMP echo request, id 2113, seq 1, length 64 Now the source address comes from vrf0. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
David Lamparter authored
When selecting an address in context of a VRF, the vrf master should be preferred for address selection. If it isn't, the user has a hard time getting the system to select to their preference - the code will pick the address off the first in-VRF interface it can find, which on a router could well be a non-routable address. Signed-off-by: David Lamparter <equinox@diac24.net> Signed-off-by: David Ahern <dsa@cumulusnetworks.com> [dsa: Fixed comment style and removed extra blank link ] Signed-off-by: David S. Miller <davem@davemloft.net>
-
David Ahern authored
David Lamparter noted a use case where the source address selection fails to pick an address from a VRF interface - unnumbered interfaces. Relevant commands from his script: ip addr add 9.9.9.9/32 dev lo ip link set lo up ip link add name vrf0 type vrf table 101 ip rule add oif vrf0 table 101 ip rule add iif vrf0 table 101 ip link set vrf0 up ip addr add 10.0.0.3/32 dev vrf0 ip link add name dummy2 type dummy ip link set dummy2 master vrf0 up --> note dummy2 has no address - unnumbered device ip route add 10.2.2.2/32 dev dummy2 table 101 ip neigh add 10.2.2.2 dev dummy2 lladdr 02:00:00:00:00:02 tcpdump -ni dummy2 & And using ping instead of his socat example: $ ping -I vrf0 -c1 10.2.2.2 ping: Warning: source address might be selected on device other than vrf0. PING 10.2.2.2 (10.2.2.2) from 9.9.9.9 vrf0: 56(84) bytes of data. >From tcpdump: 12:57:29.449128 IP 9.9.9.9 > 10.2.2.2: ICMP echo request, id 2491, seq 1, length 64 Note the source address is from lo and is not a VRF local address. With this patch: $ ping -I vrf0 -c1 10.2.2.2 PING 10.2.2.2 (10.2.2.2) from 10.0.0.3 vrf0: 56(84) bytes of data. >From tcpdump: 12:59:25.096426 IP 10.0.0.3 > 10.2.2.2: ICMP echo request, id 2113, seq 1, length 64 Now the source address comes from vrf0. The ipv4 function for selecting source address takes a const argument. Removing the const requires touching a lot of places, so instead l3mdev_master_ifindex_rcu is changed to take a const argument and then do the typecast to non-const as required by netdev_master_upper_dev_get_rcu. This is similar to what l3mdev_fib_table_rcu does. IPv6 for unnumbered interfaces appears to be selecting the addresses properly. Cc: David Lamparter <david@opensourcerouting.org> Signed-off-by: David Ahern <dsa@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Simon Horman authored
Simply document new compatibility string. As a previous patch adds a generic R-Car Gen2 compatibility string there appears to be no need for a driver updates. By documenting these compat stings they may be used in DTSs shipped, for example as part of ROMs. They must be used in conjunction with the Gen2 fallback compat string. At this time there are no known differences between the r8a779[234] IP blocks and that implemented by the driver for the Gen2 fallback compat string. Thus there is no need to update the driver as the use of the Gen2 fallback compat string will activate the correct code in the current driver while leaving the option for r8a779[234]-specific driver code to be activated in an updated driver should the need arise. Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Simon Horman authored
Add fallback compatibility string for R-Car Gen 1 and Gen2. In the case of Renesas R-Car hardware we know that there are generations of SoCs, e.g. Gen 1 and Gen 2. But beyond that its not clear what the relationship between IP blocks might be. For example, I believe that r8a7779 is older than r8a7778 but that doesn't imply that the latter is a descendant of the former or vice versa. We can, however, by examining the documentation and behaviour of the hardware at run-time observe that the current driver implementation appears to be compatible with the IP blocks on SoCs within a given generation. For the above reasons and convenience when enabling new SoCs a per-generation fallback compatibility string scheme being adopted for drivers for Renesas SoCs. Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This patch fixes the coding style issues introduced in commit: 90cfde46 can: ems_usb: Fix possible tx overflow Reported-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-