On 10/06/15 14:44, Scott Feldman wrote: > On Tue, Jun 9, 2015 at 5:12 PM, Florian Fainelli <f.faine...@gmail.com> wrote: > > >> I see the problem now, DSA does not implement a port_obj_add callback, >> so when net/ipv4/fib_trie.c::switchdev_fib_ipv4_add() gets to call >> switchdev_port_obj_add, we return -EOPNOTSUPP, and take the error path >> in fib_table_insert thus not inserting the route for this interface. > > Yup, that's the problem. > >> Now when I restart the DHCP client, we end-up inserting the default >> route which is correct, still figuring out what is different here, >> probably the deletion of the routes by the DHCP client script first is >> the different condition. > > After the first failure, ipv4.fib_offload_disabled is set, so the next > time switchdev_fib_ipv4_add() just returns 0 and the route is > installed. That explains the one-off behavior. > >> At any rate, since switchdev_fib_ipv4_add() returns something that make >> us take an error path in the fib_trie, something like this seems to fix >> it for me but I am not well versed enough into the IPv4 routing code to >> be 100% confident this is the right fix. Also, there are other callers >> of switchdev_port_obj_add() but a quick look seems to make them safe as >> they are only called for "offloading" capable hardware. > > Your fix looks good to me. The other users of > switchdev_port_obj_add() want to return -EOPNOTSUPP to user, so it's > just this one case for IPv4 fib insert/del where we'll want to treat > no support silently. Are you going to resend as patch for net-next, > or should I?
I would prefer if you submitted it since you explained how things are working and now everything makes sense. I will be happy to test it and provide the magic tags ;) -- Florian -- 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
