- 19 Jun, 2016 7 commits
-
-
Philippe Reynes authored
The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by:
Philippe Reynes <tremyfr@gmail.com> Acked-by:
Mans Rullgard <mans@mansr.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Eric Dumazet says: ==================== ipv6: better traceroute support in sit and gre In commit ca15a078 ("sit: generate icmpv6 error when receiving icmpv4 error"), Oussama Ghorbel added minimal support for SIT tunnels to generate ICMPv6 messages when receiving ICMPv4 messages. This patch series extends this to GRE tunnels. It also adds support for ICMPV6_TIME_EXCEED. Partial support for RFC 4884 is added, to forward ICMP Multi-part extensions eventually found in the ICMPv4 message. v2: replaced an overlapping memcpy() by memmove() ==================== Signed-off-by:
-
Eric Dumazet authored
When receiving an ICMPv4 message containing extensions as defined in RFC 4884, and translating it to ICMPv6 at SIT or GRE tunnel, we need some extra manipulation in order to properly forward the extensions. This patch only takes care of Time Exceeded messages as they are the ones that typically carry information from various routers in a fabric during a traceroute session. It also avoids complex skb logic if the data_len is not a multiple of 8. RFC states : The "original datagram" field MUST contain at least 128 octets. If the original datagram did not contain 128 octets, the "original datagram" field MUST be zero padded to 128 octets. In practice routers use 128 bytes of original datagram, not more. Initial translation was added in commit ca15a078 ("sit: generate icmpv6 error when receiving icmpv4 error") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Oussama Ghorbel <ghorbel@pivasoftware.com> Signed-off-by:
-
Eric Dumazet authored
ipgre_err() can call ip6_err_gen_icmpv6_unreach() for proper support of ipv4+gre+icmp+ipv6+... frames, used for example by traceroute/mtr. Signed-off-by:
-
Eric Dumazet authored
For better traceroute/mtr support for SIT and GRE tunnels, we translate IPV4 ICMP ICMP_TIME_EXCEEDED to ICMPV6_TIME_EXCEED We also have to translate the IPv4 source IP address of ICMP message to IPv6 v4mapped. Signed-off-by:
-
Eric Dumazet authored
We want to use this helper from GRE as well, so this is the time to move it in net/ipv6/icmp.c Also add a @nhs parameter, since SIT and GRE have different values for the header(s) to skip. Signed-off-by:
-
Eric Dumazet authored
SIT or GRE tunnels might want to translate an IPV4 address into a v4mapped one when translating ICMP to ICMPv6. This patch adds the parameter to icmp6_send() but does not change icmpv6_send() signature. Signed-off-by:
-
- 18 Jun, 2016 33 commits
-
-
Philippe Reynes authored
There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. Signed-off-by: -
Philippe Reynes authored
The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by:
-
Wei Yongjun authored
Fixes the following sparse warnings: net/rds/tcp.c:59:5: warning: symbol 'rds_tcp_min_sndbuf' was not declared. Should it be static? net/rds/tcp.c:60:5: warning: symbol 'rds_tcp_min_rcvbuf' was not declared. Should it be static? Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Acked-by:
Sowmini Varadhan <sowmini.varadhan@oracle.com> Acked-by:
Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by:
-
Wei Yongjun authored
Remove including <linux/version.h> that don't need it. Signed-off-by:
-
Wei Yongjun authored
Remove including <linux/version.h> that don't need it. Signed-off-by:
-
David S. Miller authored
Merge tag 'linux-can-next-for-4.8-20160617' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2016-06-17 this is a pull request of 14 patches for net-next/master. Geert Uytterhoeven contributes a patch that adds a file patterns for CAN device tree bindings to MAINTAINERS. A patch by Alexander Aring fixes warnings when building without proc support. A patch by me improves the sample point calculation. Marek Vasut's patch converts the slcan driver to use CAN_MTU. A patch by William Breathitt Gray converts the tscan1 driver to use module_isa_driver. Two patches by Maximilian Schneider for the gs_usb driver fix coding style and add support for set_phys_id callback. 5 patches by Oliver Hartkopp add support for CANFD to the bcm. And finally two patches by Ramesh Shanmugasundaram, which add support for the rcar_canfd driver. ==================== Signed-off-by:
-
David S. Miller authored
Ivan Khoronzhuk says: ==================== net: ethernet: ti: cpsw: delete rx_descs property There is no reason in rx_descs property because davinici_cpdma driver splits pool of descriptors equally between tx and rx channels. So, this patch series makes driver to use available number of descriptors for rx channels. ==================== Signed-off-by: -
Ivan Khoronzhuk authored
There is no reason to hold s/w dependent parameter in device tree. Even more, there is no reason in this parameter because davinici_cpdma driver splits pool of descriptors equally between tx and rx channels anyway. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by:
-
Ivan Khoronzhuk authored
There is no reason in rx_descs property because davinici_cpdma driver splits pool of descriptors equally between tx and rx channels. That is, if number of descriptors 256, 128 of them are for rx channels. While receiving, the descriptor is freed to the pool and then allocated with new skb. And if in DT the "rx_descs" is set to 64, then 128 - 64 = 64 descriptors are always in the pool and cannot be used, for tx, for instance. It's not correct resource usage, better to set it to half of pool, then the rx pool can be used in full. It will not have any impact on performance, as anyway, the "redundant" descriptors were unused. Signed-off-by:
-
Dan Carpenter authored
"up_map" is a u64 type but we're not using the high 32 bits. Fixes: 35c55c98 ('tipc: add neighbor monitoring framework') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
David S. Miller authored
David Ahern says: ==================== net: vrf: Fix ipv6 source address selection IPv6 address selection is currently messed up for several use cases such as unnumbered deployments with global addresses on the VRF device and none on the enslaved devices. Update the source address selection to consider the real output route as opposed to the VRF route that sends packets to the VRF device first (ie., implement get_saddr6 similar to the IPv4 method) and update the IPv6 address selection to consider L3 domains and preference for addresses on the VRF device). ==================== Signed-off-by: -
David Ahern authored
IPv6 version of 3f2fb9a8 ("net: l3mdev: address selection should only consider devices in L3 domain") and the follow up commit, a17b693cdd876 ("net: l3mdev: prefer VRF master for source address selection"). That is, if outbound device is given then the address preference order is an address from that device, an address from the master device if it is enslaved, and then an address from a device in the same L3 domain. Signed-off-by:
David Ahern <dsa@cumulusnetworks.com> Signed-off-by:
-
David Ahern authored
IPv6 source address selection needs to consider the real egress route. Similar to IPv4 implement a get_saddr6 method which is called if source address has not been set. The get_saddr6 method does a full lookup which means pulling a route from the VRF FIB table and properly considering linklocal/multicast destination addresses. Lookup failures (eg., unreachable) then cause the source address selection to fail which gets propagated back to the caller. Signed-off-by:
-
David Ahern authored
VRF driver needs access to ip6_route_get_saddr code. Since it does little beyond ipv6_dev_get_saddr and ipv6_dev_get_saddr is already exported for modules move ip6_route_get_saddr to the header as an inline. Code move only; no functional change. Signed-off-by:
-
Sudip Mukherjee authored
The variable i was declared but was never used and we were getting a build warning for that. Signed-off-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by:
-
David S. Miller authored
Alexander Duyck says: ==================== Future-proof tunnel offload handlers These patches are meant to address two things. First we are currently using the ndo_add/del_vxlan_port calls with VXLAN-GPE tunnels and we cannot really support that as it is likely to cause more harm than good since VXLAN-GPE can support tunnels without a MAC address on the inner header. As such we need to add a new offload to advertise this, but in doing so it would mean introducing 3 new functions for the driver to request the ports, and then for the tunnel to push the changes to add and delete the ports to the device. However instead of taking that approach I think it would be much better if we just made one common function for fetching the ports, and provided a generic means to push the tunnels to the device. So in order to make this work this patch set does several things. First it merges the existing VXLAN and GENEVE functionality into one set of functions and passes an enum in order to specify the type of tunnel we want to offload. By doing this we only have to extend this enum in the future if we want to add additional types. Second it goes through the drivers replacing all of the tunnel specific offload calls with implementations that support the generic calls so that we can drop the VXLAN and GENEVE specific calls entirely. Finally I go through in the last patch and replace the VXLAN specific offload request that was being used for VXLAN-GPE with one that specifies if we want to offload VXLAN or VXLAN-GPE so that the hardware can decide if it can actually support it or not. I also ended up with some minor clean-up built into the driver patches for this. Most of it is to either fix misuse of build flags, specifying a type to ignore instead of the type that should be used, or in the case of ixgbe I actually moved a rtnl_lock/unlock in order to avoid taking it unless it was actually needed. v2: I did my best to remove the word "offload" from any of the calls or notifiers as this isn't really an offload. It is a workaround for the fact that the drivers don't provide basic features like CHECKSUM_COMPLETE. I also added a disclaimer to the section defining the function prototypes explaining that these are essentially workarounds. I ended up going through and stripping all of the VXLAN and GENEVE build flags from the drivers. There isn't much point in carrying them. In addition I dropped the use of the vxlan.h or geneve.h header files in favor of udp_tunnel.h in the cases where a driver didn't need anything from either of those headers. I updated the tunnel add/del functions so that they pass a udp_tunnel_info structure instead of a list of arguments. This way we should be able to add additional information in the future with little impact on the other drivers. I updated bnxt so that it doesn't use a hard-coded port number for GENEVE. I have been able to test mlx4e, mlx5e, and i40e and verified functionality on these drivers. Though there are patches for the net tree I submitted due to unrelated bugs I found in the mlx4e and i40e/i40evf drivers. v3: Fixed a typo that caused us to add geneve port when we should have been deleting it. Ended up dropping geneve and vxlan wrappers for udp_tunnel_notify_rx_add/del_port and instead just called them directly. Updated comments for functions to call out RTNL instead of port lock. Updated patch description to remove changes that were moved into a second patch. Rebased on latest net-next to fix merge conflict on bnxt driver. ==================== Signed-off-by: -
Alexander Duyck authored
The fact is VXLAN with Generic Protocol Extensions cannot be supported by the same hardware parsers that support VXLAN. The protocol extensions allow for things like a Next Protocol field which in turn allows for things other than Ethernet to be passed over the tunnel. Most existing parsers will not know how to interpret this. To resolve this I am giving VXLAN-GPE its own UDP encapsulation offload type. This way hardware that does support GPE can simply add this type to the switch statement for VXLAN, and if they don't support it then this will fix any issues where headers might be interpreted incorrectly. Signed-off-by:
Alexander Duyck <aduyck@mirantis.com> Acked-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Alexander Duyck authored
Now that we have all the drivers using udp_tunnel_get_rx_ports, ndo_add_udp_enc_rx_port, and ndo_del_udp_enc_rx_port we can drop the function calls that were specific to VXLAN and GENEVE. Signed-off-by:
-
Alexander Duyck authored
This change replaces the network device operations for adding or removing a VXLAN port with operations that are more generically defined to be used for any UDP offload port but provide a type. As such by just adding a line to verify that the offload type is VXLAN we can maintain the same functionality. Signed-off-by:
-
Alexander Duyck authored
This patch goes through and combines the notifiers for VXLAN and GENEVE into a single function for each action. So there is now one combined function for getting ports, one for adding the ports, and one for deleting the ports. Signed-off-by:
-
Alexander Duyck authored
This change replaces the network device operations for adding or removing a VXLAN port with operations that are more generically defined to be used for any UDP offload port but provide a type. As such by just adding a line to verify that the offload type is VXLAN we can maintain the same functionality. Signed-off-by:
-
Alexander Duyck authored
This change replaces the network device operations for adding or removing a VXLAN port with operations that are more generically defined to be used for any UDP offload port but provide a type. As such by just adding a line to verify that the offload type is VXLAN we can maintain the same functionality. Signed-off-by:
-
Alexander Duyck authored
This change replaces the network device operations for adding or removing a VXLAN port with operations that are more generically defined to be used for any UDP offload port but provide a type. As such by just adding a line to verify that the offload type is VXLAN we can maintain the same functionality. In addition I updated the socket address family check so that instead of excluding IPv6 we instead abort of type is not IPv4. This makes much more sense as we should only be supporting IPv4 outer addresses on this hardware. Signed-off-by:
-
Alexander Duyck authored
This change replaces the network device operations for adding or removing a VXLAN port with operations that are more generically defined to be used for any UDP offload port but provide a type. As such by just adding a line to verify that the offload type is VXLAN we can maintain the same functionality. In addition I updated the socket address family check so that instead of excluding IPv6 we instead abort of type is not IPv4. This makes much more sense as we should only be supporting IPv4 outer addresses on this hardware. The last change is that I pulled the rtnl_lock/unlock into the conditional statement for IXGBE_FLAG2_VXLAN_REREG_NEEDED. The motivation behind this is to avoid unneeded bouncing of the mutex which will just slow down the handling of this call anyway. Signed-off-by:
-
Alexander Duyck authored
This patch goes through and combines the notifiers for VXLAN and GENEVE into a single function for each action. So there is now one combined function for getting ports, one for adding the ports, and one for deleting the ports. Signed-off-by:
-
Alexander Duyck authored
This change replaces the network device operations for adding or removing a VXLAN port with operations that are more generically defined to be used for any UDP offload port but provide a type. As such by just adding a line to verify that the offload type if VXLAN we can maintain the same functionality. Signed-off-by:
-
Alexander Duyck authored
This change replaces the network device operations for adding or removing a VXLAN port with operations that are more generically defined to be used for any UDP offload port but provide a type. As such by just adding a line to verify that the offload type if VXLAN we can maintain the same functionality. I have also gone though and removed the BE2NET_VXLAN config option since it no longer relies on the VXLAN code anyway. Signed-off-by:
-
Alexander Duyck authored
The port number for GENEVE is hard coded into the bnxt driver. This is the kind of thing we want to avoid going forward. For now I will integrate this back into the port notifier so that we can change the GENEVE port number if we need to in the future. Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Alexander Duyck authored
This patch ends up doing several things. First it updates the driver to make use of the new unified UDP tunnel offload notifier functions. In addition I updated the code so that we can work around the bits that were checking for if VXLAN was enabled since we are now using a notifier based setup. Signed-off-by:
-
Alexander Duyck authored
This patch goes through and combines the notifiers for VXLAN and GENEVE into a single function for each action. So there is now one combined function for getting ports, one for adding the ports, and one for deleting the ports. I also went through and dropped the BNX2X VXLAN and GENEVE specific build flags. Signed-off-by:
-
Alexander Duyck authored
This patch merges the notifiers for VXLAN and GENEVE into a single UDP tunnel notifier. The idea is that we will want to only have to make one notifier call to receive the list of ports for VXLAN and GENEVE tunnels that need to be offloaded. In addition we add a new set of ndo functions named ndo_udp_tunnel_add and ndo_udp_tunnel_del that are meant to allow us to track the tunnel meta-data such as port and address family as tunnels are added and removed. The tunnel meta-data is now transported in a structure named udp_tunnel_info which for now carries the type, address family, and port number. In the future this could be updated so that we can include a tuple of values including things such as the destination IP address and other fields. I also ended up going with a naming scheme that consisted of using the prefix udp_tunnel on function names. I applied this to the notifier and ndo ops as well so that it hopefully points to the fact that these are primarily used in the udp_tunnel functions. Signed-off-by:
-
Alexander Duyck authored
This patch merges the GENEVE and VXLAN code so that both functions pass through a shared code path. This way we can start the effort of using a single function on the network device drivers to handle both of these tunnel types. Signed-off-by:
-
Alexander Duyck authored
This patch makes it so that we add udp_tunnel.h to vxlan.h and geneve.h header files. This is useful as I plan to move the generic handlers for the port offloads into the udp_tunnel header file and leave the vxlan and geneve headers to be a bit more protocol specific. I also went through and cleaned out a number of redundant includes that where in the .h and .c files for these drivers. Signed-off-by:
-
