From: Jiri Pirko <jiri@resnulli•us>
To: Roopa Prabhu <roopa@cumulusnetworks•com>
Cc: Ido Schimmel <idosch@idosch•org>,
Eric Dumazet <eric.dumazet@gmail•com>,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>,
"davem@davemloft•net" <davem@davemloft•net>,
Jiri Pirko <jiri@mellanox•com>, mlxsw <mlxsw@mellanox•com>,
David Ahern <dsa@cumulusnetworks•com>,
Nikolay Aleksandrov <nikolay@cumulusnetworks•com>,
Andy Gospodarek <andy@greyhouse•net>,
Vivien Didelot <vivien.didelot@savoirfairelinux•com>,
Andrew Lunn <andrew@lunn•ch>,
Florian Fainelli <f.fainelli@gmail•com>,
alexander.h.duyck@intel•com,
Alexey Kuznetsov <kuznet@ms2•inr.ac.ru>,
James Morris <jmorris@namei•org>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6•org>,
Patrick McHardy <kaber@trash•net>,
Ido Schimmel <idosch@mellanox•com>
Subject: Re: [PATCH net-next v2] ipv4: fib: Replay events when registering FIB notifier
Date: Wed, 2 Nov 2016 14:48:45 +0100 [thread overview]
Message-ID: <20161102134845.GI1713@nanopsycho.orion> (raw)
In-Reply-To: <CAJieiUjGHX0C7mG3Y8m2VZHPPq=Rz-2D8e_L9ZASi-bCs8nJJw@mail.gmail.com>
Wed, Nov 02, 2016 at 02:29:40PM CET, roopa@cumulusnetworks•com wrote:
>On Wed, Nov 2, 2016 at 12:20 AM, Jiri Pirko <jiri@resnulli•us> wrote:
>> Wed, Nov 02, 2016 at 03:13:42AM CET, roopa@cumulusnetworks•com wrote:
>>>
>[snip]
>
>>>I understand..but, if you are adding some core infrastructure for switchdev ..it cannot be
>>>based on the number of simple use-cases or data you have today.
>>>
>>>I won't be surprised if tomorrow other switch drivers have a case where they need to
>>>reset the hw routing table state and reprogram all routes again. Re-registering the notifier to just
>>>get the routing state of the kernel will not scale. For the long term, since the driver does not maintain a cache,
>>
>> Driver (mlxsw, rocker) maintain a cache. So I'm not sure why you say
>> otherwise.
>>
>>
>>>a pull api with efficient use of rtnl will be useful for other such cases as well.
>>
>> How do you imagine this "pull API" should look like?
>
>
>Just like you already have added fib notifiers to parallel fib netlink
>notifications, the pull API is a parallel to 'netlink dump'.
>Is my imagination too wild ? :)
Perhaps I'm slow, but I don't understand what you mean.
>
>
>>
>>
>>>
>>>
>>>If you don't want to get to the complexity of a new api right away because of the
>>>simple case of management interface routes you have, Can your driver register the notifier early ?
>>>(I am sure you have probably already thought about this)
>>
>> Register early? What it would resolve? I must be missing something. We
>> register as early as possible. But the thing is, we cannot register
>> in a past. And that is what this patch resolves.
>
>sure, you must be having a valid problem then. I was just curious why
>your driver is not up and initialized before any of the addresses or
>routes get configured in the system (even on a management port). Ours
If you unload the module and load it again for example. This is a valid
usecase.
>does. But i agree there can be races and you cannot always guarantee
>(I was just responding to ido's comment about adding complexity for a
>small problem he has to solve for management routes). Our driver does
>a pull before it starts. This helps when we want to reset the hardware
>routing table state too.
Can you point me to you driver in the tree? I would like to see how you
do "the pull".
>
>
>But, my point was, when you are defining an API, you cannot quantify
>the 'past' to be just the very 'close past' or 'the past is just the
>management routes that were added' . Tomorrow the 'past' can be the
>full routing table if you need to reset the hardware state.
Sure.
next prev parent reply other threads:[~2016-11-02 13:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-31 21:13 [PATCH net-next v2] ipv4: fib: Replay events when registering FIB notifier idosch
2016-10-31 21:24 ` Eric Dumazet
2016-10-31 22:57 ` Ido Schimmel
2016-11-01 14:19 ` Eric Dumazet
2016-11-01 15:14 ` Roopa Prabhu
2016-11-01 15:36 ` David Miller
2016-11-02 7:35 ` Jiri Pirko
2016-11-02 15:26 ` David Miller
2016-11-01 17:03 ` Ido Schimmel
2016-11-02 2:13 ` Roopa Prabhu
2016-11-02 7:20 ` Jiri Pirko
2016-11-02 13:29 ` Roopa Prabhu
2016-11-02 13:44 ` Ido Schimmel
2016-11-02 13:48 ` Jiri Pirko [this message]
2016-11-02 14:35 ` Roopa Prabhu
2016-11-02 14:43 ` Jiri Pirko
2016-11-01 15:44 ` Ido Schimmel
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=20161102134845.GI1713@nanopsycho.orion \
--to=jiri@resnulli$(echo .)us \
--cc=alexander.h.duyck@intel$(echo .)com \
--cc=andrew@lunn$(echo .)ch \
--cc=andy@greyhouse$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=dsa@cumulusnetworks$(echo .)com \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=f.fainelli@gmail$(echo .)com \
--cc=idosch@idosch$(echo .)org \
--cc=idosch@mellanox$(echo .)com \
--cc=jiri@mellanox$(echo .)com \
--cc=jmorris@namei$(echo .)org \
--cc=kaber@trash$(echo .)net \
--cc=kuznet@ms2$(echo .)inr.ac.ru \
--cc=mlxsw@mellanox$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=nikolay@cumulusnetworks$(echo .)com \
--cc=roopa@cumulusnetworks$(echo .)com \
--cc=vivien.didelot@savoirfairelinux$(echo .)com \
--cc=yoshfuji@linux-ipv6$(echo .)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