On Sat, Aug 26, 2017 at 10:04 AM, Ido Schimmel <ido...@idosch.org> wrote: > On Fri, Aug 25, 2017 at 01:26:07PM -0700, David Ahern wrote: >> Jiri / Ido: >> >> [snip] > > Regarding the silent abort, that's intentional. You can look at the same > code in v4.9 - when the chain was still blocking - and you'll see that > we didn't propagate the error even then. This was discussed in the past > and the conclusion was that user doesn't expect to operation to fail. If > hardware resources are exceeded, we let the kernel take care of the > forwarding instead.
History here is that the initial fib offload hooks were added during rocker days. subsequently we have had many discussions (on offload policies) to see if we can remove that check and report the error back to the user (routing daemon in this case) since the cpu kernel cannot handle 100G or more traffic on such platforms. Basically the cpu kernel cannot take care of forwarding for such platforms. I believe this came up during the last switchdev BOF as well. The current silent abort is in there because kernel needs to maintain its semantics for hardware offload. Which is a valid position but we will need to find a way to make it work for switch platforms. IIUC, the only place where switchdev offload returns error to the user is 'bridge and bond membership offload' I know fib and bridge fdb offload don't propagate errors to the user (maybe they used to before moving to notifiers ?. need to check history on this). Are tc hardware offload errors propagated to the user ? It is a bit inconsistent today, some errors are propagated to the user and some are not.
