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