On Wed, Jun 3, 2015 at 10:57 AM, Andy Gospodarek <go...@cumulusnetworks.com> wrote: > On Wed, Jun 03, 2015 at 10:40:26AM -0700, Scott Feldman wrote: >> On Wed, Jun 3, 2015 at 8:12 AM, Andy Gospodarek >> <go...@cumulusnetworks.com> wrote: >> > On Tue, Jun 02, 2015 at 10:03:23PM -0700, Scott Feldman wrote: >> >> On Tue, Jun 2, 2015 at 8:07 PM, Andy Gospodarek >> >> <go...@cumulusnetworks.com> wrote: >> >> > This patch adds the ability to have the Linux kernel track whether or >> >> > not a particular route should be used based on the link-status of the >> >> > interface associated with the next-hop. >> >> > >> >> > Before this patch any link-failure on an interface that was serving as a >> >> > gateway for some systems could result in those systems being isolated >> >> > from the rest of the network as the stack would continue to attempt to >> >> > send frames out of an interface that is actually linked-down. When the >> >> > kernel is responsible for all forwarding, it should also be responsible >> >> > for taking action when the traffic can no longer be forwarded -- there >> >> > is no real need to outsource link-monitoring to userspace anymore. >> >> >> >> Hi Andy, how does this work for the hardware offload case? I'm not >> >> seeing how hardware gets updated when the software route is updated. >> >> Seems hardware isn't updated and would send frames out the downed nh >> >> interface. >> > >> > Scott, you are correct that this does not currently address the hardware >> > offload case. If one wanted offloaded hardware to reflect this change, >> > then there needs to be either: >> > >> > - The ability to communicate the flag changes down to offload devices in >> > the event that they want some action to take place >> > switchdev_fib_ipv4_modify(), maybe? (Not to derail this convo too much >> > but it will soon be time to consider what to do at the switchdev layer >> > when route flags are modified like when the RTNH_F_OFFLOAD flag is >> > removed by the user if they feel the route does not need to be >> > offloaded for any reason.) >> >> Switchdev_fib_ipv4_add() can handle adds and mods, so you can use >> that. Any place you're sending notification of route change, hook >> switchdev so the offload device is updated with the route change. > I should know better than to ask this, but does just the rocker > implementation presume this operation is an add and modify or was this > the implementation from the beginning. (Forgive me for not remembering > earlier discussion on this.)
The intent was add/mod, but looks like I need to update some documentation; I'll do that. See fib_trie.c:fib_table_insert case for NLM_F_REPLACE...that's a mod case. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
