Mon, Sep 19, 2016 at 01:16:17AM CEST, wrote:
>On 9/18/16, 1:00 PM, Florian Fainelli wrote:
>> Le 06/09/2016 à 05:01, Jiri Pirko a écrit :
>>> From: Jiri Pirko <>
>>> This is RFC, unfinished. I came across some issues in the process so I would
>>> like to share those and restart the fib offload discussion in order to make 
>>> it
>>> really usable.
>>> So the goal of this patchset is to allow driver to propagate all prefixes
>>> configured in kernel down HW. This is necessary for routing to work
>>> as expected. If we don't do that HW might forward prefixes known to kernel
>>> incorrectly. Take an example when default route is set in switch HW and 
>>> there
>>> is an IP address set on a management (non-switch) port.
>>> Currently, only fibs related to the switch port netdev are offloaded using
>>> switchdev ops. This model is not extendable so the first patch introduces
>>> a replacement: notifier to propagate fib additions and removals to whoever
>>> interested. The second patch makes mlxsw to adopt this new way, registering
>>> one notifier block for each mlxsw (asic) instance.
>> Instead of introducing another specialization of a notifier_block
>> implementation, could we somehow have a kernel-based netlink listener
>> which receives the same kind of event information from rtmsg_fib()?
>> The reason is that having such a facility would hook directly onto
>> existing rtmsg_* calls that exist throughout the stack, and that seems
>> to scale better.
>I was thinking along the same lines. Instead of proliferating notifier blocks
>through-out the stack for switchdev offload, putting existing events to use 
>would be nice.
>But the problem though is drivers having to parse the netlink msg again. also, 
>the intent
>here is to do the offload first ..before the route is added to the kernel 
>(though i don't see that in
>the current series). existing netlink rmsg_fib events are generated after the 
>route is added to the kernel.
>Jiri, instead of the notifier, do you see a problem with always calling the 
>existing switchdev
>offload api for every route  for every asic instance ?. the first device where 
>the route fits wins.

There is not list of asic instances. Therefore the notifier fits much better 

>it seems similar to driver registering for notifier and looking at every route 
>am i missing something ?
>and the policies you mention could help around selecting the asic instance 
>(FCFS or mirror).
>you will need to abstract out the asic instance for switchdev api to call on, 
>but I thought you
>already have that in some form in your devlink infrastructure.

switchdev asic instances and devlink instances are orthogonal.

Reply via email to