- 27 Sep, 2017 39 commits
-
-
Yotam Gigi authored
Add functionality for calling the multicast routing offloading logic upon MFC and VIF add and delete notifications. In addition, call the multicast routing upon RIF addition and deletion events. As the multicast routing offload logic may sleep, the actual calls are done in a deferred work. To ensure the MFC object is not freed in that interval, a reference is held to it. In case of a failure, the abort mechanism is used, which ejects all the routes from the hardware and triggers the traffic to flow through the kernel. Note: At that stage, the FIB notifications are still ignored, and will be enabled in a further patch. Signed-off-by:
Yotam Gigi <yotamg@mellanox.com> Reviewed-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Yotam Gigi authored
Currently, the mlxsw Spectrum driver offloads only either the RT_TABLE_MAIN FIB table or the VRF tables, so the RT_TABLE_LOCAL table is squashed to the RT_TABLE_MAIN table to allow local routes to be offloaded too. By default, multicast MFC routes which are not assigned to any user requested table are put in the RT_TABLE_DEFAULT table. Due to the fact that offloading multicast MFC routes support in Spectrum router logic is going to be introduced soon, squash the default table to MAIN too. Signed-off-by:
-
Yotam Gigi authored
Implement the multicast routing hardware API introduced in previous patch for the specific spectrum hardware. The spectrum hardware multicast routes are written using the RMFT2 register and point to an ACL flexible action set. The actions used for multicast routes are: - Counter action, which allows counting bytes and packets on multicast routes. - Multicast route action, which provide RPF check and do the actual packet duplication to a list of RIFs. - Trap action, in the case the route action specified by the called is trap. Signed-off-by:
-
Yotam Gigi authored
Add the multicast router offloading logic, which is in charge of handling the VIF and MFC notifications and translating it to the hardware logic API. The offloading logic has to overcome several obstacles in order to safely comply with the kernel multicast router user API: - It must keep track of the mapping between VIFs to netdevices. The user can add an MFC cache entry pointing to a VIF, delete the VIF and add re-add it with a different netdevice. The offloading logic has to handle this in order to be compatible with the kernel logic. - It must keep track of the mapping between netdevices to spectrum RIFs, as the current hardware implementation assume having a RIF for every port in a multicast router. - It must handle routes pointing to pimreg device to be trapped to the kernel, as the packet should be delivered to userspace. - It must handle routes pointing tunnel VIFs. The current implementation does not support multicast forwarding to tunnels, thus routes that point to a tunnel should be trapped to the kernel. - It must be aware of proxy multicast routes, which include both (*,*) routes and duplicate routes. Currently proxy routes are not offloaded and trigger the abort mechanism: removal of all routes from hardware and triggering the traffic to go through the kernel. The multicast routing offloading logic also updates the counters of the offloaded MFC routes in a periodic work. Signed-off-by:
-
Yotam Gigi authored
When the ipmr starts, it adds one default FIB rule that matches all packets and sends them to the DEFAULT (multicast) FIB table. A more complex rule can be added by user to specify that for a specific interface, a packet should be look up at either an arbitrary table or according to the l3mdev of the interface. For drivers willing to offload the ipmr logic into a hardware but don't want to offload all the FIB rules functionality, provide a function that can indicate whether the FIB rule is the default multicast rule, thus only one routing table is needed. This way, a driver can register to the FIB notification chain, get notifications about FIB rules added and trigger some kind of an internal abort mechanism when a non default rule is added by the user. Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Yotam Gigi authored
Allow drivers, registered to the fib notification chain indicate whether a multicast MFC route is offloaded or not, similarly to unicast routes. The indication of whether a route is offloaded is done using the mfc_flags field on an mfc_cache struct, and the information is sent to the userspace via the RTNetlink interface only. Currently, MFC routes are either offloaded or not, thus there is no need to add per-VIF offload indication. Signed-off-by:
-
Yotam Gigi authored
Use the newly introduced notification chain to send events upon VIF and MFC addition and deletion. The MFC notifications are sent only on resolved MFC entries, as unresolved cannot be offloaded. Signed-off-by:
-
Yotam Gigi authored
Make the ipmr module register as a FIB notifier. To do that, implement both the ipmr_seq_read and ipmr_dump ops. The ipmr_seq_read op returns a sequence counter that is incremented on every notification related operation done by the ipmr. To implement that, add a sequence counter in the netns_ipv4 struct and increment it whenever a new MFC route or VIF are added or deleted. The sequence operations are protected by the RTNL lock. The ipmr_dump iterates the list of MFC routes and the list of VIF entries and sends notifications about them. The entries dump is done under RCU where the VIF dump uses the mrt_lock too, as the vif->dev field can change under RCU. Signed-off-by:
-
Yotam Gigi authored
Next commits will introduce MFC notifications through the atomic fib_notification chain, thus allowing modules to be aware of MFC entries. Due to the fact that modules may need to hold a reference to an MFC entry, add reference count to MFC entries to prevent them from being freed while these modules use them. The reference counting is done only on resolved MFC entries currently. Signed-off-by:
-
Yotam Gigi authored
In order for an interface to forward packets according to the kernel multicast routing table, it must be configured with a VIF index according to the mroute user API. The VIF index is then used to refer to that interface in the mroute user API, for example, to set the iif and oifs of an MFC entry. In order to allow drivers to be aware and offload multicast routes, they have to be aware of the VIF add and delete notifications. Due to the fact that a specific VIF can be deleted and re-added pointing to another netdevice, and the MFC routes that point to it will forward the matching packets to the new netdevice, a driver willing to offload MFC cache entries must be aware of the VIF add and delete events in addition to MFC routes notifications. Signed-off-by:
-
David S. Miller authored
Simon Horman says: ==================== nfp: flower vxlan tunnel offload John says: This patch set allows offloading of TC flower match and set tunnel fields to the NFP. The initial focus is on VXLAN traffic. Due to the current state of the NFP firmware, only VXLAN traffic on well known port 4789 is handled. The match and action fields must explicity set this value to be supported. Tunnel end point information is also offloaded to the NFP for both encapsulation and decapsulation. The NFP expects 3 separate data sets to be supplied. For decapsulation, 2 separate lists exist; a list of MAC addresses referenced by an index comprised of the port number, and a list of IP addresses. These IP addresses are not connected to a MAC or port. The MAC addresses can be written as a block or one at a time (because they have an index, previous values can be overwritten) while the IP addresses are always written as a list of all the available IPs. Because the MAC address used as a tunnel end point may be associated with a physical port or may be a virtual netdev like an OVS bridge, we do not know which addresses should be offloaded. For this reason, all MAC addresses of active netdevs are offloaded to the NFP. A notifier checks for changes to any currently offloaded MACs or any new netdevs that may occur. For IP addresses, the tunnel end point used in the rules is known as the destination IP address must be specified in the flower classifier rule. When a new IP address appears in a rule, the IP address is offloaded. The IP is removed from the offloaded list when all rules matching on that IP are deleted. For encapsulation, a next hop table is updated on the NFP that contains the source/dest IPs, MACs and egress port. These are written individually when requested. If the NFP tries to encapsulate a packet but does not know the next hop, then is sends a request to the host. The host carries out a route lookup and populates the given entry on the NFP table. A notifier also exists to check for any links changing or going down in the kernel next hop table. If an offloaded next hop entry is removed from the kernel then it is also removed on the NFP. The NFP periodically sends a message to the host telling it which tunnel ports have packets egressing the system. The host uses this information to update the used value in the neighbour entry. This means that, rather than expire when it times out, the kernel will send an ARP to check if the link is still live. From an NFP perspective, this means that valid entries will not be removed from its next hop table. ==================== Acked-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
John Hurley authored
Periodically receive messages containing the destination IPs of tunnels that have recently forwarded traffic. Update the neighbour entries 'used' value for these IPs next hop. This prevents the neighbour entry from expiring on timeout but rather signals an ARP to verify the connection. From an NFP perspective, packets will not fall back mid-flow unless the link is verified to be down. Signed-off-by:
John Hurley <john.hurley@netronome.com> Reviewed-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
-
John Hurley authored
Receive a request when the NFP does not know the next hop for a packet that is to be encapsulated in a VXLAN tunnel. Do a route lookup, determine the next hop entry and update neighbour table on NFP. Monitor the kernel neighbour table for link changes and update NFP with relevant information. Overwrite routes with zero values on the NFP when they expire. Signed-off-by:
-
John Hurley authored
Maintain a list of IPv4 addresses used as the tunnel destination IP match fields in currently active flower rules. Offload the entire list of NFP_FL_IPV4_ADDRS_MAX (even if some are unused) when new IPs are added or removed. The NFP should only be aware of tunnel end points that are currently used by rules on the device Signed-off-by:
-
John Hurley authored
Generate a list of MAC addresses of netdevs that could be used as VXLAN tunnel end points. Give offloaded MACs an index for storage on the NFP in the ranges: 0x100-0x1ff physical port representors 0x200-0x2ff VF port representors 0x300-0x3ff other offloads (e.g. vxlan netdevs, ovs bridges) Assign phys and vf indexes based on unique 8 bit values in the port num. Maintain list of other netdevs to ensure same netdev is not offloaded twice and each gets a unique ID without exhausting the entries. Because the IDs are unique but constant for a netdev, any changes are implemented by overwriting the index on NFP. Signed-off-by:
-
John Hurley authored
Compile set tunnel actions for tc flower. Only support VXLAN and ensure a tunnel destination port of 4789 is used. Signed-off-by:
-
John Hurley authored
Compile ovs-tc flower vxlan metadata match fields for offloading. Only support offload of tunnel data when the VXLAN port specifically matches well known port 4789. Signed-off-by:
-
John Hurley authored
Add a helper function that returns the length of the cmsg data when given the cmsg skb Signed-off-by:
-
David S. Miller authored
Jiri Pirko says: ==================== mlxsw: Introduce support for "pass" gact action offloading Very simple patchset adds ability for user to insert filters with "pass" gact action and offload it. That allows scenarios like this: $ tc filter add dev enp3s0np19 ingress protocol ip pref 10 flower skip_sw dst_ip 192.168.101.0/24 action drop $ tc filter add dev enp3s0np19 ingress protocol ip pref 9 flower skip_sw dst_ip 192.168.101.1 action pass ==================== Signed-off-by: -
Jiri Pirko authored
If action is "gact_ok", offload it to HW. Signed-off-by:
-
Jiri Pirko authored
Introduce a helper called is_tcf_gact_pass which could be used to tell if the action is gact pass or not. Signed-off-by:
-
Jiri Pirko authored
Propagate error instead of doing WARN_ON right away. Signed-off-by:
-
David S. Miller authored
Vivien Didelot says: ==================== net: dsa: use generic slave phydev DSA currently stores a phy_device pointer in each slave private structure. This requires to implement our own ethtool ksettings accessors and such. This patchset removes the private phy_device in favor of the one provided in the net_device structure, and thus allows us to use the generic phy_ethtool_* functions. ==================== Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vivien Didelot authored
Use phy_ethtool_nway_reset now that dsa_slave_nway_reset does exactly the same. Signed-off-by:
Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
-
Vivien Didelot authored
Use phy_ethtool_set_link_ksettings now that dsa_slave_set_link_ksettings does exactly the same. Signed-off-by:
-
Vivien Didelot authored
Use phy_ethtool_get_link_ksettings now that dsa_slave_get_link_ksettings does exactly the same. Signed-off-by:
-
Vivien Didelot authored
There is no need to store a phy_device in dsa_slave_priv since net_device already provides one. Simply s/p->phy/dev->phydev/. Signed-off-by:
-
Vivien Didelot authored
Instead of returning -EOPNOTSUPP when a slave device has no PHY, directly return -ENODEV as ethtool and phylib do. Signed-off-by:
-
David S. Miller authored
Jiri Pirko says: ==================== mlxsw: Add router adjacency dpipe table Arkadi says: This patchset adds router adjacency dpipe table support. This will provide the ability to observe the hardware offloaded IPv4/6 nexthops. ==================== Signed-off-by: -
Arkadi Sharshevsky authored
Add support for controlling nexthop counters via dpipe. Signed-off-by:
Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by:
-
Arkadi Sharshevsky authored
Add support for adjacency table dump. Signed-off-by:
-
Arkadi Sharshevsky authored
Add support for setting counters on nexthops based on dpipe's adjacency table counter status. This patch also adds the ability for getting the counter value, which will be used by the dpipe adjacency table dump implementation in the next patches. Signed-off-by:
-
Arkadi Sharshevsky authored
In order to add the ability for setting counters on nexthops the RATR register should be extended. Signed-off-by:
-
Arkadi Sharshevsky authored
Add initial support for router adjacency table. The table does lookup based on the nexthop-group index and the local nexthop offset. After locating the nexthop entry it sets the destination MAC address and the egress RIF. Signed-off-by:
-
Arkadi Sharshevsky authored
This is done as a preparation before introducing the ability to dump the adjacency table via dpipe, and to count the table size. The current table implementation avoids tunnel entries, thus a helper for checking if the nexthop group contains tunnel entries is also provided. The mlxsw's nexthop representative struct stays private to the router module. Signed-off-by:
-
Arkadi Sharshevsky authored
Use list_is_last helper to check for last neighbor. Signed-off-by:
-
Arkadi Sharshevsky authored
Keep nexthops in a linked list for easy access. Signed-off-by:
-
Arkadi Sharshevsky authored
This patch adds field for mlxsw's meta header which will be used to describe the match/action behavior of the adjacency table. The fields are: 1. Adj_index - The global index of the nexthop group in the adjacency table. 2. Adj_hash_index - Local index offset which is based on packets hash mod the nexthop group size. Signed-off-by:
-
Arkadi Sharshevsky authored
Fix indentation in mlxsw_meta header's description. Signed-off-by:
-
- 26 Sep, 2017 1 commit
-
-
David S. Miller authored
Daniel Borkmann says: ==================== BPF metadata for direct access This work enables generic transfer of metadata from XDP into skb, meaning the packet has a flexible and programmable room for meta data, which can later be used by BPF to set various skb members when passing up the stack. For details, please see second patch. Support has been implemented and tested with two drivers, and should be straight forward to add to other drivers as well which properly support head adjustment already. ==================== Signed-off-by:
-
