Re:  netif userland API

2023-10-28 Thread Eugene Grosbein
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

2023-10-28 Thread Roy Marples
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

2023-10-28 Thread Eugene Grosbein
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

2023-10-28 Thread Eugene Grosbein
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