netdev - Re: [PATCH net-next] net: change fib behavior based on interface link status

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]

Date:	Wed, 3 Jun 2015 11:12:11 -0700
From:	Scott Feldman <sfeldma@...il.com>
To:	Andy Gospodarek <gospo@...ulusnetworks.com>
Cc:	Netdev <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>, ddutt@...ulusnetworks.com
Subject: Re: [PATCH net-next] net: change fib behavior based on interface link status

On Wed, Jun 3, 2015 at 10:57 AM, Andy Gospodarek
<gospo@...ulusnetworks.com> wrote:
> On Wed, Jun 03, 2015 at 10:40:26AM -0700, Scott Feldman wrote:
>> On Wed, Jun 3, 2015 at 8:12 AM, Andy Gospodarek
>> <gospo@...ulusnetworks.com> wrote:
>> > On Tue, Jun 02, 2015 at 10:03:23PM -0700, Scott Feldman wrote:
>> >> On Tue, Jun 2, 2015 at 8:07 PM, Andy Gospodarek
>> >> <gospo@...ulusnetworks.com> wrote:
>> >> > This patch adds the ability to have the Linux kernel track whether or
>> >> > not a particular route should be used based on the link-status of the
>> >> > interface associated with the next-hop.
>> >> >
>> >> > Before this patch any link-failure on an interface that was serving as a
>> >> > gateway for some systems could result in those systems being isolated
>> >> > from the rest of the network as the stack would continue to attempt to
>> >> > send frames out of an interface that is actually linked-down.  When the
>> >> > kernel is responsible for all forwarding, it should also be responsible
>> >> > for taking action when the traffic can no longer be forwarded -- there
>> >> > is no real need to outsource link-monitoring to userspace anymore.
>> >>
>> >> Hi Andy, how does this work for the hardware offload case?  I'm not
>> >> seeing how hardware gets updated when the software route is updated.
>> >> Seems hardware isn't updated and would send frames out the downed nh
>> >> interface.
>> >
>> > Scott, you are correct that this does not currently address the hardware
>> > offload case.  If one wanted offloaded hardware to reflect this change,
>> > then there needs to be either:
>> >
>> > - The ability to communicate the flag changes down to offload devices in
>> >   the event that they want some action to take place
>> >   switchdev_fib_ipv4_modify(), maybe? (Not to derail this convo too much
>> >   but it will soon be time to consider what to do at the switchdev layer
>> >   when route flags are modified like when the RTNH_F_OFFLOAD flag is
>> >   removed by the user if they feel the route does not need to be
>> >   offloaded for any reason.)
>>
>> Switchdev_fib_ipv4_add() can handle adds and mods, so you can use
>> that.  Any place you're sending notification of route change, hook
>> switchdev so the offload device is updated with the route change.
> I should know better than to ask this, but does just the rocker
> implementation presume this operation is an add and modify or was this
> the implementation from the beginning.  (Forgive me for not remembering
> earlier discussion on this.)

The intent was add/mod, but looks like I need to update some
documentation; I'll do that.  See fib_trie.c:fib_table_insert case for
NLM_F_REPLACE...that's a mod case.
--
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