Date:   Fri, 30 Sep 2022 07:07:05 -0400
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Nikolay Aleksandrov <razor@...ckwall.org>, netdev@...r.kernel.org,
        davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
        Johannes Berg <johannes@...solutions.net>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Florian Westphal <fw@...len.de>,
        Jacob Keller <jacob.e.keller@...el.com>,
        Florent Fourcot <florent.fourcot@...irst.fr>,
        Guillaume Nault <gnault@...hat.com>,
        Nicolas Dichtel <nicolas.dichtel@...nd.com>,
        Hangbin Liu <liuhangbin@...il.com>
Subject: Re: [PATCH net-next] docs: netlink: clarify the historical baggage of
 Netlink flags

On Wed, Sep 28, 2022 at 10:21 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Wed, 28 Sep 2022 10:03:07 +0300 Nikolay Aleksandrov wrote:
> > The part about NLM_F_BULK is correct now, but won't be soon. I have patches to add
> > bulk delete to mdbs as well, and IIRC there were plans for other object types.
> > I can update the doc once they are applied, but IMO it will be more useful to explain
> > why they are used instead of who's using them, i.e. the BULK was added to support
> > flush for FDBs w/ filtering initially and it's a flag so others can re-use it
> > (my first attempt targeted only FDBs[1], but after a discussion it became clear that
> > it will be more beneficial if other object types can re-use it so moved to a flag).
> > The first version of the fdb flush support used only netlink attributes to do the
> > flush via setlink, later moved to a specific RTM command (RTM_FLUSHNEIGH)[2] and
> > finally settled on the flag[3][4] so everyone can use it.
>
> I thought that's all FDB-ish stuff. Not really looking forward to the
> use of flags spreading but within rtnl it may make some sense. We can
> just update the docs tho, no?
>
> BTW how would you define the exact semantics of NLM_F_BULK vs it not
> being set, in abstract terms?

I missed the discussion.
NLM_F_BULK looks strange. Why pollute the main header? Wouldnt NLM_F_ROOT
have sufficed to trigger the semantic? Or better create your own
"service header"
and put fdb specific into that object header? i.e the idea in netlink
being you specify:
{Main header: Object specific header: Object specific attributes in TLVs}
Main header should only be extended if you really really have to -
i.e requires much
longer review..

Historical context: We did try to push netlink as a wire protocol
(meaning it goes
across nodes instead of user-kernel), see:
https://www.rfc-editor.org/rfc/rfc3549.html and
https://datatracker.ietf.org/doc/html/draft-jhsrha-forces-netlink2-02
(there's an implementation
of netlink2 that i can dig up).
unfortunately there was much politiking and ForCES protocol was the compromise;
as a side, there's _no way in hell_ current netlink would be possible
to use on the wire
because of all these one-offs that were being added over time.
RFC3549 has some documentation which is not really up to date but still valid
(section 2.2/3 on the header). Note: The EXCL, APPEND etc are very
similar to file system
semantics (eg open())
Generic netlink was written because there were too many people
grabbing netlink ids
and we were going to run out of them at some point. IIRC, i called it
"foobar" originally
and Dave didnt like that name. It was intended to be the less
efficient cousin (subject to
more locks etc) - and the RPC semantic changes were mostly to
accommodate the fact
that you couldnt use netlink proper - although I am more a fan of
CRUD(restful) semantics
than RPC (netlink proper is salvagable for CRUD as is).

Not sure how much of this can be leveraged in the documentation (I
will take a look).

cheers,
jamal

cheers,
jamal

Powered by blists - more mailing lists