Re: [PATCH net v2] switchdev: don't abort hardware ipv4 fib offload on failure to program fib entry in hardware

[roopa <roopa@cumulusnetworks.com>]

On 5/18/15, 8:48 PM, David Miller wrote:
> From: John Fastabend <john.r.fastabend@intel.com>
> Date: Mon, 18 May 2015 17:21:29 -0700
>
>> So how about having an error strategy sysctl field that we can set
>> at provisioning time. I think this would align to Roopa's option (b).
>> This way we can default to "transparent" mode and the users where
>> this wont work can set the error mode. This way user land software
>> stacks that work today should continue to work in both modes.
> Alert: This is not a switch provisioning issue.
>
> You can frame it like that all day, and continue to talk about
> low power cpus or other things which are completely and utterly
> irrelevant.
>
> Stop looking at how some specific piece of hardware is configured,
> and think about what actually is asking the kernel to do stuff.
>
> That's because the real issue is _semantics_ and what a Linux machine
> is expected to do when you insert a route and valid reasons why a
> route insertion can fail.
>
> That is the _only_ issue.
>
> And that has to do with what semantics _applcations_ making these
> routing change requests expect.
>
> There is nothing else that matters.
>
> And since it is an issue of what semantics those application want and
> are able to handle, that is where the request of changed behavior
> belongs.
>
> If we added your suggested sysctl, we'd have to name it
> "sysctl_break_all_my_apps_please" because that is exactly what it
> would be doing. :-)
understood. This seems to lean towards option c) where app explicitly 
requests offload with RTNH_F_OFFLOAD for every route.

from where I see, with the limitations on these boxes,
this requires every app, every `ip route` cmd running on the box to 
explicitly specify offload when running on this hardware. In which case 
having a way to specify a global system policy seemed appropriate. Hence 
the sysctl suggestion.