[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160919060854.GB1846@nanopsycho.orion>
Date: Mon, 19 Sep 2016 08:08:54 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, idosch@...lanox.com,
eladr@...lanox.com, yotamg@...lanox.com, nogahf@...lanox.com,
ogerlitz@...lanox.com, roopa@...ulusnetworks.com,
nikolay@...ulusnetworks.com, linville@...driver.com, tgraf@...g.ch,
gospo@...ulusnetworks.com, sfeldma@...il.com, ast@...mgrid.com,
edumazet@...gle.com, hannes@...essinduktion.org,
dsa@...ulusnetworks.com, jhs@...atatu.com,
vivien.didelot@...oirfairelinux.com, john.fastabend@...el.com,
andrew@...n.ch, ivecera@...hat.com
Subject: Re: [patch net-next RFC 0/2] fib4 offload: notifier to let hw to be
aware of all prefixes
Sun, Sep 18, 2016 at 10:00:44PM CEST, f.fainelli@...il.com wrote:
>Le 06/09/2016 à 05:01, Jiri Pirko a écrit :
>> From: Jiri Pirko <jiri@...lanox.com>
>>
>> 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()?
rtmsg_fib destination is userspace. The message format is netlink. I
don't think it is wise to pass netlink messages inside kernel when we
can pass nice structures. Lower overhead. This is how it is done in the
rest of kernel. Not sure how your comment is related specifically to
this patch.
>
>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.
>--
>Florian
Powered by blists - more mailing lists