From: "Duyck, Alexander H" <alexander.h.duyck@intel•com>
To: "jiri@resnulli•us" <jiri@resnulli•us>
Cc: "netdev@vger•kernel.org" <netdev@vger•kernel.org>,
"jiri@mellanox•com" <jiri@mellanox•com>,
"davem@davemloft•net" <davem@davemloft•net>,
"edumazet@google•com" <edumazet@google•com>
Subject: Re: [net PATCH 1/2] ipv4: Restore fib_trie_flush_external function and fix call ordering
Date: Tue, 15 Nov 2016 21:11:50 +0000 [thread overview]
Message-ID: <1479244302.681.129.camel@intel.com> (raw)
In-Reply-To: <20161115210754.GE1783@nanopsycho.orion>
On Tue, 2016-11-15 at 22:07 +0100, Jiri Pirko wrote:
> Tue, Nov 15, 2016 at 10:01:03PM CET, alexander.h.duyck@intel•com wrote:
> >
> > On Tue, 2016-11-15 at 21:52 +0100, Jiri Pirko wrote:
> > >
> > > Tue, Nov 15, 2016 at 09:49:02PM CET, alexander.h.duyck@intel•com wrote:
> > > >
> > > >
> > > > On Tue, 2016-11-15 at 21:31 +0100, Jiri Pirko wrote:
> > > > >
> > > > >
> > > > > Tue, Nov 15, 2016 at 09:29:09PM CET, alexander.h.duyck@intel•com wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, 2016-11-15 at 20:51 +0100, Jiri Pirko wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Tue, Nov 15, 2016 at 11:46:06AM CET, alexander.h.duyck@intel•com wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > The patch that removed the FIB offload infrastructure was a bit too
> > > > > > > > aggressive and also removed code needed to clean up us splitting the table
> > > > > > > > if additional rules were added. Specifically the function
> > > > > > > > fib_trie_flush_external was called at the end of a new rule being added to
> > > > > > > > flush the foreign trie entries from the main trie.
> > > > > > > >
> > > > > > > > I updated the code so that we only call fib_trie_flush_external on the main
> > > > > > > > table so that we flush the entries for local from main. This way we don't
> > > > > > > > call it for every rule change which is what was happening previously.
> > > > > > >
> > > > > > > Well, the function was introduced by:
> > > > > > >
> > > > > > > commit 104616e74e0b464d449fdd2ee2f547d2fad71610
> > > > > > > Author: Scott Feldman <sfeldma@gmail•com>
> > > > > > > Date: Thu Mar 5 21:21:16 2015 -0800
> > > > > > >
> > > > > > > switchdev: don't support custom ip rules, for now
> > > > > > >
> > > > > > > Keep switchdev FIB offload model simple for now and don't allow custom ip
> > > > > > > rules.
> > > > > > >
> > > > > > > Why this was not needed before? What changed in between:
> > > > > > > 104616e74e0b464d449fdd2ee2f547d2fad71610 ("switchdev: don't support custom ip rules, for now")
> > > > > > > and
> > > > > > > 347e3b28c1ba2 ("switchdev: remove FIB offload infrastructure")
> > > > > >
> > > > > > We collapsed the two tables into one in commit 0ddcf43d5d4a ("ipv4: FIB
> > > > > > Local/MAIN table collapse") which was submitted the next day. Scott
> > > > > > and I were working on things at the same time and the
> > > > > > fib_table_flush_external function was something we had worked out that
> > > > > > would allow him to take care of his use case and me to take care of
> > > > > > cleaning up the tables after unmerging.
> > > > >
> > > > > Okay. But please name the fuction differently, as it does not flush
> > > > > external. Thanks!
> > > >
> > > > You and I have different meanings for "external".
> > > >
> > > > In my case I am flushing entries that belong to a foreign "external"
> > > > table from the table specified. So by "external" I am referring to
> > > > entries that don't actually live in main, but actually reside in local.
> > > > If you take a look at fib_table_flush that gets rid of all entries,
> > > > fib_table_flush_external simply clears the foreign ones.
> > > >
> > > > Also I'd rather maintain naming since it makes it easier if we need to
> > > > backport fixes.
> > > >
> > > > Finally, the flag RTNH_F_EXTERNAL was renamed over a year ago in commit
> > > > 36583eb54d46c ("rename RTNH_F_EXTERNAL to RTNH_F_OFFLOAD") so there
> > > > isn't too much likelihood of this being confused for something that
> > > > handles offloaded entries. If you take a look in net/ipv4/* after your
> > > > patch there isn't actually anything that references the word external
> > > > so the likelihood for any confusion is extremely low.
> > >
> > > Okay. But if you can, please put a comment to this function in order to
> > > prevent future confusion. Thanks!
> >
> > I'm not sure there is much left to confuse at this point. The function
> > has gone from multi-purpose to single purpose so anyone that is messing
> > with this should only be doing so if they are messing with the unmerge
> > functionality.
> >
> > If anything it would be more confusing to refer to functionality that
> > this function doesn't support in the comments. All this function does
> > is flush foreign/external objects from the tree.
> >
> > I'm willing to review a patch if you have a suggestion for a comment
> > that would work. I just want to avoid confusing people by referring to
> > code and functionality that is no longer relevent.
>
> Perhaps I was the only one confused. Fair enough. Thanks Alex.
No, I would agree the original sharing of the function was a bit
confusing, and that was mostly due to the timeline of things with both
Scott and I rebasing our code on top of each other.
With you removing the FIB offload pieces it simplified it quite a bit
so with this fix we should be back to 100% functionality with the code
much more simplified.
Thanks.
- Alex
next prev parent reply other threads:[~2016-11-15 21:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-15 10:46 [net PATCH 0/2] ipv4: Fix memory leaks and reference issues in fib Alexander Duyck
2016-11-15 10:46 ` [net PATCH 1/2] ipv4: Restore fib_trie_flush_external function and fix call ordering Alexander Duyck
2016-11-15 18:30 ` Eric Dumazet
2016-11-15 19:51 ` Jiri Pirko
2016-11-15 20:29 ` Duyck, Alexander H
2016-11-15 20:31 ` Jiri Pirko
2016-11-15 20:49 ` Duyck, Alexander H
2016-11-15 20:52 ` Jiri Pirko
2016-11-15 21:01 ` Duyck, Alexander H
2016-11-15 21:07 ` Jiri Pirko
2016-11-15 21:11 ` Duyck, Alexander H [this message]
2016-11-15 10:46 ` [net PATCH 2/2] ipv4: Fix memory leak in exception case for splitting tries Alexander Duyck
2016-11-15 18:24 ` Eric Dumazet
2016-11-16 18:25 ` [net PATCH 0/2] ipv4: Fix memory leaks and reference issues in fib David Miller
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=1479244302.681.129.camel@intel.com \
--to=alexander.h.duyck@intel$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=edumazet@google$(echo .)com \
--cc=jiri@mellanox$(echo .)com \
--cc=jiri@resnulli$(echo .)us \
--cc=netdev@vger$(echo .)kernel.org \
/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