xref: /netbsd-src/doc/TODO.smpnet (revision fc4f42693f9b1c31f39f9cf50af1bf2010325808)
1$NetBSD: TODO.smpnet,v 1.19 2018/02/27 14:28:01 maxv Exp $
2
3MP-safe components
4==================
5
6 - Device drivers
7   - vioif(4)
8   - vmx(4)
9   - wm(4)
10   - ixg(4)
11   - ixv(4)
12 - Layer 2
13   - Ethernet (if_ethersubr.c)
14   - bridge(4)
15     - STP
16   - Fast forward (ipflow)
17 - Layer 3
18   - All except for items in the below section
19 - Interfaces
20   - gif(4)
21   - l2tp(4)
22   - pppoe(4)
23     - if_spppsubr.c
24   - tun(4)
25   - vlan(4)
26 - Packet filters
27   - npf(7)
28 - Others
29   - bpf(4)
30   - ipsec(4)
31   - opencrypto(9)
32   - pfil(9)
33
34Non MP-safe components and kernel options
35=========================================
36
37 - Device drivers
38   - Most drivers other than ones listed in the above section
39 - Layer 2
40   - ARCNET (if_arcsubr.c)
41   - ATM (if_atmsubr.c)
42   - BRIDGE_IPF
43   - FDDI (if_fddisubr.c)
44   - HIPPI (if_hippisubr.c)
45   - IEEE 1394 (if_ieee1394subr.c)
46   - IEEE 802.11 (ieee80211(4))
47   - Token ring (if_tokensubr.c)
48 - Layer 3
49   - IPSELSRC
50   - MROUTING
51   - PIM
52   - MPLS (mpls(4))
53   - IPv6 address selection policy
54 - Layer 4
55   - DCCP
56   - SCTP
57   - TCP
58   - UDP
59 - Interfaces
60   - agr(4)
61   - carp(4)
62   - etherip(4)
63   - faith(4)
64   - gre(4)
65   - ppp(4)
66   - sl(4)
67   - stf(4)
68   - strip(4)
69   - if_srt
70   - tap(4)
71 - Packet filters
72   - ipf(4)
73   - pf(4)
74 - Others
75   - AppleTalk (sys/netatalk/)
76   - ATM (sys/netnatm/)
77   - Bluetooth (sys/netbt/)
78   - altq(4)
79   - CIFS (sys/netsmb/)
80   - ISDN (sys/netisbn/)
81   - kttcp(4)
82   - NFS
83
84Know issues
85===========
86
87NOMPSAFE
88--------
89
90We use "NOMPSAFE" as a mark that indicates that the code around it isn't MP-safe
91yet.  We use it in comments and also use as part of function names, for example
92m_get_rcvif_NOMPSAFE.  Let's use "NOMPSAFE" to make it easy to find non-MP-safe
93codes by grep.
94
95bpf
96---
97
98MP-ification of bpf requires all of bpf_mtap* are called in normal LWP context
99or softint context, i.e., not in hardware interrupt context.  For Tx, all
100bpf_mtap satisfy the requrement.  For Rx, most of bpf_mtap are called in softint.
101Unfortunately some bpf_mtap on Rx are still called in hardware interrupt context.
102
103This is the list of the functions that have such bpf_mtap:
104
105 - sca_frame_process() @ sys/dev/ic/hd64570.c
106 - en_intr() @ sys/dev/ic/midway.c
107 - rxintr_cleanup() and txintr_cleanup() @ sys/dev/pci/if_lmc.c
108 - ipr_rx_data_rdy() @ sys/netisdn/i4b_ipr.c
109
110Ideally we should make the functions run in softint somehow, but we don't have
111actual devices, no time (or interest/love) to work on the task, so instead we
112provide a deferred bpf_mtap mechanism that forcibly runs bpf_mtap in softint
113context.  It's a workaround and once the functions run in softint, we should use
114the original bpf_mtap again.
115
116Lingering obsolete variables
117-----------------------------
118
119Some obsolete global variables and member variables of structures remain to
120avoid breaking old userland programs which directly access such variables via
121kvm(3).
122
123The following programs still use kvm(3) to get some information related to
124the network stack.
125
126 - netstat(1)
127 - vmstat(1)
128 - fstat(1)
129
130netstat(1) accesses ifnet_list, the head of a list of interface objects
131(struct ifnet), and traverses each object through ifnet#if_list member variable.
132ifnet_list and ifnet#if_list is obsoleted by ifnet_pslist and
133ifnet#if_pslist_entry respectively. netstat also accesses the IP address list
134of an interface throught ifnet#if_addrlist. struct ifaddr, struct in_ifaddr
135and struct in6_ifaddr are accessed and the following obsolete member variables
136are stuck: ifaddr#ifa_list, in_ifaddr#ia_hash, in_ifaddr#ia_list,
137in6_ifaddr#ia_next and in6_ifaddr#_ia6_multiaddrs. Note that netstat already
138implements alternative methods to fetch the above information via sysctl(3).
139
140vmstat(1) shows statistics of hash tables created by hashinit(9) in the kernel.
141The statistic information is retrieved via kvm(3). The global variables
142in_ifaddrhash and in_ifaddrhashtbl, which are for a hash table of IPv4
143addresses and obsoleted by in_ifaddrhash_pslist and in_ifaddrhashtbl_pslist,
144are kept for this purpose. We should provide a means to fetch statistics of
145hash tables via sysctl(3).
146
147fstat(1) shows information of bpf instances. Each bpf instance (struct bpf) is
148obtained via kvm(3). bpf_d#_bd_next, bpf_d#_bd_filter and bpf_d#_bd_list
149member variables are obsolete but remain. ifnet#if_xname is also accessed
150via struct bpf_if and obsolete ifnet#if_list is required to remain to not change
151the offset of ifnet#if_xname. The statistic counters (bpf#bd_rcount,
152bpf#bd_dcount and bpf#bd_ccount) are also victims of this restriction; for
153scalability the statistic counters should be per-CPU and we should stop using
154atomic operations for them however we have to remain the counters and atomic
155operations.
156
157Scalability
158-----------
159
160 - Per-CPU rtcaches (used in say IP forwarding) aren't scalable on multiple
161   flows per CPU
162 - ipsec(4) isn't scalable on the number of SA/SP; the cost of a look-up
163   is O(n)
164 - opencrypto(9)'s crypto_newsession()/crypto_freesession() aren't scalable
165   as they are serialized by one mutex
166
167ec_multi* of ethercom
168---------------------
169
170ec_multiaddrs and ec_multicnt of struct ethercom and items listed in
171ec_multiaddrs must be protected by ec_lock.  The core of ethernet subsystem is
172already MP-safe, however, device drivers that use the data should also be fixed.
173A typical change should be to protect manipulations of the data via ETHER_*
174macros such as ETHER_FIRST_MULTI by ETHER_LOCK and ETHER_UNLOCK.
175
176ALTQ
177----
178
179If ALTQ is enabled in the kernel, it enforces to use just one Tx queue (if_snd)
180for packet transmissions, resulting in serializing all Tx packet processing on
181the queue.  We should probably design and implement an alternative queuing
182mechanism that deals with multi-core systems at the first place, not making the
183existing ALTQ MP-safe because it's just annoying.
184