Date:   Fri, 19 Aug 2022 21:07:36 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, corbet@....net,
        stephen@...workplumber.org, sdf@...gle.com, ecree.xilinx@...il.com,
        benjamin.poirier@...il.com, idosch@...sch.org,
        f.fainelli@...il.com, jiri@...nulli.us, dsahern@...nel.org,
        fw@...len.de, linux-doc@...r.kernel.org, jhs@...atatu.com,
        tgraf@...g.ch, jacob.e.keller@...el.com, svinota.saveliev@...il.com
Subject: Re: [PATCH net-next 2/2] docs: netlink: basic introduction to
 Netlink

On Fri, 2022-08-19 at 10:54 -0700, Jakub Kicinski wrote:
> On Fri, 19 Aug 2022 18:57:01 +0200 Johannes Berg wrote:
> > > Theoretically I think we also align what I called "fixed metadata
> > > headers", practically all of those are multiple of 4 :S  
> > 
> > But they're not really aligned, are they? Hmm. Well I guess practically
> > it doesn't matter. I just read this and wasn't really sure what the
> > mention of "[h]eaders" was referring to in this context.
> 
> Aligned in what sense? Absolute address? My understanding
> was that every layer of fixed headers should round itself
> off with NLMSG_ALIGN().

Well I think aligned in this context is always towards "start of
message", since that's the only thing that matters anyway (copied into a
- hopefully suitably aligned - buffer on the other side).

But OK, I've basically only dealt with generic netlink, so I don't
really know about the expectations of NLMSG_ALIGN and other kinds of
headers.

What I meant by "are not really aligned" is that I didn't actually _see_
the NLMSG_ALIGN() calls, but that might just be because in practice
they're not needed since everyone uses multiple-of-4 sizes anyway. Or
maybe because I just didn't check very much...

> > > I'll rewrite. The only use I'm aware of is OvS upcalls, are there more?  
> > 
> > In nl80211 we have quite a few "unicast an event message to a specific
> > portid" uses, e.g. if userspace subscribes to certain action frames, the
> > frame notification for it would be unicast to the subscribed socket, or
> > the TX status response after a frame was transmitted, etc. etc.
> 
> Interesting! So there is a "please subscribe me" netlink message 
> in addition to NETLINK_ADD_MEMBERSHIP? Does the port ID get passed
> explicitly or the kernel takes it from the socket by itself? Or I 
> guess you may not use the Port ID at all if you're hooking up to 
> socket destruction..

Well it depends on the operation, but generally yes.

For example, for certain action frames in wireless, there's an explicit
"I'm going to handle an action frame that starts with the bytes 00 01
02" or something, and then only a single such subscriber is allowed, and
the mere fact that a subscriber exists will actually modify kernel
behaviour.

The reason for this being that if you have an unknown/unhandled action
frame you're supposed to send it back with 0x80 OR'ed into the category
(first byte), indicating that you couldn't handle it. So when userspace
subscribes, it also gets the responsibility for handling it.

Now this might mean userspace actually sends it back with 0x80 (as might
be the case in hostapd which basically subscribes to *all* action frames
with a zero-length "start bytes" filter), or it actually handles it, but
it does absolve the kernel of the responsibility of handling it.

But because there has to be a single handler - otherwise none of them
could return it if unhandled - we simply unicast the received action
frame to the socket that requested the subscription.


> Multicast notifications
> -----------------------

[snip]

> The notification contains the same information as the response to the
> ``CTRL_CMD_GETFAMILY`` request. It is most common for "new object"
> notifications to contain the same exact data as the respective ``GET``.

I might say we should remove that second sentence - this is one of those
murky cases where it's actually sometimes not _possible_ to do due to
message size limitations etc.

That said, it's still common, so maybe that's OK, "common" doesn't mean
"always" and some notifications might obviously differ even if it's
common.

> The socket will now receive notifications. It is recommended to use
> a separate sockets for receiving notifications and sending requests
> to the kernel. The asynchronous nature of notifications means that
> they may get mixed in with the responses making the parsing much
> harder.

Not sure I'd say "parsing" here, maybe "message handling"? I mean, it's
not really about parsing the messages, more about the potentially
interleaved sequence of handling them. But maybe I'm splitting hairs :)

johannes

Powered by blists - more mailing lists