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