From: roopa <roopa@cumulusnetworks•com>
To: David Miller <davem@davemloft•net>
Cc: 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:57:16 -0700 [thread overview]
Message-ID: <555AD0BC.7000608@cumulusnetworks.com> (raw)
In-Reply-To: <20150518.161916.2132217836491222672.davem@davemloft.net>
On 5/18/15, 1:19 PM, David Miller wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks•com>
> Date: Sun, 17 May 2015 16:42:05 -0700
>
>> On most systems where you can offload routes to hardware,
>> doing routing in software is not an option (the cpu limitations
>> make routing impossible in software).
> You absolutely do not get to determine this policy, none of us
> do.
>
> What matters is that by default the damn switch device being there
> is %100 transparent to the user.
>
> And the way to achieve that default is to do software routes as
> a fallback.
>
> I am not going to entertain changes of this nature which fail
> route loading by default just because we've exceeded a device's
> HW capacity to offload.
>
> I thought I was _really_ clear about this at netdev 0.1
sorry if i missed you emphasize this.
Current fib hw offload code aborts hw offload on the first hw offload
failure and moves all routes to software and before 4.1 goes out I was
trying to revisit this because the existing defaults will not work for
most devices. To that effect, i started with an RFC patch to get some
current thoughts and hence this patch.
I will follow up on the other options mentioned in the comment.
next prev parent reply other threads:[~2015-05-19 5:57 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
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 [this message]
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=555AD0BC.7000608@cumulusnetworks.com \
--to=roopa@cumulusnetworks$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=jiri@resnulli$(echo .)us \
--cc=john.fastabend@gmail$(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