On Wed, Nov 2, 2016 at 12:20 AM, Jiri Pirko <j...@resnulli.us> wrote: > Wed, Nov 02, 2016 at 03:13:42AM CET, ro...@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 ? :) > > >> >> >>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 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. 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.
