From: roopa <roopa@cumulusnetworks•com>
To: David Miller <davem@davemloft•net>
Cc: john.r.fastabend@intel•com, sfeldma@gmail•com,
john.fastabend@gmail•com, jiri@resnulli•us,
netdev@vger•kernel.org
Subject: Re: [PATCH net v2] switchdev: don't abort hardware ipv4 fib offload on failure to program fib entry in hardware
Date: Mon, 18 May 2015 22:58:54 -0700 [thread overview]
Message-ID: <555AD11E.5040709@cumulusnetworks.com> (raw)
In-Reply-To: <20150518.234839.995695850653714769.davem@davemloft.net>
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.
next prev parent reply other threads:[~2015-05-19 5:58 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-17 23:42 [PATCH net v2] switchdev: don't abort hardware ipv4 fib offload on failure to program fib entry in hardware Roopa Prabhu
2015-05-18 5:11 ` Scott Feldman
2015-05-18 20:19 ` David Miller
2015-05-19 0:21 ` John Fastabend
2015-05-19 3:48 ` David Miller
2015-05-19 5:58 ` roopa [this message]
2015-05-19 16:34 ` David Miller
2015-05-19 17:01 ` Jiri Pirko
2015-05-19 19:47 ` Andy Gospodarek
2015-05-19 20:28 ` David Miller
2015-05-20 14:37 ` Andy Gospodarek
2015-05-21 5:46 ` Scott Feldman
2015-05-21 15:37 ` roopa
2015-05-29 7:50 ` Jiri Pirko
2015-05-29 15:39 ` Scott Feldman
2015-05-30 9:00 ` Jiri Pirko
2015-05-31 4:19 ` John Fastabend
2015-05-31 6:34 ` Scott Feldman
2015-05-31 7:34 ` Scott Feldman
2015-05-19 5:57 ` roopa
2015-05-28 9:42 ` Jiri Pirko
2015-05-28 15:35 ` John Fastabend
2015-05-29 7:42 ` Jiri Pirko
2015-05-28 15:40 ` Scott Feldman
2015-05-28 16:10 ` John Fastabend
2015-05-29 5:37 ` roopa
2015-05-28 22:35 ` Andy Gospodarek
2015-05-29 5:51 ` roopa
2015-05-29 7:50 ` Jiri Pirko
2015-05-29 5:31 ` roopa
2015-05-29 15:12 ` Scott Feldman
2015-05-29 15:37 ` Jiri Pirko
-- strict thread matches above, loose matches on Subject: below --
2015-05-17 3:46 Roopa Prabhu
2015-05-17 23:41 ` roopa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=555AD11E.5040709@cumulusnetworks.com \
--to=roopa@cumulusnetworks$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=jiri@resnulli$(echo .)us \
--cc=john.fastabend@gmail$(echo .)com \
--cc=john.r.fastabend@intel$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=sfeldma@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox