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