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? -- 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
