[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK-6q+jYFeOyP_bvTd31av=ntJA=Qpas+v+xRDQuMNb74io2Xw@mail.gmail.com>
Date: Mon, 27 Jun 2022 21:32:08 -0400
From: Alexander Aring <aahringo@...hat.com>
To: Miquel Raynal <miquel.raynal@...tlin.com>
Cc: Alexander Aring <alex.aring@...il.com>,
Stefan Schmidt <stefan@...enfreihafen.org>,
linux-wpan - ML <linux-wpan@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Eric Dumazet <edumazet@...gle.com>,
Network Development <netdev@...r.kernel.org>,
David Girault <david.girault@...vo.com>,
Romuald Despres <romuald.despres@...vo.com>,
Frederic Blain <frederic.blain@...vo.com>,
Nicolas Schodet <nico@...fr.eu.org>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH wpan-next v3 2/4] net: ieee802154: Add support for inter
PAN management
Hi,
On Mon, Jun 27, 2022 at 4:43 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
>
> Hi Alexander,
>
> aahringo@...hat.com wrote on Sat, 25 Jun 2022 22:29:08 -0400:
>
> > Hi,
> >
> > On Mon, Jun 20, 2022 at 10:26 AM Miquel Raynal
> > <miquel.raynal@...tlin.com> wrote:
> > >
> > > Let's introduce the basics for defining PANs:
> > > - structures defining a PAN
> > > - helpers for PAN registration
> > > - helpers discarding old PANs
> > >
> >
> > I think the whole pan management can/should be stored in user space by
> > a daemon running in background.
>
> We need both, and currently:
> - while the scan is happening, the kernel saves all the discovered PANs
> - the kernel PAN list can be dumped (and also flushed) asynchronously by
> the userspace
>
> IOW the userspace is responsible of keeping its own list of PANs in
> sync with what the kernel discovers, so at any moment it can ask the
> kernel what it has in memory, it can be done during a scan or after. It
> can request a new scan to update the entries, or flush the kernel list.
> The scan operation is always requested by the user anyway, it's not
> something happening in the background.
>
I don't see what advantage it has to keep the discovered pan in the
kernel. You can do everything with a start/stop/pan discovered event.
It also has more advantages as you can look for a specific pan and
stop afterwards.
At the end the daemon has everything that the kernel also has, as you
said it's in sync.
> > This can be a network manager as it
> > listens to netlink events as "detect PAN xy" and stores it and offers
> > it in their list to associate with it.
>
> There are events produced, yes. But really, this is not something we
> actually need. The user requests a scan over a given range, when the
> scan is over it looks at the list and decides which PAN it
> wants to associate with, and through which coordinator (95% of the
> scenarii).
>
This isn't either a kernel job to decide which pan it will be associated with.
> > We need somewhere to draw a line and I guess the line is "Is this
> > information used e.g. as any lookup or something in the hot path", I
> > don't see this currently...
>
> Each PAN descriptor is like 20 bytes, so that's why I don't feel back
> keeping them, I think it's easier to be able to serve the list of PANs
> upon request rather than only forwarding events and not being able to
> retrieve the list a second time (at least during the development).
>
This has nothing to do with memory.
> Overall I feel like this part is still a little bit blurry because it
> has currently no user, perhaps I should send the next series which
> actually makes the current series useful.
>
Will it get more used than caching entries in the kernel for user
space? Please also no in-kernel association feature.
We can maybe agree to that point to put it under
IEEE802154_NL802154_EXPERIMENTAL config, as soon as we have some
_open_ user space program ready we will drop this feature again...
this program will show that there is no magic about it.
- Alex
Powered by blists - more mailing lists