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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAE4R7bDSbVo7ryzHktLWtA07RswT929bhWpYwpLZUkv1eQB1tw@mail.gmail.com>
Date:	Fri, 29 May 2015 08:39:46 -0700
From:	Scott Feldman <sfeldma@...il.com>
To:	Jiri Pirko <jiri@...nulli.us>
Cc:	David Miller <davem@...emloft.net>,
	Andy Gospodarek <gospo@...ulusnetworks.com>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	"Fastabend, John R" <john.r.fastabend@...el.com>,
	john fastabend <john.fastabend@...il.com>,
	Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net v2] switchdev: don't abort hardware ipv4 fib offload
 on failure to program fib entry in hardware

On Fri, May 29, 2015 at 12:50 AM, Jiri Pirko <jiri@...nulli.us> wrote:
> Thu, May 21, 2015 at 07:46:54AM CEST, sfeldma@...il.com wrote:
>>On Tue, May 19, 2015 at 1:28 PM, David Miller <davem@...emloft.net> wrote:
>>> From: Andy Gospodarek <gospo@...ulusnetworks.com>
>>> Date: Tue, 19 May 2015 15:47:32 -0400
>>>
>>>> Are you actually saying that if users complain loudly enough about
>>>> the current behavior (not the change Roopa has proposed) that you
>>>> would be open to considering a change the current behavior?
>>>
>>> I am saying that we have a contract with users not to break existing
>>> behavior.  Full stop.
>>
>>After rehearing David's argument, we should probably explore option d)
>>which is a refinement on the fib_offload_disable mechanism we have
>>today.  fib_offload_disable is global for all routes.  Once we hit a
>>HW install problem, the global flag is set and all routes fallback to
>>SW.  We did this because we can't allow the failed route to exist in
>>SW and not in HW because it could mess up LPM searches (HW could hit
>>on a lesser prefix even when SW has the true LPM, because HW gets
>>first shot at match).  The refinement on fib_offload_disable is this:
>>make it per-related-prefix rather than global, and on a HW install
>>problem, set the flag for the related-prefix and uninstall only those
>>routes from HW.  Related-prefix (is there a correct term for this?)
>>are routes to the same dst addr but with different prefix lengths.  I
>>haven't parsed the fib_trie structure to see how routes are organized,
>>but I suspect since it's optimized for lookup the related-prefix
>>tracking is already there and we can build on that.
>
> This looks interesting. However, I'm not sure that it is acceptable for
> user to experience this hw evict of "random entries". User knows what
> entries are essential to have in hw. With your solution, I can see no way
> user can actually say what should be offloaded or not. Kernel just
> automagically decides.

The default eviction policy could be based on RTA_PRIORITY: evict
lower priority routes first.  It would be up to the device driver to
decide between two routes of same priority.

To help device driver make the decision, we could have eviction policy options:

    Priority-base (default)
    Prefer IPv6 over IPv4
    Prefer IPv4 over IPv6
    Prefer single path over multipath
    Prefer longer prefix lengths over shorter
    Optimize for resource utilization

These are portable across different switches.   They're in terms a
user understands.  It's up to the device driver which truly
understands the device constraints to translates the user's eviction
policy choices into something that makes sense to that device.

-scott
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html