Hi, On Mon, Jun 27, 2022 at 4:43 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > Hi Alexander, > > aahringo@xxxxxxxxxx wrote on Sat, 25 Jun 2022 22:29:08 -0400: > > > Hi, > > > > On Mon, Jun 20, 2022 at 10:26 AM Miquel Raynal > > <miquel.raynal@xxxxxxxxxxx> 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
