TODO.smpnet revision 1.47
11.47Snia$NetBSD: TODO.smpnet,v 1.47 2022/08/14 10:13:06 nia Exp $ 21.1Sozaki 31.2SozakiMP-safe components 41.2Sozaki================== 51.1Sozaki 61.21SozakiThey work without the big kernel lock (KERNEL_LOCK), i.e., with NET_MPSAFE 71.21Sozakikernel option. Some components scale up and some don't. 81.21Sozaki 91.7Sozaki - Device drivers 101.30Smsaitoh - aq(4) 111.41Smrg - bcmgenet(4) 121.47Snia - bge(4) 131.41Smrg - iavf(4) 141.41Smrg - ixg(4) 151.41Smrg - ixl(4) 161.41Smrg - ixv(4) 171.41Smrg - mcx(4) 181.41Smrg - rge(4) 191.41Smrg - se(4) 201.41Smrg - sunxi_emac(4) 211.7Sozaki - vioif(4) 221.7Sozaki - vmx(4) 231.7Sozaki - wm(4) 241.41Smrg - xennet(4) 251.41Smrg - usbnet(4) based adapters: 261.41Smrg - axe(4) 271.41Smrg - axen(4) 281.41Smrg - cdce(4) 291.41Smrg - cue(4) 301.41Smrg - kue(4) 311.41Smrg - mos(4) 321.41Smrg - mue(4) 331.41Smrg - smsc(4) 341.41Smrg - udav(4) 351.41Smrg - upl(4) 361.41Smrg - ure(4) 371.41Smrg - url(4) 381.41Smrg - urndis(4) 391.7Sozaki - Layer 2 401.7Sozaki - Ethernet (if_ethersubr.c) 411.7Sozaki - bridge(4) 421.7Sozaki - STP 431.7Sozaki - Fast forward (ipflow) 441.7Sozaki - Layer 3 451.7Sozaki - All except for items in the below section 461.7Sozaki - Interfaces 471.43Snia - canloop(4) 481.7Sozaki - gif(4) 491.22Sozaki - ipsecif(4) 501.7Sozaki - l2tp(4) 511.43Snia - lagg(4) 521.7Sozaki - pppoe(4) 531.7Sozaki - if_spppsubr.c 541.40Snia - tap(4) 551.7Sozaki - tun(4) 561.43Snia - vether(4) 571.12Sozaki - vlan(4) 581.7Sozaki - Packet filters 591.7Sozaki - npf(7) 601.7Sozaki - Others 611.7Sozaki - bpf(4) 621.12Sozaki - ipsec(4) 631.12Sozaki - opencrypto(9) 641.7Sozaki - pfil(9) 651.2Sozaki 661.2SozakiNon MP-safe components and kernel options 671.2Sozaki========================================= 681.2Sozaki 691.21SozakiThe components and options aren't MP-safe, i.e., requires the big kernel lock, 701.21Sozakiyet. Some of them can be used safely even if NET_MPSAFE is enabled because 711.21Sozakithey're still protected by the big kernel lock. The others aren't protected and 721.21Sozakiso unsafe, e.g, they may crash the kernel. 731.21Sozaki 741.21SozakiProtected ones 751.21Sozaki-------------- 761.21Sozaki 771.7Sozaki - Device drivers 781.7Sozaki - Most drivers other than ones listed in the above section 791.21Sozaki - Layer 4 801.21Sozaki - DCCP 811.21Sozaki - SCTP 821.21Sozaki - TCP 831.21Sozaki - UDP 841.21Sozaki 851.21SozakiUnprotected ones 861.21Sozaki---------------- 871.21Sozaki 881.6Sozaki - Layer 2 891.6Sozaki - ARCNET (if_arcsubr.c) 901.6Sozaki - IEEE 1394 (if_ieee1394subr.c) 911.6Sozaki - IEEE 802.11 (ieee80211(4)) 921.6Sozaki - Layer 3 931.6Sozaki - IPSELSRC 941.6Sozaki - MROUTING 951.6Sozaki - PIM 961.6Sozaki - MPLS (mpls(4)) 971.17Sozaki - IPv6 address selection policy 981.6Sozaki - Interfaces 991.6Sozaki - agr(4) 1001.6Sozaki - carp(4) 1011.6Sozaki - faith(4) 1021.6Sozaki - gre(4) 1031.6Sozaki - ppp(4) 1041.6Sozaki - sl(4) 1051.6Sozaki - stf(4) 1061.6Sozaki - if_srt 1071.6Sozaki - Packet filters 1081.6Sozaki - ipf(4) 1091.6Sozaki - pf(4) 1101.6Sozaki - Others 1111.6Sozaki - AppleTalk (sys/netatalk/) 1121.6Sozaki - Bluetooth (sys/netbt/) 1131.6Sozaki - altq(4) 1141.6Sozaki - kttcp(4) 1151.6Sozaki - NFS 1161.2Sozaki 1171.2SozakiKnow issues 1181.2Sozaki=========== 1191.1Sozaki 1201.15SozakiNOMPSAFE 1211.15Sozaki-------- 1221.15Sozaki 1231.15SozakiWe use "NOMPSAFE" as a mark that indicates that the code around it isn't MP-safe 1241.15Sozakiyet. We use it in comments and also use as part of function names, for example 1251.15Sozakim_get_rcvif_NOMPSAFE. Let's use "NOMPSAFE" to make it easy to find non-MP-safe 1261.15Sozakicodes by grep. 1271.15Sozaki 1281.1Sozakibpf 1291.2Sozaki--- 1301.1Sozaki 1311.1SozakiMP-ification of bpf requires all of bpf_mtap* are called in normal LWP context 1321.1Sozakior softint context, i.e., not in hardware interrupt context. For Tx, all 1331.44Sandvarbpf_mtap satisfy the requirement. For Rx, most of bpf_mtap are called in softint. 1341.1SozakiUnfortunately some bpf_mtap on Rx are still called in hardware interrupt context. 1351.1Sozaki 1361.1SozakiThis is the list of the functions that have such bpf_mtap: 1371.1Sozaki 1381.1Sozaki - sca_frame_process() @ sys/dev/ic/hd64570.c 1391.1Sozaki 1401.1SozakiIdeally we should make the functions run in softint somehow, but we don't have 1411.1Sozakiactual devices, no time (or interest/love) to work on the task, so instead we 1421.1Sozakiprovide a deferred bpf_mtap mechanism that forcibly runs bpf_mtap in softint 1431.1Sozakicontext. It's a workaround and once the functions run in softint, we should use 1441.1Sozakithe original bpf_mtap again. 1451.10Sozaki 1461.35Sjdolecekif_mcast_op() - SIOCADDMULTI/SIOCDELMULTI 1471.35Sjdolecek----------------------------------------- 1481.35SjdolecekHelper function is called to add or remove multicast addresses for 1491.35Sjdolecekinterface. When called via ioctl it takes IFNET_LOCK(), when called 1501.35Sjdolecekvia sosetopt() it doesn't. 1511.35Sjdolecek 1521.35SjdolecekVarious network drivers can't assert IFNET_LOCKED() in their if_ioctl 1531.35Sjdolecekbecause of this. Generally drivers still take care to splnet() even 1541.35Sjdolecekwith NET_MPSAFE before calling ether_ioctl(), but they do not take 1551.35SjdolecekKERNEL_LOCK(), so this is actually unsafe. 1561.35Sjdolecek 1571.10SozakiLingering obsolete variables 1581.10Sozaki----------------------------- 1591.10Sozaki 1601.10SozakiSome obsolete global variables and member variables of structures remain to 1611.10Sozakiavoid breaking old userland programs which directly access such variables via 1621.10Sozakikvm(3). 1631.10Sozaki 1641.10SozakiThe following programs still use kvm(3) to get some information related to 1651.10Sozakithe network stack. 1661.10Sozaki 1671.10Sozaki - netstat(1) 1681.10Sozaki - vmstat(1) 1691.10Sozaki - fstat(1) 1701.10Sozaki 1711.10Sozakinetstat(1) accesses ifnet_list, the head of a list of interface objects 1721.10Sozaki(struct ifnet), and traverses each object through ifnet#if_list member variable. 1731.10Sozakiifnet_list and ifnet#if_list is obsoleted by ifnet_pslist and 1741.10Sozakiifnet#if_pslist_entry respectively. netstat also accesses the IP address list 1751.46Sandvarof an interface through ifnet#if_addrlist. struct ifaddr, struct in_ifaddr 1761.10Sozakiand struct in6_ifaddr are accessed and the following obsolete member variables 1771.10Sozakiare stuck: ifaddr#ifa_list, in_ifaddr#ia_hash, in_ifaddr#ia_list, 1781.10Sozakiin6_ifaddr#ia_next and in6_ifaddr#_ia6_multiaddrs. Note that netstat already 1791.10Sozakiimplements alternative methods to fetch the above information via sysctl(3). 1801.10Sozaki 1811.10Sozakivmstat(1) shows statistics of hash tables created by hashinit(9) in the kernel. 1821.10SozakiThe statistic information is retrieved via kvm(3). The global variables 1831.10Sozakiin_ifaddrhash and in_ifaddrhashtbl, which are for a hash table of IPv4 1841.10Sozakiaddresses and obsoleted by in_ifaddrhash_pslist and in_ifaddrhashtbl_pslist, 1851.10Sozakiare kept for this purpose. We should provide a means to fetch statistics of 1861.10Sozakihash tables via sysctl(3). 1871.10Sozaki 1881.10Sozakifstat(1) shows information of bpf instances. Each bpf instance (struct bpf) is 1891.10Sozakiobtained via kvm(3). bpf_d#_bd_next, bpf_d#_bd_filter and bpf_d#_bd_list 1901.10Sozakimember variables are obsolete but remain. ifnet#if_xname is also accessed 1911.10Sozakivia struct bpf_if and obsolete ifnet#if_list is required to remain to not change 1921.11Sozakithe offset of ifnet#if_xname. The statistic counters (bpf#bd_rcount, 1931.11Sozakibpf#bd_dcount and bpf#bd_ccount) are also victims of this restriction; for 1941.11Sozakiscalability the statistic counters should be per-CPU and we should stop using 1951.11Sozakiatomic operations for them however we have to remain the counters and atomic 1961.11Sozakioperations. 1971.13Sozaki 1981.13SozakiScalability 1991.13Sozaki----------- 2001.13Sozaki 2011.13Sozaki - Per-CPU rtcaches (used in say IP forwarding) aren't scalable on multiple 2021.13Sozaki flows per CPU 2031.13Sozaki - ipsec(4) isn't scalable on the number of SA/SP; the cost of a look-up 2041.13Sozaki is O(n) 2051.14Sknakahar - opencrypto(9)'s crypto_newsession()/crypto_freesession() aren't scalable 2061.14Sknakahar as they are serialized by one mutex 2071.16Sozaki 2081.18SozakiALTQ 2091.18Sozaki---- 2101.18Sozaki 2111.18SozakiIf ALTQ is enabled in the kernel, it enforces to use just one Tx queue (if_snd) 2121.18Sozakifor packet transmissions, resulting in serializing all Tx packet processing on 2131.18Sozakithe queue. We should probably design and implement an alternative queuing 2141.18Sozakimechanism that deals with multi-core systems at the first place, not making the 2151.18Sozakiexisting ALTQ MP-safe because it's just annoying. 2161.27Spgoyette 2171.27SpgoyetteUsing kernel modules 2181.27Spgoyette-------------------- 2191.27Spgoyette 2201.27SpgoyettePlease note that if you enable NET_MPSAFE in your kernel, and you use and 2211.27Spgoyetteloadable kernel modules (including compat_xx modules or individual network 2221.27Spgoyetteinterface if_xxx device driver modules), you will need to build custom 2231.27Spgoyettemodules. For each module you will need to add the following line to its 2241.27SpgoyetteMakefile: 2251.27Spgoyette 2261.27Spgoyette CPPFLAGS+= NET_MPSAFE 2271.27Spgoyette 2281.27SpgoyetteFailure to do this may result in unpredictable behavior. 2291.28Sozaki 2301.28SozakiIPv4 address initialization atomicity 2311.28Sozaki------------------------------------- 2321.28Sozaki 2331.28SozakiAn IPv4 address is referenced by several data structures: an associated 2341.28Sozakiinterface, its local route, a connected route (if necessary), the global list, 2351.28Sozakithe global hash table, etc. These data structures are not updated atomically, 2361.28Sozakii.e., there can be inconsistent states on an IPv4 address in the kernel during 2371.28Sozakithe initialization of an IPv4 address. 2381.28Sozaki 2391.28SozakiOne known failure of the issue is that incoming packets destinating to an 2401.28Sozakiinitializing address can loop in the network stack in a short period of time. 2411.28SozakiThe address initialization creates an local route first and then registers an 2421.28Sozakiinitializing address to the global hash table that is used to decide if an 2431.28Sozakiincoming packet destinates to the host by checking the destination of the packet 2441.44Sandvaris registered to the hash table. So, if the host allows forwarding, an incoming 2451.28Sozakipacket can match on a local route of an initializing address at ip_output while 2461.28Sozakiit fails the to-self check described above at ip_input. Because a matched local 2471.28Sozakiroute points a loopback interface as its destination interface, an incoming 2481.28Sozakipacket sends to the network stack (ip_input) again, which results in looping. 2491.28SozakiThe loop stops once an initializing address is registered to the hash table. 2501.28Sozaki 2511.28SozakiOne solution of the issue is to reorder the address initialization instructions, 2521.28Sozakifirst register an address to the hash table then create its routes. Another 2531.28Sozakisolution is to use the routing table for the to-self check instead of using the 2541.28Sozakiglobal hash table, like IPv6. 2551.29Sozaki 2561.29Sozakiif_flags 2571.29Sozaki-------- 2581.29Sozaki 2591.29SozakiTo avoid data race on if_flags it should be protected by a lock (currently it's 2601.29SozakiIFNET_LOCK). Thus, if_flags should not be accessed on packet processing to 2611.29Sozakiavoid performance degradation by lock contentions. Traditionally IFF_RUNNING, 2621.29SozakiIFF_UP and IFF_OACTIVE flags of if_flags are checked on packet processing. If 2631.29Sozakiyou make a driver MP-safe you must remove such checks. 2641.29Sozaki 2651.45SriastradDrivers should not touch IFF_ALLMULTI. They are tempted to do so when updating 2661.45Sriastradhardware multicast filters on SIOCADDMULTI/SIOCDELMULTI. Instead, they should 2671.45Sriastraduse the ETHER_F_ALLMULTI bit in struct ethercom::ec_flags, under ETHER_LOCK. 2681.45Sriastradether_ioctl takes care of presenting IFF_ALLMULTI according to the current state 2691.45Sriastradof ETHER_F_ALLMULTI when queried with SIOCGIFFLAGS. 2701.29Sozaki 2711.29SozakiAlso IFF_PROMISC is checked in ether_input and we should get rid of it somehow. 272