From: Alexander Duyck <alexander.duyck@gmail.com>
To: roopa <roopa@cumulusnetworks.com>, Scott Feldman <sfeldma@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>, Netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH net] ipv4: include NLM_F_APPEND flag in append route notifications
Date: Wed, 17 Jun 2015 08:35:29 -0700 [thread overview]
Message-ID: <558193C1.70001@gmail.com> (raw)
In-Reply-To: <5581893E.3070609@cumulusnetworks.com>
On 06/17/2015 07:50 AM, roopa wrote:
> On 6/17/15, 12:50 AM, Scott Feldman wrote:
>> On Tue, Jun 16, 2015 at 9:11 AM, Roopa Prabhu
>> <roopa@cumulusnetworks.com> wrote:
>>
>> [snip]
>>
>>> @@ -1203,6 +1204,8 @@ int fib_table_insert(struct fib_table *tb,
>>> struct fib_config *cfg)
>>>
>>> if (!(cfg->fc_nlflags & NLM_F_APPEND))
>>> fa = fa_first;
>>> + else
>>> + nlflags |= NLM_F_APPEND;
>>> }
>> The if and else parts above don't seem logically related.
> I have it at this place because here is where the decision to append
> really happens.
>> Maybe you
>> could initialize nlflags as:
>>
>> unsigned int nlflags = cfg->fc_nlflags &
>> (NLM_F_REPLACE|NLM_F_APPEND);
>>
>> And then pass rtmsg_fib(..., nlflags) to avoid the flag test/set?
> nlflags should only contain NLM_F_REPLACE and NLM_F_APPEND if a replace or
> append really took place. Hence the check and setting of nlflags is at
> the place where that
> decision is made.
>
> I had tried this patch a couple of other ways.... Do you think the below
> would be less confusing ?
>
> thanks.
>
>
>
> diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
> index 3c699c4..9bfa3d8 100644
> --- a/net/ipv4/fib_trie.c
> +++ b/net/ipv4/fib_trie.c
> @@ -1082,6 +1082,7 @@ int fib_table_insert(struct fib_table *tb, struct
> fib_config *cfg)
> struct trie *t = (struct trie *)tb->tb_data;
> struct fib_alias *fa, *new_fa;
> struct key_vector *l, *tp;
> + unsigned int nlflags = 0;
> struct fib_info *fi;
> u8 plen = cfg->fc_dst_len;
> u8 slen = KEYLENGTH - plen;
> @@ -1189,8 +1190,9 @@ int fib_table_insert(struct fib_table *tb, struct
> fib_config *cfg)
> fib_release_info(fi_drop);
> if (state & FA_S_ACCESSED)
> rt_cache_flush(cfg->fc_nlinfo.nl_net);
> + nlflags |= NLM_F_REPLACE;
> rtmsg_fib(RTM_NEWROUTE, htonl(key), new_fa, plen,
> - tb->tb_id, &cfg->fc_nlinfo, NLM_F_REPLACE);
> + tb->tb_id, &cfg->fc_nlinfo, nlflags);
>
> goto succeeded;
>
Why even bother modifying this part? Is this actually needed at all,
are there some other flags you plan to drop into nlflags as well that
would be passed as a part of this message?
> @@ -1201,7 +1203,9 @@ int fib_table_insert(struct fib_table *tb, struct
> fib_config *cfg)
> if (fa_match)
> goto out;
>
> - if (!(cfg->fc_nlflags & NLM_F_APPEND))
> + if (cfg->fc_nlflags & NLM_F_APPEND)
> + nlflags |= NLM_F_APPEND;
> + else
> fa = fa_first;
> }
> err = -ENOENT;
I'm not sure I see the point of using the |=. Why not just use a = and
save yourself an instruction or two since you don't really need the OR
operator in this case.
> @@ -1238,7 +1242,7 @@ int fib_table_insert(struct fib_table *tb, struct
> fib_config *cfg)
>
> rt_cache_flush(cfg->fc_nlinfo.nl_net);
> rtmsg_fib(RTM_NEWROUTE, htonl(key), new_fa, plen, new_fa->tb_id,
> - &cfg->fc_nlinfo, 0);
> + &cfg->fc_nlinfo, nlflags);
> succeeded:
> return 0;
>
>
next prev parent reply other threads:[~2015-06-17 15:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-16 16:11 [PATCH net] ipv4: include NLM_F_APPEND flag in append route notifications Roopa Prabhu
2015-06-16 16:14 ` roopa
2015-06-17 7:50 ` Scott Feldman
2015-06-17 14:50 ` roopa
2015-06-17 15:35 ` Alexander Duyck [this message]
2015-06-17 16:20 ` roopa
2015-06-17 17:31 ` Alexander Duyck
2015-06-17 18:07 ` 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=558193C1.70001@gmail.com \
--to=alexander.duyck@gmail.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=roopa@cumulusnetworks.com \
--cc=sfeldma@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.