Since the interface is fully accessible after if_attach(), if_counters_alloc() should be called before.
> + > + if_attach(ifp); > + if_alloc_sadl(ifp); > + if_counters_alloc(ifp); > + On Mon, Jan 09, 2023 at 04:22:50PM +1000, David Gwynne wrote: > this is basically pair(4) except at layer 3 instead of Ethernet. > > i have a few reasons for this. > > pair basically exists to move packets between rdomains, which are a > layer 3 construct. pushing an ethernet header onto an mbuf data payload > and then pulling it off again on the other side of the link is a waste > of time. rport instead just stores which address family the packet is in > the mbuf header when sending a packet, and switches between l3 input > routines on the recving side. it doesnt have to touch the data payload > at all. > > Ethernet as a broadcast medium also implies a bunch of address related > issues. having to do arp/ndp between rdomains feels like a waste of > time. having to allocate a subnet or keep addresses adjacent on an ipv4 > subnet, or using a whole /64 for ipv6 is annoying. rport(4) as a point > to point interface lets you use any address and doesnt waste network or > broadcast addresses. > > pair(4) as an Ethernet interface technically supports all the virtual > Ethernet interfaces you can stack on a real interface. what does a > vlan(4) on a pair(4) interface mean? does it make sense to add a > pair interface to a bridge or tpmr? my gut feeling is that none of > that makes sense and we'd be better off without these options. > > i also made rport(4) mpsafe, and have a way to move packets around in > parallel in the future too. > > my test config (shell script) looked like this: > > ifconfig lo1 create rdomain 1 > ifconfig lo1 inet 127.0.0.1/8 > > ifconfig rport0 create > ifconfig rport1 create rdomain 1 > > ifconfig rport0 inet 169.254.169.254/32 169.254.254.169 > ifconfig rport1 inet 169.254.254.169/32 169.254.169.254 > > ifconfig rport0 parent rport1 > > ifconfig rport0 up > ifconfig rport1 up >
