Re: netif userland API
28.10.2023 23:43, Roy Marples wrote: > Using netlink rather than route on a modern FreeBSD kernel may allow you do > do the same thing > but install a kernel filter on the socket just to receive interface changes. > > That should match your requirements. This scales bad still. More new vlans under single parent we have, more system calls to list them, longer wall clock time util listing completition and more burden for the system as a whole. I'm talking about *efficient* API. Eugene
Re: netif userland API
Using netlink rather than route on a modern FreeBSD kernel may allow you do do the same thing but install a kernel filter on the socket just to receive interface changes.That should match your requirements.Roy Marples On Sat,28 Oct 2023 15:29:01 +0100 eu...@freebsd.org wrote 28.10.2023 23:21, Roy Marples wrote: > What you would do is open a route socket, then call getifaddrs and then > listen on the route socket for new interfaces. > > Then you can maintain a list of current vlans and take action accordingly. I'd like to be able to make a couple of system calls only to get a list of pre-created vlans for a moment. Efficiently and scalable. Not making thousands of reads (syscalls) from routing sockets and not syncing with the kernel. Eugene
Re: netif userland API
28.10.2023 23:21, Roy Marples wrote: > What you would do is open a route socket, then call getifaddrs and then > listen on the route socket for new interfaces. > > Then you can maintain a list of current vlans and take action accordingly. I'd like to be able to make a couple of system calls only to get a list of pre-created vlans for a moment. Efficiently and scalable. Not making thousands of reads (syscalls) from routing sockets and not syncing with the kernel. Eugene
netif userland API
Hi! Assume we run some FreeBSD-based broadband remote access server for PPPoE (net/mpd5 for example). The server has hundreds or thousands vlan interfaces and even more ngXXX interfaces, one per user PPPoE session. The server software may need to enable its PPPoE service for all newly created vlans over another "physical" parent interface just configured in addition to already running ones. I see no effective userland API for the software to list vlan interfaces under specific parent one. The only option I see is getifaddrs(3) function to get list of ALL interfaces in the system then iterate over the list calling ioctl SIOCGETVLAN and if there is no error, compare returned vlr_parent name with the name of needed parent interface. Not efficient at all, while serving new PPPoE connection attempts simultaneously, collecting traffic stats for RADIUS accounting etc. Do I miss something? Eugene