From: roopa <roopa@cumulusnetworks•com>
To: Jiri Pirko <jiri@resnulli•us>
Cc: David Miller <davem@davemloft•net>,
sfeldma@gmail•com, john.fastabend@gmail•com,
netdev@vger•kernel.org, andy@greyhouse•net
Subject: Re: [PATCH net v2] switchdev: don't abort hardware ipv4 fib offload on failure to program fib entry in hardware
Date: Thu, 28 May 2015 22:31:05 -0700 [thread overview]
Message-ID: <5567F999.5080704@cumulusnetworks.com> (raw)
In-Reply-To: <20150528094244.GA19629@nanopsycho.orion>
On 5/28/15, 2:42 AM, Jiri Pirko wrote:
> Mon, May 18, 2015 at 10:19:16PM CEST, davem@davemloft•net 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
> I certainly agree that by default, transparency 1:1 sw:hw mapping is
> what we need for fib. The current code is a good start!
>
> I see couple of issues regarding switchdev_fib_ipv4_abort:
> 1) If user adds and entry, switchdev_fib_ipv4_add fails, abort is
> executed -> and, error returned. I would expect that route entry should
> be added in this case. The next attempt of adding the same entry will
> be successful.
> The current behaviour breaks the transparency you are reffering to.
> 2) When switchdev_fib_ipv4_abort happens to be executed, the offload is
> disabled for good (until reboot). That is certainly not nice, alhough
> I understand that is the easiest solution for now.
+1
>
> I believe that we all agree that the 1:1 transparency, although it is a
> default, may not be optimal for real-life usage. HW resources are
> limited and user does not know them. The danger of hitting _abort and
> screwing-up the whole system is huge, unacceptable.
>
> So here, there are couple of more or less simple things that I suggest to
> do in order to move a little bit forward:
> 1) Introduce system-wide option to switch _abort to just plain fail.
> When HW does not have capacity, do not flush and fallback to sw, but
> rather just fail to add the entry. This would not break anything.
> Userspace has to be prepared that entry add could fail.
This was my option b)
> 2) Introduce a way to propagate resources to userspace. Driver knows about
> resources used/available/potentially_available. Switchdev infra could
> be extended in order to propagate the info to the user.
This could be an option as well. On our switches we do provide a utility
to query
similar hardware resources/stats. We were planning to propose a netlink
based query/get api for the switchdev case.
> 3) Introduce couple of flags for entry add that would alter the default
> behaviour. Something like:
> NLM_F_SKIP_KERNEL
> NLM_F_SKIP_OFFLOAD
+1, we have discussed similar flags in many other switchdev discussions
as well.
and this is also along the lines of option c) that i was proposing as
possible alternatives with this patch.
> Again, this does not break the current users. On the other hand, this
> gives new users a leverage to instruct kernel where the entry should
> be added to (or not added to).
>
> Any thoughts? Objections?
>
>
+1 to all what you said.
thanks
next prev parent reply other threads:[~2015-05-29 5:31 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
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 [this message]
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=5567F999.5080704@cumulusnetworks.com \
--to=roopa@cumulusnetworks$(echo .)com \
--cc=andy@greyhouse$(echo .)net \
--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