- 17 Aug, 2015 2 commits
-
-
Yuval Mintz authored
Management firmware tells driver in case bandwidth configuration for a specific function exists, but [regretably] the same field has different meanings depending on the multi-function mode - it can either be a percentile value or an actual speed. For newer multi-function modes current logic is incorrect - driver understands values as actual speeds instead of percentages, causing the resulting chip configuration to be incorrect. Signed-off-by:
Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
fib_lookup() forces FIB_LOOKUP_NOREF flag, while fib_table_lookup() does not. This patch solves the typical message at reboot time or device dismantle : unregister_netdevice: waiting for eth0 to become free. Usage count = 4 Fixes: 3bfd8472 ("net: Use passed in table for nexthop lookups") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: David Ahern <dsa@cumulusnetworks.com> Acked-by:
David Ahern <dsa@cumulusnetworks.com> Signed-off-by:
-
- 14 Aug, 2015 28 commits
-
-
David S. Miller authored
David Ahern says: ==================== VRF-lite - v6 In the context of internet scale routing a requirement that always comes up is the need to partition the available routing tables into disjoint routing planes. A specific use case is the multi-tenancy problem where each tenant has their own unique routing tables and in the very least need different default gateways. This patch allows the ability to create virtual router domains (aka VRFs (VRF-lite to be specific) in the linux packet forwarding stack. The main observation is that through the use of rules and socket binding to interfaces, all the facilities that we need are already present in the infrastructure. What is missing is a handle that identifies a routing domain and can be used to gather applicable rules/tables and uniqify neighbor selection. The scheme used needs to preserves the notions of ECMP, and general routing principles. This driver is a cross between functionality that the IPVLAN driver and the Team drivers provide where a device is created and packets into/out of the routing domain are shuttled through this device. The device is then used as a handle to identify the applicable rules. The VRF device is thus the layer3 equivalent of a vlan device. The very important point to note is that this is only a Layer3 concept so L2 tools (e.g., LLDP) do not need to be run in each VRF, processes can run in unaware mode or select a VRF to be talking through. Also the behavioral model is a generalized application of the familiar VRF-Lite model with some performance paths that need optimization. (Specifically the output route selector that Roopa, Robert, Thomas and EricB are currently discussing on the MPLS thread) High Level points ================= 1. Simple overlay driver (minimal changes to current stack) * uses the existing fib tables and fib rules infrastructure 2. Modelled closely after the ipvlan driver 3. Uses current API and infrastructure. * Applications can use SO_BINDTODEVICE or cmsg device indentifiers to pick VRF (ping, traceroute just work) * Standard IP Rules work, and since they are aggregated against the device, scale is manageable 4. Completely orthogonal to Namespaces and only provides separation in the routing plane (and ARP) N2 N1 (all configs here) +---------------+ +--------------+ | | |swp1 :10.0.1.1+----------------------+swp1 :10.0.1.2 | | | | | |swp2 :10.0.2.1+----------------------+swp2 :10.0.2.2 | | | +---------------+ | VRF 1 | | table 5 | | | +---------------+ | | | VRF 2 | N3 | table 6 | +---------------+ | | | | |swp3 :10.0.2.1+----------------------+swp1 :10.0.2.2 | | | | | |swp4 :10.0.3.1+----------------------+swp2 :10.0.3.2 | +--------------+ +---------------+ Given the topology above, the setup needed to get the basic VRF functions working would be Create the VRF devices and associate with a table ip link add vrf1 type vrf table 5 ip link add vrf2 type vrf table 6 Install the lookup rules that map table to VRF domain ip rule add pref 200 oif vrf1 lookup 5 ip rule add pref 200 iif vrf1 lookup 5 ip rule add pref 200 oif vrf2 lookup 6 ip rule add pref 200 iif vrf2 lookup 6 ip link set vrf1 up ip link set vrf2 up Enslave the routing member interfaces ip link set swp1 master vrf1 ip link set swp2 master vrf1 ip link set swp3 master vrf2 ip link set swp4 master vrf2 Connected and local routes are automatically moved from main and local tables to the VRF table. ping using VRF0 is simply ping -I vrf0 10.0.1.2 Design Highlights ================= If a device is enslaved to a VRF device (ie., associated with a VRF) then: 1. Rx path The master device index is used as the iif for all lookups. 2. Tx path Similarly, for Tx the VRF device oif is used in the flow to direct lookups to the table associated with the VRF via its rule. From there the FLOWI_FLAG_VRFSRC flag is used to indicate that the oif should not be used for FIB table lookups. 3. Connected and local routes On link up for a device, connected and local routes are added to the table associated with the VRF device, rather than the local and main tables. 4. Socket lookups Sockets operating in the VRF must be bound to the VRF device. As such socket lookups compare the VRF device index to sk_bound_dev_if. 5. Neighbor entries Neighbor entries are not impacted by the VRF device. Entries are associated with a particular interface; the VRF association is indirect via the interface-to-VRF device enslavement. Version 6 - addressed comments from DaveM - added patch to properly set oif in ip_send_unicast_reply. Needs to be set to VRF device for proper FIB lookup - added patch to handle IP fragments Version 5 - dropped patch regarding socket lookups; no longer needed + removed vrf helpers no longer needed after this patch is dropped - removed dev_open and close operations + no need to reset vrf data on an ifdown and creates problems if a slave is deleted while the vrf interface is down (Thanks, Nikolay) - cleanups for sparse warnings + make C=2 is now clean for vrf driver Version 4 - builds are clean with and without VRF device enabled (no, yes and module) - tightened the driver implementation + device add/delete, slave add/remove, and module unload are all clean - fixed RCU references + with RCU and lock debugging enabled changes are clean through the suite of tests - TX path uses custom dst, so patch refactoring rtable allocation is dropped along with the patch adding rt_nexthop helper - dropped the task patch that adds default bind to interface for sockets and the associated chvrf example command + the patches are a convenience for running unmodified code. They are not needed for the core functionality. Any application with support for SO_BINDTODEVICE works properly with this patch set. Version 3 - addressed comments from first 2 RFCs with the exception of the name Nicolas: We will do the name conversion once we agree on what the correct name should be (vrf, mrf or something else) - packets flow through the VRF device in both directions allowing the following: - tcpdump -i vrf<n> - tc rules on vrf device - netfilter rules on vrf device TO-DO ===== 1. IPv6 2. ipsec, xfrms - dst patch accepted into ipsec-next; will post VRF patch once merge happens 3. listen filter to allow 1 socket to work with multiple VRF devices - i.e., bind to VRF's a, b, c only or NOT VRFs e, f, g Eric B: I have ipsec working with VRFs implemented using the VRF driver, including the worst case scenario of complete duplication in the networking config. Thanks to Nikolay for his many, many code reviews whipping the device driver into shape, and bug-Fixes and ideas from Hannes, Roopa Prabhu, Jon Toppins, Jamal. ==================== Signed-off-by: -
David Ahern authored
This driver borrows heavily from IPvlan and teaming drivers. Routing domains (VRF-lite) are created by instantiating a VRF master device with an associated table and enslaving all routed interfaces that participate in the domain. As part of the enslavement, all connected routes for the enslaved devices are moved to the table associated with the VRF device. Outgoing sockets must bind to the VRF device to function. Standard FIB rules bind the VRF device to tables and regular fib rule processing is followed. Routed traffic through the box, is forwarded by using the VRF device as the IIF and following the IIF rule to a table that is mated with the VRF. Example: Create vrf 1: ip link add vrf1 type vrf table 5 ip rule add iif vrf1 table 5 ip rule add oif vrf1 table 5 ip route add table 5 prohibit default ip link set vrf1 up Add interface to vrf 1: ip link set eth1 master vrf1 Signed-off-by:Shrijeet Mukherjee <shm@cumulusnetworks.com> Signed-off-by:
-
David Ahern authored
Fragmentation cache uses information from the IP header to reassemble packets. That information can be duplicated across VRFs -- same source and destination addresses, protocol and id. Handle fragmentation with VRFs by adding the VRF device index to entries in the cache and the lookup arg. Signed-off-by:
-
David Ahern authored
If output device is not specified use VRF device if input device is enslaved. This is needed to ensure tcp acks and resets go out VRF device. Signed-off-by:
-
David Ahern authored
If a user passes in a table for new routes use that table for nexthop lookups. Specifically, this solves the case where a connected route does not exist in the main table, but only another table and then a subsequent route is added with a next hop using the connected route. ie., $ ip route ls default via 10.0.2.2 dev eth0 10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 169.254.0.0/16 dev eth0 scope link metric 1003 192.168.56.0/24 dev eth1 proto kernel scope link src 192.168.56.51 $ ip route ls table 10 1.1.1.0/24 dev eth2 scope link Without this patch adding a nexthop route fails: $ ip route add table 10 2.2.2.0/24 via 1.1.1.10 RTNETLINK answers: Network is unreachable With this patch the route is added successfully. Signed-off-by:
-
David Ahern authored
When a device associated with a VRF is brought up or down routes should be added to/removed from the table associated with the VRF. fib_magic defaults to using the main or local tables. Have it use the table with the device if there is one. A part of this is directing prefsrc validations to the correct table as well. Signed-off-by:
-
David Ahern authored
Currently inet_addr_type and inet_dev_addr_type expect local addresses to be in the local table. With the VRF device local routes for devices associated with a VRF will be in the table associated with the VRF. Provide an alternate inet_addr lookup to use a specific table rather than defaulting to the local table. inet_addr_type_dev_table keeps the same semantics as inet_addr_type but if the passed in device is enslaved to a VRF then the table for that VRF is used for the lookup. Signed-off-by:
-
David Ahern authored
Currently inet_addr_type and inet_dev_addr_type expect local addresses to be in the local table. With the VRF device local routes for devices associated with a VRF will be in the table associated with the VRF. Provide an alternate inet_addr lookup to use a specific table rather than defaulting to the local table. Signed-off-by:
-
David Ahern authored
For unconnected UDP sockets using a VRF device lookup source address based on VRF table. This allows the UDP header to be properly setup before showing up at the VRF device via the dst. Signed-off-by:
-
David Ahern authored
As with ingress use the index of VRF master device for route lookups on egress. However, the oif should only be used to direct the lookups to a specific table. Routes in the table are not based on the VRF device but rather interfaces that are part of the VRF so do not consider the oif for lookups within the table. The FLOWI_FLAG_VRFSRC is used to control this latter part. Signed-off-by:
-
David Ahern authored
On ingress use index of VRF master device for route lookups if real device is enslaved. Rules are expected to be installed for the VRF device to direct lookups to a specific table. Signed-off-by:
-
David Ahern authored
Add a VRF_MASTER flag for interfaces and helper functions for determining if a device is a VRF_MASTER. Add link attribute for passing VRF_TABLE id. Add vrf_ptr to netdevice. Add various macros for determining if a device is a VRF device, the index of the master VRF device and table associated with VRF device. Signed-off-by:
-
Andy Gospodarek authored
This is useful information to include in ipv6 netlink messages that report interface information. IFLA_OPERSTATE is already included in ipv4 messages, but missing for ipv6. This closes that gap. Signed-off-by:
Andy Gospodarek <gospo@cumulusnetworks.com> Signed-off-by:
-
Sasha Levin authored
Commit 10e4ea75 ("net: Fix race condition in store_rps_map") has moved the manipulation of the rps_needed jump label under a spinlock. Since changing the state of a jump label may sleep this is incorrect and causes warnings during runtime. Make rps_map_lock a mutex to allow sleeping under it. Fixes: 10e4ea75 ("net: Fix race condition in store_rps_map") Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Acked-by:
Tom Herbert <tom@herbertland.com> Signed-off-by:
-
David S. Miller authored
Vivien Didelot says: ==================== net: dsa: mv88e6xxx: add hardware VLAN support This patchset brings support to access hardware VLAN entries in DSA and mv88e6xxx, through switchdev VLAN objects. In the following example, ports swp[0-2] belong to bridge br0, and ports swp[3-4] belong to bridge br1. Here's an example of what can be achieved after this patchset: # bridge vlan add dev swp1 vid 100 master # bridge vlan add dev swp2 vid 100 master # bridge vlan add dev swp3 vid 100 master # bridge vlan add dev swp4 vid 100 master # bridge vlan del dev swp1 vid 100 master The above commands correctly programmed hardware VLAN 100 for port swp2, while ports swp3 and swp4 use software VLAN 100, as shown with: # bridge vlan port vlan ids swp0 None swp0 swp1 None swp1 swp2 100 swp2 100 swp3 100 swp3 swp4 100 swp4 br0 None br1 None Assuming that port 5 is the CPU port, the hardware VLAN table would contain the following data: VID FID SID 0 1 2 3 4 5 6 100 8 0 x x t x x t x Where 'x' means excluded, and 't' means tagged. Also, adding an FDB entry to VLAN 100 for port swp2 like this: # bridge fdb add 3c:97:0e:11:6e:30 dev swp2 vlan 100 Would result in the following example output: # bridge fdb # 01:00:5e:00:00:01 dev eth0 self permanent # 01:00:5e:00:00:01 dev eth1 self permanent # 00:50:d2:10:78:15 dev swp0 master br0 permanent # 00:50:d2:10:78:15 dev swp2 vlan 100 master br0 permanent # 3c:97:0e:11:6e:30 dev swp2 vlan 100 self static # 00:50:d2:10:78:15 dev swp3 master br1 permanent # 00:50:d2:10:78:15 dev swp3 vlan 100 master br1 permanent And the Address Translation Unit would contain: DB T/P Vec State Addr 008 Port 004 e 3c:97:0e:11:6e:30 ==================== Signed-off-by: -
Vivien Didelot authored
This commit changes the 802.1Q mode of each port from Disabled to Secure. This enables the VLAN support, by checking the VTU entries on ingress. Signed-off-by:
Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by:
-
Vivien Didelot authored
Implement port_pvid_set and port_vlan_add to add new entries in the VLAN hardware table, and join ports to them. The patch also implement the STU Get Next and Load Purge operations, since it is required to have a valid STU entry for at least all VLANs. Each VLAN has its own forwarding database, with FID num_ports+1 to 4095. Signed-off-by:
-
Vivien Didelot authored
Add support for the VTU Load Purge operation and implement the port_vlan_del driver function to remove a port from a VLAN entry, and delete the VLAN if the given port was its last member. Signed-off-by:
-
Vivien Didelot authored
Add an helper function to read the next valid VLAN entry for a given port. It is used in the VID to FID conversion function to retrieve the forwarding database assigned to a given VLAN port. Finally update the FDB getnext operation to iterate on the next valid port VLAN when the end of the current database is reached. Signed-off-by:
-
Vivien Didelot authored
Implement the port_pvid_get and vlan_getnext driver functions required to dump VLAN entries from the hardware, with the VTU Get Next operation. Some functions and structure will be shared with STU operations, since their table format are similar (e.g. STU data entries are accessible with the same registers as VTU entries, except with an offset of 2). Signed-off-by:
-
Vivien Didelot authored
Implement the VTU Flush operation (which also flushes the STU), so that warm boots won't preserved old entries. Signed-off-by:
-
Vivien Didelot authored
Add new functions in DSA drivers to access hardware VLAN entries through SWITCHDEV_OBJ_PORT_VLAN objects: - port_pvid_get() and vlan_getnext() to dump a VLAN - port_vlan_del() to exclude a port from a VLAN - port_pvid_set() and port_vlan_add() to join a port to a VLAN The DSA infrastructure will ensure that each VLAN of the given range does not already belong to another bridge. If it does, it will fallback to software VLAN and won't program the hardware. Signed-off-by:
-
Andy Gospodarek authored
Like the ipv4 patch with a similar title, this adds a sysctl to allow the user to change routing behavior based on whether or not the interface associated with the nexthop was an up or down link. The default setting preserves the current behavior, but anyone that enables it will notice that nexthops on down interfaces will no longer be selected: net.ipv6.conf.all.ignore_routes_with_linkdown = 0 net.ipv6.conf.default.ignore_routes_with_linkdown = 0 net.ipv6.conf.lo.ignore_routes_with_linkdown = 0 ... When the above sysctls are set, not only will link status be reported to userspace, but an indication that a nexthop is dead and will not be used is also reported. 1000::/8 via 7000::2 dev p7p1 metric 1024 dead linkdown pref medium 1000::/8 via 8000::2 dev p8p1 metric 1024 pref medium 7000::/8 dev p7p1 proto kernel metric 256 dead linkdown pref medium 8000::/8 dev p8p1 proto kernel metric 256 pref medium 9000::/8 via 8000::2 dev p8p1 metric 2048 pref medium 9000::/8 via 7000::2 dev p7p1 metric 1024 dead linkdown pref medium fe80::/64 dev p7p1 proto kernel metric 256 dead linkdown pref medium fe80::/64 dev p8p1 proto kernel metric 256 pref medium This also adds devconf support and notification when sysctl values change. v2: drop use of rt6i_nhflags since it is not needed right now Signed-off-by:
Dinesh Dutt <ddutt@cumulusnetworks.com> Signed-off-by:
-
Andy Gospodarek authored
Add support to track current link status of ipv6 nexthops to match recent changes that added support for ipv4 nexthops. This takes a simple approach to track linkdown status for next-hops and simply checks the dev for the dst entry and sets proper flags that to be used in the netlink message. v2: drop use of rt6i_nhflags since it is not needed right now Signed-off-by:
-
Hariprasad Shenai authored
Handle TRACE_PKT, stack can sniff them on the first port Add debubfs enrty to configure tracing for offload traffic like iWARP & iSCSI for debugging purpose. Signed-off-by:
Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by:
-
yalin wang authored
HWM_REVERSE() macro is unused, remove it. Signed-off-by:
yalin wang <yalin.wang2010@gmail.com> Signed-off-by:
-
Scott Feldman authored
Rocker driver tracks arp_tbl neighs to resolve IPv4 route nexthops. The driver uses NETEVENT_NEIGH_UPDATE for neigh adds and updates, but there is no event when the neigh is removed from the device (such as when the device goes admin down). This patches hooks ndo_neigh_destroy so the driver can know when a neigh is removed from the device. In response, the driver will purge the neigh entry from its internal tbl. I didn't find an in-tree users of ndo_neigh_destroy, so I'm not sure if this ndo is vestigial or if there are out-of-tree users. In any case, it does what I need here. An alternative design would be to generate NETEVENT_NEIGH_UPDATE event when neigh is being destroyed, setting state to NUD_NONE so driver knows neigh entry is dead. Signed-off-by:
Scott Feldman <sfeldma@gmail.com> Signed-off-by:
-
Scott Feldman authored
On sucessful probe, driver prints the switch ID. This patch changes the format of the printed ID to match what's used in sysfs phys_switch_id node. Signed-off-by:
-
- 13 Aug, 2015 10 commits
-
-
David S. Miller authored
Jeremy Linton says: ==================== Enable smsc911x for use with ACPI This set of patches enables the front Ethernet port on the ARM Juno development platform when used with an ACPI enabled kernel. These patches covert the of_property* calls in the driver to the DT/ACPI agnostic device_property* calls, and add the arm hardware id to the acpi_match_table. To support the above changes I copied a couple routines from of_net into the properties.c file, and modified them to be ACPI/DT agnostic. I'm not 100% sure this is the correct location for these functions. But I think they are required to avoid having a dozen different implementations scattered across assorted Ethernet adapters that are being enabled to use ACPI properties. ==================== Signed-off-by: -
Jeremy Linton authored
Add ACPI bindings for the smsc911x driver. Convert the DT specific calls to nonspecific device* calls, This allows the driver to work with both ACPI and DT configurations. Ethernet should now work when using ACPI on ARM Juno. Signed-off-by:
Jeremy Linton <jeremy.linton@arm.com> Reviewed-by:
Graeme Gregory <graeme.gregory@linaro.org> Signed-off-by:
-
Jeremy Linton authored
OF has some helper functions for parsing MAC and PHY settings. In cases where the platform is providing this information rather than the device itself, there needs to be similar functions for ACPI. These functions are slightly modified versions of the ones in of_net which can use information provided via DT or ACPI. Signed-off-by:
-
David S. Miller authored
Yuchung Cheng says: ==================== minor tail loss probe improvements This patch series enhance the tail loss probe (TLP) on some error conditions. When TLP fails to send a probe, it will no longer extend the RTO. When it fails to send a new packet because of receiver window limit, it'll try to retransmit the last packet. ==================== Signed-off-by: -
Yuchung Cheng authored
When TLP fails to send new packet because of receive window limit, it should fall back to retransmit the last packet instead. Signed-off-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
Nandita Dukkipati <nanditad@google.com> Signed-off-by:
-
Yuchung Cheng authored
If TLP was unable to send a probe, it extended the RTO to now + icsk_rto. But extending the RTO makes little sense if no TLP probe went out. With this commit, instead of extending the RTO we re-arm it relative to the transmit time of the write queue head. Signed-off-by:
-
David S. Miller authored
Mugunthan V N says: ==================== Add AM335x PG1.0 CPSW errata workaround With commit 870915fe ("drivers: net: cpsw: remove disable_irq/enable_irq as irq can be masked from cpsw itself"), CPSW on AM335x beagle bone white is broken as there is a errata for AM335x PG1.0. This patch series implements the workaround by disabling the interrupts from ARM IRQ controller for AM335x SoC in addition to the masking of interrupts in CPSW. ==================== Signed-off-by:
-
Mugunthan V N authored
CPSW driver has been updated with compatibles for enabling errata workarounds. So updating cpsw compatibles. Signed-off-by:
Mugunthan V N <mugunthanvnm@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Mugunthan V N authored
CPSW driver has been updated with compatibles for enabling errata workarounds. So updating cpsw compatibles. Signed-off-by:
-
Mugunthan V N authored
As per Am335x Errata [1] Advisory 1.0.9, The CPSW C0_TX_PEND and C0_RX_PEND interrupt outputs provide a single transmit interrupt that combines transmit channel interrupts TXPEND[7:0] and a single receive interrupt that combines receive channel interrupts RXPEND[7:0]. The TXPEND[0] and RXPEND[0] interrupt outputs are connected to the ARM Cortex-A8 interrupt controller (INTC) rather than the C0_TX_PEND and C0_RX_PEND interrupt outputs. So even though CPSW interrupt is cleared by writing appropriate values to EOI register the interrupt is not cleared in IRQ controller. So interrupt is still pending and CPU is struck in ISR, the workaround is to disable the interrupts in ARM irq controller. [1] http://www.ti.com/lit/er/sprz360f/sprz360f.pdfSigned-off-by:
-
