| blob | ea682090b3c1a1b2676b703389ec69bc2eb8a84f |
1 /*
2 * CDDL HEADER START
3 *
4 * The contents of this file are subject to the terms of the
5 * Common Development and Distribution License (the "License").
6 * You may not use this file except in compliance with the License.
7 *
8 * You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
9 * or http://www.opensolaris.org/os/licensing.
10 * See the License for the specific language governing permissions
11 * and limitations under the License.
12 *
13 * When distributing Covered Code, include this CDDL HEADER in each
14 * file and include the License file at usr/src/OPENSOLARIS.LICENSE.
15 * If applicable, add the following below this CDDL HEADER, with the
16 * fields enclosed by brackets "[]" replaced with your own identifying
17 * information: Portions Copyright [yyyy] [name of copyright owner]
18 *
19 * CDDL HEADER END
20 */
21 /*
22 * Copyright 2010 Sun Microsystems, Inc. All rights reserved.
23 * Use is subject to license terms.
24 * Copyright 2017 Joyent, Inc.
25 * Copyright 2013 Nexenta Systems, Inc. All rights reserved.
26 */
28 /*
29 * MAC data path
30 *
31 * The MAC data path is concerned with the flow of traffic from mac clients --
32 * DLS, IP, etc. -- to various GLDv3 device drivers -- e1000g, vnic, aggr,
33 * ixgbe, etc. -- and from the GLDv3 device drivers back to clients.
34 *
35 * -----------
36 * Terminology
37 * -----------
38 *
39 * MAC uses a lot of different, but related terms that are associated with the
40 * design and structure of the data path. Before we cover other aspects, first
41 * let's review the terminology that MAC uses.
42 *
43 * MAC
44 *
45 * This driver. It interfaces with device drivers and provides abstractions
46 * that the rest of the system consumes. All data links -- things managed
47 * with dladm(8), are accessed through MAC.
48 *
49 * GLDv3 DEVICE DRIVER
50 *
51 * A GLDv3 device driver refers to a driver, both for pseudo-devices and
52 * real devices, which implement the GLDv3 driver API. Common examples of
53 * these are igb and ixgbe, which are drivers for various Intel networking
54 * cards. These devices may or may not have various features, such as
55 * hardware rings and checksum offloading. For MAC, a GLDv3 device is the
56 * final point for the transmission of a packet and the starting point for
57 * the receipt of a packet.
58 *
59 * FLOWS
60 *
61 * At a high level, a flow refers to a series of packets that are related.
62 * Often times the term is used in the context of TCP to indicate a unique
63 * TCP connection and the traffic over it. However, a flow can exist at
64 * other levels of the system as well. MAC has a notion of a default flow
65 * which is used for all unicast traffic addressed to the address of a MAC
66 * device. For example, when a VNIC is created, a default flow is created
67 * for the VNIC's MAC address. In addition, flows are created for broadcast
68 * groups and a user may create a flow with flowadm(8).
69 *
70 * CLASSIFICATION
71 *
72 * Classification refers to the notion of identifying an incoming frame
73 * based on its destination address and optionally its source addresses and
74 * doing different processing based on that information. Classification can
75 * be done in both hardware and software. In general, we usually only
76 * classify based on the layer two destination, eg. for Ethernet, the
77 * destination MAC address.
78 *
79 * The system also will do classification based on layer three and layer
80 * four properties. This is used to support things like flowadm(8), which
81 * allows setting QoS and other properties on a per-flow basis.
82 *
83 * RING
84 *
85 * Conceptually, a ring represents a series of framed messages, often in a
86 * contiguous chunk of memory that acts as a circular buffer. Rings come in
87 * a couple of forms. Generally they are either a hardware construct (hw
88 * ring) or they are a software construct (sw ring) maintained by MAC.
89 *
90 * HW RING
91 *
92 * A hardware ring is a set of resources provided by a GLDv3 device driver
93 * (even if it is a pseudo-device). A hardware ring comes in two different
94 * forms: receive (rx) rings and transmit (tx) rings. An rx hw ring is
95 * something that has a unique DMA (direct memory access) region and
96 * generally supports some form of classification (though it isn't always
97 * used), as well as a means of generating an interrupt specific to that
98 * ring. For example, the device may generate a specific MSI-X for a PCI
99 * express device. A tx ring is similar, except that it is dedicated to
100 * transmission. It may also be a vector for enabling features such as VLAN
101 * tagging and large transmit offloading. It usually has its own dedicated
102 * interrupts for transmit being completed.
103 *
104 * SW RING
105 *
106 * A software ring is a construction of MAC. It represents the same thing
107 * that a hardware ring generally does, a collection of frames. However,
108 * instead of being in a contiguous ring of memory, they're instead linked
109 * by using the mblk_t's b_next pointer. Each frame may itself be multiple
110 * mblk_t's linked together by the b_cont pointer. A software ring always
111 * represents a collection of classified packets; however, it varies as to
112 * whether it uses only layer two information, or a combination of that and
113 * additional layer three and layer four data.
114 *
115 * FANOUT
116 *
117 * Fanout is the idea of spreading out the load of processing frames based
118 * on the source and destination information contained in the layer two,
119 * three, and four headers, such that the data can then be processed in
120 * parallel using multiple hardware threads.
121 *
122 * A fanout algorithm hashes the headers and uses that to place different
123 * flows into a bucket. The most important thing is that packets that are
124 * in the same flow end up in the same bucket. If they do not, performance
125 * can be adversely affected. Consider the case of TCP. TCP severely
126 * penalizes a connection if the data arrives out of order. If a given flow
127 * is processed on different CPUs, then the data will appear out of order,
128 * hence the invariant that fanout always hash a given flow to the same
129 * bucket and thus get processed on the same CPU.
130 *
131 * RECEIVE SIDE SCALING (RSS)
132 *
133 *
134 * Receive side scaling is a term that isn't common in illumos, but is used
135 * by vendors and was popularized by Microsoft. It refers to the idea of
136 * spreading the incoming receive load out across multiple interrupts which
137 * can be directed to different CPUs. This allows a device to leverage
138 * hardware rings even when it doesn't support hardware classification. The
139 * hardware uses an algorithm to perform fanout that ensures the flow
140 * invariant is maintained.
141 *
142 * SOFT RING SET
143 *
144 * A soft ring set, commonly abbreviated SRS, is a collection of rings and
145 * is used for both transmitting and receiving. It is maintained in the
146 * structure mac_soft_ring_set_t. A soft ring set is usually associated
147 * with flows, and coordinates both the use of hardware and software rings.
148 * Because the use of hardware rings can change as devices such as VNICs
149 * come and go, we always ensure that the set has software classification
150 * rules that correspond to the hardware classification rules from rings.
151 *
152 * Soft ring sets are also used for the enforcement of various QoS
153 * properties. For example, if a bandwidth limit has been placed on a
154 * specific flow or device, then that will be enforced by the soft ring
155 * set.
156 *
157 * SERVICE ATTACHMENT POINT (SAP)
158 *
159 * The service attachment point is a DLPI (Data Link Provider Interface)
160 * concept; however, it comes up quite often in MAC. Most MAC devices speak
161 * a protocol that has some notion of different channels or message type
162 * identifiers. For example, Ethernet defines an EtherType which is a part
163 * of the Ethernet header and defines the particular protocol of the data
164 * payload. If the EtherType is set to 0x0800, then it defines that the
165 * contents of that Ethernet frame is IPv4 traffic. For Ethernet, the
166 * EtherType is the SAP.
167 *
168 * In DLPI, a given consumer attaches to a specific SAP. In illumos, the ip
169 * and arp drivers attach to the EtherTypes for IPv4, IPv6, and ARP. Using
170 * libdlpi(3LIB) user software can attach to arbitrary SAPs. With the
171 * exception of 802.1Q VLAN tagged traffic, MAC itself does not directly
172 * consume the SAP; however, it uses that information as part of hashing
173 * and it may be used as part of the construction of flows.
174 *
175 * PRIMARY MAC CLIENT
176 *
177 * The primary mac client refers to a mac client whose unicast address
178 * matches the address of the device itself. For example, if the system has
179 * instance of the e1000g driver such as e1000g0, e1000g1, etc., the
180 * primary mac client is the one named after the device itself. VNICs that
181 * are created on top of such devices are not the primary client.
182 *
183 * TRANSMIT DESCRIPTORS
184 *
185 * Transmit descriptors are a resource that most GLDv3 device drivers have.
186 * Generally, a GLDv3 device driver takes a frame that's meant to be output
187 * and puts a copy of it into a region of memory. Each region of memory
188 * usually has an associated descriptor that the device uses to manage
189 * properties of the frames. Devices have a limited number of such
190 * descriptors. They get reclaimed once the device finishes putting the
191 * frame on the wire.
192 *
193 * If the driver runs out of transmit descriptors, for example, the OS is
194 * generating more frames than it can put on the wire, then it will return
195 * them back to the MAC layer.
196 *
197 * ---------------------------------
198 * Rings, Classification, and Fanout
199 * ---------------------------------
200 *
201 * The heart of MAC is made up of rings, and not those that Elven-kings wear.
202 * When receiving a packet, MAC breaks the work into two different, though
203 * interrelated phases. The first phase is generally classification and then the
204 * second phase is generally fanout. When a frame comes in from a GLDv3 Device,
205 * MAC needs to determine where that frame should be delivered. If it's a
206 * unicast frame (say a normal TCP/IP packet), then it will be delivered to a
207 * single MAC client; however, if it's a broadcast or multicast frame, then MAC
208 * may need to deliver it to multiple MAC clients.
209 *
210 * On transmit, classification isn't quite as important, but may still be used.
211 * Unlike with the receive path, the classification is not used to determine
212 * devices that should transmit something, but rather is used for special
213 * properties of a flow, eg. bandwidth limits for a given IP address, device, or
214 * connection.
215 *
216 * MAC employs a software classifier and leverages hardware classification as
217 * well. The software classifier can leverage the full layer two information,
218 * source, destination, VLAN, and SAP. If the SAP indicates that IP traffic is
219 * being sent, it can classify based on the IP header, and finally, it also
220 * knows how to classify based on the local and remote ports of TCP, UDP, and
221 * SCTP.
222 *
223 * Hardware classifiers vary in capability. Generally all hardware classifiers
224 * provide the capability to classify based on the destination MAC address. Some
225 * hardware has additional filters built in for performing more in-depth
226 * classification; however, it often has much more limited resources for these
227 * activities as compared to the layer two destination address classification.
228 *
229 * The modus operandi in MAC is to always ensure that we have software-based
230 * capabilities and rules in place and then to supplement that with hardware
231 * resources when available. In general, simple layer two classification is
232 * sufficient and nothing else is used, unless a specific flow is created with
233 * tools such as flowadm(8) or bandwidth limits are set on a device with
234 * dladm(8).
235 *
236 * RINGS AND GROUPS
237 *
238 * To get into how rings and classification play together, it's first important
239 * to understand how hardware devices commonly associate rings and allow them to
240 * be programmed. Recall that a hardware ring should be thought of as a DMA
241 * buffer and an interrupt resource. Rings are then collected into groups. A
242 * group itself has a series of classification rules. One or more MAC addresses
243 * are assigned to a group.
244 *
245 * Hardware devices vary in terms of what capabilities they provide. Sometimes
246 * they allow for a dynamic assignment of rings to a group and sometimes they
247 * have a static assignment of rings to a group. For example, the ixgbe driver
248 * has a static assignment of rings to groups such that every group has exactly
249 * one ring and the number of groups is equal to the number of rings.
250 *
251 * Classification and receive side scaling both come into play with how a device
252 * advertises itself to MAC and how MAC uses it. If a device supports layer two
253 * classification of frames, then MAC will assign MAC addresses to a group as a
254 * form of primary classification. If a single MAC address is assigned to a
255 * group, a common case, then MAC will consider packets that come in from rings
256 * on that group to be fully classified and will not need to do any software
257 * classification unless a specific flow has been created.
258 *
259 * If a device supports receive side scaling, then it may advertise or support
260 * groups with multiple rings. In those cases, then receive side scaling will
261 * come into play and MAC will use that as a means of fanning out received
262 * frames across multiple CPUs. This can also be combined with groups that
263 * support layer two classification.
264 *
265 * If a device supports dynamic assignments of rings to groups, then MAC will
266 * change around the way that rings are assigned to various groups as devices
267 * come and go from the system. For example, when a VNIC is created, a new flow
268 * will be created for the VNIC's MAC address. If a hardware ring is available,
269 * MAC may opt to reassign it from one group to another.
270 *
271 * ASSIGNMENT OF HARDWARE RINGS
272 *
273 * This is a bit of a complicated subject that varies depending on the device,
274 * the use of aggregations, the special nature of the primary mac client. This
275 * section deserves being fleshed out.
276 *
277 * FANOUT
278 *
279 * illumos uses fanout to help spread out the incoming processing load of chains
280 * of frames away from a single CPU. If a device supports receive side scaling,
281 * then that provides an initial form of fanout; however, what we're concerned
282 * with all happens after the context of a given set of frames being classified
283 * to a soft ring set.
284 *
285 * After frames reach a soft ring set and account for any potential bandwidth
286 * related accounting, they may be fanned out based on one of the following
287 * three modes:
288 *
289 * o No Fanout
290 * o Protocol level fanout
291 * o Full software ring protocol fanout
292 *
293 * MAC makes the determination as to which of these modes a given soft ring set
294 * obtains based on parameters such as whether or not it's the primary mac
295 * client, whether it's on a 10 GbE or faster device, user controlled dladm(8)
296 * properties, and the nature of the hardware and the resources that it has.
297 *
298 * When there is no fanout, MAC does not create any soft rings for a device and
299 * the device has frames delivered directly to the MAC client.
300 *
301 * Otherwise, all fanout is performed by software. MAC divides incoming frames
302 * into one of three buckets -- IPv4 TCP traffic, IPv4 UDP traffic, and
303 * everything else. Note, VLAN tagged traffic is considered other, regardless of
304 * the interior EtherType. Regardless of the type of fanout, these three
305 * categories or buckets are always used.
306 *
307 * The difference between protocol level fanout and full software ring protocol
308 * fanout is the number of software rings that end up getting created. The
309 * system always uses the same number of software rings per protocol bucket. So
310 * in the first case when we're just doing protocol level fanout, we just create
311 * one software ring each for IPv4 TCP traffic, IPv4 UDP traffic, and everything
312 * else.
313 *
314 * In the case where we do full software ring protocol fanout, we generally use
315 * mac_compute_soft_ring_count() to determine the number of rings. There are
316 * other combinations of properties and devices that may send us down other
317 * paths, but this is a common starting point. If it's a non-bandwidth enforced
318 * device and we're on at least a 10 GbE link, then we'll use eight soft rings
319 * per protocol bucket as a starting point. See mac_compute_soft_ring_count()
320 * for more information on the total number.
321 *
322 * For each of these rings, we create a mac_soft_ring_t and an associated worker
323 * thread. Particularly when doing full software ring protocol fanout, we bind
324 * each of the worker threads to individual CPUs.
325 *
326 * The other advantage of these software rings is that it allows upper layers to
327 * optionally poll on them. For example, TCP can leverage an squeue to poll on
328 * the software ring, see squeue.c for more information.
329 *
330 * DLS BYPASS
331 *
332 * DLS is the data link services module. It interfaces with DLPI, which is the
333 * primary way that other parts of the system such as IP interface with the MAC
334 * layer. While DLS is traditionally a STREAMS-based interface, it allows for
335 * certain modules such as IP to negotiate various more modern interfaces to be
336 * used, which are useful for higher performance and allow it to use direct
337 * function calls to DLS instead of using STREAMS.
338 *
339 * When we have IPv4 TCP or UDP software rings, then traffic on those rings is
340 * eligible for what we call the dls bypass. In those cases, rather than going
341 * out mac_rx_deliver() to DLS, DLS instead registers them to go directly via
342 * the direct callback registered with DLS, generally ip_input().
343 *
344 * HARDWARE RING POLLING
345 *
346 * GLDv3 devices with hardware rings generally deliver chains of messages
347 * (mblk_t chain) during the context of a single interrupt. However, interrupts
348 * are not the only way that these devices may be used. As part of implementing
349 * ring support, a GLDv3 device driver must have a way to disable the generation
350 * of that interrupt and allow for the operating system to poll on that ring.
351 *
352 * To implement this, every soft ring set has a worker thread and a polling
353 * thread. If a sufficient packet rate comes into the system, MAC will 'blank'
354 * (disable) interrupts on that specific ring and the polling thread will start
355 * consuming packets from the hardware device and deliver them to the soft ring
356 * set, where the worker thread will take over.
357 *
358 * Once the rate of packet intake drops down below a certain threshold, then
359 * polling on the hardware ring will be quiesced and interrupts will be
360 * re-enabled for the given ring. This effectively allows the system to shift
361 * how it handles a ring based on its load. At high packet rates, polling on the
362 * device as opposed to relying on interrupts can actually reduce overall system
363 * load due to the minimization of interrupt activity.
364 *
365 * Note the importance of each ring having its own interrupt source. The whole
366 * idea here is that we do not disable interrupts on the device as a whole, but
367 * rather each ring can be independently toggled.
368 *
369 * USE OF WORKER THREADS
370 *
371 * Both the soft ring set and individual soft rings have a worker thread
372 * associated with them that may be bound to a specific CPU in the system. Any
373 * such assignment will get reassessed as part of dynamic reconfiguration events
374 * in the system such as the onlining and offlining of CPUs and the creation of
375 * CPU partitions.
376 *
377 * In many cases, while in an interrupt, we try to deliver a frame all the way
378 * through the stack in the context of the interrupt itself. However, if the
379 * amount of queued frames has exceeded a threshold, then we instead defer to
380 * the worker thread to do this work and signal it. This is particularly useful
381 * when you have the soft ring set delivering frames into multiple software
382 * rings. If it was only delivering frames into a single software ring then
383 * there'd be no need to have another thread take over. However, if it's
384 * delivering chains of frames to multiple rings, then it's worthwhile to have
385 * the worker for the software ring take over so that the different software
386 * rings can be processed in parallel.
387 *
388 * In a similar fashion to the hardware polling thread, if we don't have a
389 * backlog or there's nothing to do, then the worker thread will go back to
390 * sleep and frames can be delivered all the way from an interrupt. This
391 * behavior is useful as it's designed to minimize latency and the default
392 * disposition of MAC is to optimize for latency.
393 *
394 * MAINTAINING CHAINS
395 *
396 * Another useful idea that MAC uses is to try and maintain frames in chains for
397 * as long as possible. The idea is that all of MAC can handle chains of frames
398 * structured as a series of mblk_t structures linked with the b_next pointer.
399 * When performing software classification and software fanout, MAC does not
400 * simply determine the destination and send the frame along. Instead, in the
401 * case of classification, it tries to maintain a chain for as long as possible
402 * before passing it along and performing additional processing.
403 *
404 * In the case of fanout, MAC first determines what the target software ring is
405 * for every frame in the original chain and constructs a new chain for each
406 * target. MAC then delivers the new chain to each software ring in succession.
407 *
408 * The whole rationale for doing this is that we want to try and maintain the
409 * pipe as much as possible and deliver as many frames through the stack at once
410 * that we can, rather than just pushing a single frame through. This can often
411 * help bring down latency and allows MAC to get a better sense of the overall
412 * activity in the system and properly engage worker threads.
413 *
414 * --------------------
415 * Bandwidth Management
416 * --------------------
417 *
418 * Bandwidth management is something that's built into the soft ring set itself.
419 * When bandwidth limits are placed on a flow, a corresponding soft ring set is
420 * toggled into bandwidth mode. This changes how we transmit and receive the
421 * frames in question.
422 *
423 * Bandwidth management is done on a per-tick basis. We translate the user's
424 * requested bandwidth from a quantity per-second into a quantity per-tick. MAC
425 * cannot process a frame across more than one tick, thus it sets a lower bound
426 * for the bandwidth cap to be a single MTU. This also means that when
427 * hires ticks are enabled (hz is set to 1000), that the minimum amount of
428 * bandwidth is higher, because the number of ticks has increased and MAC has to
429 * go from accepting 100 packets / sec to 1000 / sec.
430 *
431 * The bandwidth counter is reset by either the soft ring set's worker thread or
432 * a thread that is doing an inline transmit or receive if they discover that
433 * the current tick is in the future from the recorded tick.
434 *
435 * Whenever we're receiving or transmitting data, we end up leaving most of the
436 * work to the soft ring set's worker thread. This forces data inserted into the
437 * soft ring set to be effectively serialized and allows us to exhume bandwidth
438 * at a reasonable rate. If there is nothing in the soft ring set at the moment
439 * and the set has available bandwidth, then it may processed inline.
440 * Otherwise, the worker is responsible for taking care of the soft ring set.
441 *
442 * ---------------------
443 * The Receive Data Path
444 * ---------------------
445 *
446 * The following series of ASCII art images breaks apart the way that a frame
447 * comes in and is processed in MAC.
448 *
449 * Part 1 -- Initial frame receipt, SRS classification
450 *
451 * Here, a frame is received by a GLDv3 driver, generally in the context of an
452 * interrupt, and it ends up in mac_rx_common(). A driver calls either mac_rx or
453 * mac_rx_ring, depending on whether or not it supports rings and can identify
454 * the interrupt as having come from a specific ring. Here we determine whether
455 * or not it's fully classified and perform software classification as
456 * appropriate. From here, everything always ends up going to either entry [A]
457 * or entry [B] based on whether or not they have subflow processing needed. We
458 * leave via fanout or delivery.
459 *
460 * +===========+
461 * v hardware v
462 * v interrupt v
463 * +===========+
464 * |
465 * * . . appropriate
466 * | upcall made
467 * | by GLDv3 driver . . always
468 * | .
469 * +--------+ | +----------+ . +---------------+
470 * | GLDv3 | +---->| mac_rx |-----*--->| mac_rx_common |
471 * | Driver |-->--+ +----------+ +---------------+
472 * +--------+ | ^ |
473 * | | ^ v
474 * ^ | * . . always +----------------------+
475 * | | | | mac_promisc_dispatch |
476 * | | +-------------+ +----------------------+
477 * | +--->| mac_rx_ring | |
478 * | +-------------+ * . . hw classified
479 * | v or single flow?
480 * | |
481 * | +--------++--------------+
482 * | | | * hw class,
483 * | | * hw classified | subflows
484 * | no hw class and . * | or single | exist
485 * | subflows | | flow |
486 * | | v v
487 * | | +-----------+ +-----------+
488 * | | | goto | | goto |
489 * | | | entry [A] | | entry [B] |
490 * | | +-----------+ +-----------+
491 * | v ^
492 * | +-------------+ |
493 * | | mac_rx_flow | * SRS and flow found,
494 * | +-------------+ | call flow cb
495 * | | +------+
496 * | v |
497 * v +==========+ +-----------------+
498 * | v For each v--->| mac_rx_classify |
499 * +----------+ v mblk_t v +-----------------+
500 * | srs | +==========+
501 * | pollling |
502 * | thread |->------------------------------------------+
503 * +----------+ |
504 * v . inline
505 * +--------------------+ +----------+ +---------+ .
506 * [A]---->| mac_rx_srs_process |-->| check bw |-->| enqueue |--*---------+
507 * +--------------------+ | limits | | frames | |
508 * ^ +----------+ | to SRS | |
509 * | +---------+ |
510 * | send chain +--------+ | |
511 * * when clasified | signal | * BW limits, |
512 * | flow changes | srs |<---+ loopback, |
513 * | | worker | stack too |
514 * | +--------+ deep |
515 * +-----------------+ +--------+ |
516 * | mac_flow_lookup | | srs | +---------------------+ |
517 * +-----------------+ | worker |---->| mac_rx_srs_drain |<---+
518 * ^ | thread | | mac_rx_srs_drain_bw |
519 * | +--------+ +---------------------+
520 * | |
521 * +----------------------------+ * software rings
522 * [B]-->| mac_rx_srs_subflow_process | | for fanout?
523 * +----------------------------+ |
524 * +----------+-----------+
525 * | |
526 * v v
527 * +--------+ +--------+
528 * | goto | | goto |
529 * | Part 2 | | Part 3 |
530 * +--------+ +--------+
531 *
532 * Part 2 -- Fanout
533 *
534 * This part is concerned with using software fanout to assign frames to
535 * software rings and then deliver them to MAC clients or allow those rings to
536 * be polled upon. While there are two different primary fanout entry points,
537 * mac_rx_fanout and mac_rx_proto_fanout, they behave in similar ways, and aside
538 * from some of the individual hashing techniques used, most of the general
539 * flow is the same.
540 *
541 * +--------+ +-------------------+
542 * | From |---+--------->| mac_rx_srs_fanout |----+
543 * | Part 1 | | +-------------------+ | +=================+
544 * +--------+ | | v for each mblk_t v
545 * * . . protocol only +--->v assign to new v
546 * | fanout | v chain based on v
547 * | | v hash % nrings v
548 * | +-------------------------+ | +=================+
549 * +--->| mac_rx_srs_proto_fanout |----+ |
550 * +-------------------------+ |
551 * v
552 * +------------+ +--------------------------+ +================+
553 * | enqueue in |<---| mac_rx_soft_ring_process |<------v for each chain v
554 * | soft ring | +--------------------------+ +================+
555 * +------------+
556 * | +-----------+
557 * * soft ring set | soft ring |
558 * | empty and no | worker |
559 * | worker? | thread |
560 * | +-----------+
561 * +------*----------------+ |
562 * | . | v
563 * No . * . Yes | +------------------------+
564 * | +----<--| mac_rx_soft_ring_drain |
565 * | | +------------------------+
566 * v |
567 * +-----------+ v
568 * | signal | +---------------+
569 * | soft ring | | Deliver chain |
570 * | worker | | goto Part 3 |
571 * +-----------+ +---------------+
572 *
573 *
574 * Part 3 -- Packet Delivery
575 *
576 * Here, we go through and deliver the mblk_t chain directly to a given
577 * processing function. In a lot of cases this is mac_rx_deliver(). In the case
578 * of DLS bypass being used, then instead we end up going ahead and deliver it
579 * to the direct callback registered with DLS, generally ip_input.
580 *
581 *
582 * +---------+ +----------------+ +------------------+
583 * | From |---+------->| mac_rx_deliver |--->| Off to DLS, or |
584 * | Parts 1 | | +----------------+ | other MAC client |
585 * | and 2 | * DLS bypass +------------------+
586 * +---------+ | enabled +----------+ +-------------+
587 * +---------->| ip_input |--->| To IP |
588 * +----------+ | and beyond! |
589 * +-------------+
590 *
591 * ----------------------
592 * The Transmit Data Path
593 * ----------------------
594 *
595 * Before we go into the images, it's worth talking about a problem that is a
596 * bit different from the receive data path. GLDv3 device drivers have a finite
597 * amount of transmit descriptors. When they run out, they return unused frames
598 * back to MAC. MAC, at this point has several options about what it will do,
599 * which vary based upon the settings that the client uses.
600 *
601 * When a device runs out of descriptors, the next thing that MAC does is
602 * enqueue them off of the soft ring set or a software ring, depending on the
603 * configuration of the soft ring set. MAC will enqueue up to a high watermark
604 * of mblk_t chains, at which point it will indicate flow control back to the
605 * client. Once this condition is reached, any mblk_t chains that were not
606 * enqueued will be returned to the caller and they will have to decide what to
607 * do with them. There are various flags that control this behavior that a
608 * client may pass, which are discussed below.
609 *
610 * When this condition is hit, MAC also returns a cookie to the client in
611 * addition to unconsumed frames. Clients can poll on that cookie and register a
612 * callback with MAC to be notified when they are no longer subject to flow
613 * control, at which point they may continue to call mac_tx(). This flow control
614 * actually manages to work itself all the way up the stack, back through dls,
615 * to ip, through the various protocols, and to sockfs.
616 *
617 * While the behavior described above is the default, this behavior can be
618 * modified. There are two alternate modes, described below, which are
619 * controlled with flags.
620 *
621 * DROP MODE
622 *
623 * This mode is controlled by having the client pass the MAC_DROP_ON_NO_DESC
624 * flag. When this is passed, if a device driver runs out of transmit
625 * descriptors, then the MAC layer will drop any unsent traffic. The client in
626 * this case will never have any frames returned to it.
627 *
628 * DON'T ENQUEUE
629 *
630 * This mode is controlled by having the client pass the MAC_TX_NO_ENQUEUE flag.
631 * If the MAC_DROP_ON_NO_DESC flag is also passed, it takes precedence. In this
632 * mode, when we hit a case where a driver runs out of transmit descriptors,
633 * then instead of enqueuing packets in a soft ring set or software ring, we
634 * instead return the mblk_t chain back to the caller and immediately put the
635 * soft ring set into flow control mode.
636 *
637 * The following series of ASCII art images describe the transmit data path that
638 * MAC clients enter into based on calling into mac_tx(). A soft ring set has a
639 * transmission function associated with it. There are seven possible
640 * transmission modes, some of which share function entry points. The one that a
641 * soft ring set gets depends on properties such as whether there are
642 * transmission rings for fanout, whether the device involves aggregations,
643 * whether any bandwidth limits exist, etc.
644 *
645 *
646 * Part 1 -- Initial checks
647 *
648 * * . called by
649 * | MAC clients
650 * v . . No
651 * +--------+ +-----------+ . +-------------------+ +====================+
652 * | mac_tx |->| device |-*-->| mac_protect_check |->v Is this the simple v
653 * +--------+ | quiesced? | +-------------------+ v case? See [1] v
654 * +-----------+ | +====================+
655 * * . Yes * failed |
656 * v | frames |
657 * +--------------+ | +-------+---------+
658 * | freemsgchain |<---------+ Yes . * No . *
659 * +--------------+ v v
660 * +-----------+ +--------+
661 * | goto | | goto |
662 * | Part 2 | | SRS TX |
663 * | Entry [A] | | func |
664 * +-----------+ +--------+
665 * | |
666 * | v
667 * | +--------+
668 * +---------->| return |
669 * | cookie |
670 * +--------+
671 *
672 * [1] The simple case refers to the SRS being configured with the
673 * SRS_TX_DEFAULT transmission mode, having a single mblk_t (not a chain), their
674 * being only a single active client, and not having a backlog in the srs.
675 *
676 *
677 * Part 2 -- The SRS transmission functions
678 *
679 * This part is a bit more complicated. The different transmission paths often
680 * leverage one another. In this case, we'll draw out the more common ones
681 * before the parts that depend upon them. Here, we're going to start with the
682 * workings of mac_tx_send() a common function that most of the others end up
683 * calling.
684 *
685 * +-------------+
686 * | mac_tx_send |
687 * +-------------+
688 * |
689 * v
690 * +=============+ +==============+
691 * v more than v--->v check v
692 * v one client? v v VLAN and add v
693 * +=============+ v VLAN tags v
694 * | +==============+
695 * | |
696 * +------------------+
697 * |
698 * | [A]
699 * v |
700 * +============+ . No v
701 * v more than v . +==========+ +--------------------------+
702 * v one active v-*---->v for each v---->| mac_promisc_dispatch_one |---+
703 * v client? v v mblk_t v +--------------------------+ |
704 * +============+ +==========+ ^ |
705 * | | +==========+ |
706 * * . Yes | v hardware v<-------+
707 * v +------------+ v rings? v
708 * +==========+ | +==========+
709 * v for each v No . . . * |
710 * v mblk_t v specific | |
711 * +==========+ flow | +-----+-----+
712 * | | | |
713 * v | v v
714 * +-----------------+ | +-------+ +---------+
715 * | mac_tx_classify |------------+ | GLDv3 | | GLDv3 |
716 * +-----------------+ |TX func| | ring tx |
717 * | +-------+ | func |
718 * * Specific flow, generally | +---------+
719 * | bcast, mcast, loopback | |
720 * v +-----+-----+
721 * +==========+ +---------+ |
722 * v valid L2 v--*--->| freemsg | v
723 * v header v . No +---------+ +-------------------+
724 * +==========+ | return unconsumed |
725 * * . Yes | frames to the |
726 * v | caller |
727 * +===========+ +-------------------+
728 * v braodcast v +----------------+ ^
729 * v flow? v--*-->| mac_bcast_send |------------------+
730 * +===========+ . +----------------+ |
731 * | . . Yes |
732 * No . * v
733 * | +---------------------+ +---------------+ +----------+
734 * +->|mac_promisc_dispatch |->| mac_fix_cksum |->| flow |
735 * +---------------------+ +---------------+ | callback |
736 * +----------+
737 *
738 *
739 * In addition, many but not all of the routines, all rely on
740 * mac_tx_softring_process as an entry point.
741 *
742 *
743 * . No . No
744 * +--------------------------+ +========+ . +===========+ . +-------------+
745 * | mac_tx_soft_ring_process |-->v worker v-*->v out of tx v-*->| goto |
746 * +--------------------------+ v only? v v descr.? v | mac_tx_send |
747 * +========+ +===========+ +-------------+
748 * Yes . * * . Yes |
749 * . No v | v
750 * v=========+ . +===========+ . Yes | Yes . +==========+
751 * v apppend v<--*----------v out of tx v-*-------+---------*--v returned v
752 * v mblk_t v v descr.? v | v frames? v
753 * v chain v +===========+ | +==========+
754 * +=========+ | *. No
755 * | | v
756 * v v +------------+
757 * +===================+ +----------------------+ | done |
758 * v worker scheduled? v | mac_tx_sring_enqueue | | processing |
759 * v Out of tx descr? v +----------------------+ +------------+
760 * +===================+ |
761 * | | . Yes v
762 * * Yes * No . +============+
763 * | v +-*---------v drop on no v
764 * | +========+ v v TX desc? v
765 * | v wake v +----------+ +============+
766 * | v worker v | mac_pkt_ | * . No
767 * | +========+ | drop | | . Yes . No
768 * | | +----------+ v . .
769 * | | v ^ +===============+ . +========+ .
770 * +--+--------+---------+ | v Don't enqueue v-*->v ring v-*----+
771 * | | v Set? v v empty? v |
772 * | +---------------+ +===============+ +========+ |
773 * | | | | |
774 * | | +-------------------+ | |
775 * | *. Yes | +---------+ |
776 * | | v v v
777 * | | +===========+ +========+ +--------------+
778 * | +<-v At hiwat? v v append v | return |
779 * | +===========+ v mblk_t v | mblk_t chain |
780 * | * No v chain v | and flow |
781 * | v +========+ | control |
782 * | +=========+ | | cookie |
783 * | v append v v +--------------+
784 * | v mblk_t v +========+
785 * | v chain v v wake v +------------+
786 * | +=========+ v worker v-->| done |
787 * | | +========+ | processing |
788 * | v .. Yes +------------+
789 * | +=========+ . +========+
790 * | v first v--*-->v wake v
791 * | v append? v v worker v
792 * | +=========+ +========+
793 * | | |
794 * | No . * |
795 * | v |
796 * | +--------------+ |
797 * +------>| Return | |
798 * | flow control |<------------+
799 * | cookie |
800 * +--------------+
801 *
802 *
803 * The remaining images are all specific to each of the different transmission
804 * modes.
805 *
806 * SRS TX DEFAULT
807 *
808 * [ From Part 1 ]
809 * |
810 * v
811 * +-------------------------+
812 * | mac_tx_single_ring_mode |
813 * +-------------------------+
814 * |
815 * | . Yes
816 * v .
817 * +==========+ . +============+
818 * v SRS v-*->v Try to v---->---------------------+
819 * v backlog? v v enqueue in v |
820 * +==========+ v SRS v-->------+ * . . Queue too
821 * | +============+ * don't enqueue | deep or
822 * * . No ^ | | flag or at | drop flag
823 * | | v | hiwat, |
824 * v | | | return +---------+
825 * +-------------+ | | | cookie | freemsg |
826 * | goto |-*-----+ | | +---------+
827 * | mac_tx_send | . returned | | |
828 * +-------------+ mblk_t | | |
829 * | | | |
830 * | | | |
831 * * . . all mblk_t * queued, | |
832 * v consumed | may return | |
833 * +-------------+ | tx cookie | |
834 * | SRS TX func |<------------+------------+----------------+
835 * | completed |
836 * +-------------+
837 *
838 * SRS_TX_SERIALIZE
839 *
840 * +------------------------+
841 * | mac_tx_serializer_mode |
842 * +------------------------+
843 * |
844 * | . No
845 * v .
846 * +============+ . +============+ +-------------+ +============+
847 * v srs being v-*->v set SRS v--->| goto |-->v remove SRS v
848 * v processed? v v proc flags v | mac_tx_send | v proc flag v
849 * +============+ +============+ +-------------+ +============+
850 * | |
851 * * Yes |
852 * v . No v
853 * +--------------------+ . +==========+
854 * | mac_tx_srs_enqueue | +------------------------*-----<--v returned v
855 * +--------------------+ | v frames? v
856 * | | . Yes +==========+
857 * | | . |
858 * | | . +=========+ v
859 * v +-<-*-v queued v +--------------------+
860 * +-------------+ | v frames? v<----| mac_tx_srs_enqueue |
861 * | SRS TX func | | +=========+ +--------------------+
862 * | completed, |<------+ * . Yes
863 * | may return | | v
864 * | cookie | | +========+
865 * +-------------+ +-<---v wake v
866 * v worker v
867 * +========+
868 *
869 *
870 * SRS_TX_FANOUT
871 *
872 * . Yes
873 * +--------------------+ +=============+ . +--------------------------+
874 * | mac_tx_fanout_mode |--->v Have fanout v-*-->| goto |
875 * +--------------------+ v hint? v | mac_rx_soft_ring_process |
876 * +=============+ +--------------------------+
877 * * . No |
878 * v ^
879 * +===========+ |
880 * +--->v for each v +===============+
881 * | v mblk_t v v pick softring v
882 * same * +===========+ v from hash v
883 * hash | | +===============+
884 * | v |
885 * | +--------------+ |
886 * +---| mac_pkt_hash |--->*------------+
887 * +--------------+ . different
888 * hash or
889 * done proc.
890 * SRS_TX_AGGR chain
891 *
892 * +------------------+ +================================+
893 * | mac_tx_aggr_mode |--->v Use aggr capab function to v
894 * +------------------+ v find appropriate tx ring. v
895 * v Applies hash based on aggr v
896 * v policy, see mac_tx_aggr_mode() v
897 * +================================+
898 * |
899 * v
900 * +-------------------------------+
901 * | goto |
902 * | mac_rx_srs_soft_ring_process |
903 * +-------------------------------+
904 *
905 *
906 * SRS_TX_BW, SRS_TX_BW_FANOUT, SRS_TX_BW_AGGR
907 *
908 * Note, all three of these tx functions start from the same place --
909 * mac_tx_bw_mode().
910 *
911 * +----------------+
912 * | mac_tx_bw_mode |
913 * +----------------+
914 * |
915 * v . No . No . Yes
916 * +==============+ . +============+ . +=============+ . +=========+
917 * v Out of BW? v--*->v SRS empty? v--*->v reset BW v-*->v Bump BW v
918 * +==============+ +============+ v tick count? v v Usage v
919 * | | +=============+ +=========+
920 * | +---------+ | |
921 * | | +--------------------+ |
922 * | | | +----------------------+
923 * v | v v
924 * +===============+ | +==========+ +==========+ +------------------+
925 * v Don't enqueue v | v set bw v v Is aggr? v--*-->| goto |
926 * v flag set? v | v enforced v +==========+ . | mac_tx_aggr_mode |-+
927 * +===============+ | +==========+ | . +------------------+ |
928 * | Yes .* | | No . * . |
929 * | | | | | . Yes |
930 * * . No | | v | |
931 * | +---------+ | +========+ v +======+ |
932 * | | freemsg | | v append v +============+ . Yes v pick v |
933 * | +---------+ | v mblk_t v v Is fanout? v--*---->v ring v |
934 * | | | v chain v +============+ +======+ |
935 * +------+ | +========+ | | |
936 * v | | v v |
937 * +---------+ | v +-------------+ +--------------------+ |
938 * | return | | +========+ | goto | | goto | |
939 * | flow | | v wakeup v | mac_tx_send | | mac_tx_fanout_mode | |
940 * | control | | v worker v +-------------+ +--------------------+ |
941 * | cookie | | +========+ | | |
942 * +---------+ | | | +------+------+
943 * | v | |
944 * | +---------+ | v
945 * | | return | +============+ +------------+
946 * | | flow | v unconsumed v-------+ | done |
947 * | | control | v frames? v | | processing |
948 * | | cookie | +============+ | +------------+
949 * | +---------+ | |
950 * | Yes * |
951 * | | |
952 * | +===========+ |
953 * | v subtract v |
954 * | v unused bw v |
955 * | +===========+ |
956 * | | |
957 * | v |
958 * | +--------------------+ |
959 * +------------->| mac_tx_srs_enqueue | |
960 * +--------------------+ |
961 * | |
962 * | |
963 * +------------+ |
964 * | return fc | |
965 * | cookie and |<------+
966 * | mblk_t |
967 * +------------+
968 */
970 #include <sys/types.h>
971 #include <sys/callb.h>
972 #include <sys/sdt.h>
973 #include <sys/strsubr.h>
974 #include <sys/strsun.h>
975 #include <sys/vlan.h>
976 #include <sys/stack.h>
977 #include <sys/archsystm.h>
978 #include <inet/ipsec_impl.h>
979 #include <inet/ip_impl.h>
980 #include <inet/sadb.h>
981 #include <inet/ipsecesp.h>
982 #include <inet/ipsecah.h>
983 #include <inet/ip6.h>
985 #include <sys/mac_impl.h>
986 #include <sys/mac_client_impl.h>
987 #include <sys/mac_client_priv.h>
988 #include <sys/mac_soft_ring.h>
989 #include <sys/mac_flow_impl.h>
1003 mac_tx_srs_mode_t mac_tx_mode;
1004 mac_tx_func_t mac_tx_func;
1007 /*
1008 * There are seven modes of operation on the Tx side. These modes get set
1009 * in mac_tx_srs_setup(). Except for the experimental TX_SERIALIZE mode,
1010 * none of the other modes are user configurable. They get selected by
1011 * the system depending upon whether the link (or flow) has multiple Tx
1012 * rings or a bandwidth configured, or if the link is an aggr, etc.
1013 *
1014 * When the Tx SRS is operating in aggr mode (st_mode) or if there are
1015 * multiple Tx rings owned by Tx SRS, then each Tx ring (pseudo or
1016 * otherwise) will have a soft ring associated with it. These soft rings
1017 * are stored in srs_tx_soft_rings[] array.
1018 *
1019 * Additionally in the case of aggr, there is the st_soft_rings[] array
1020 * in the mac_srs_tx_t structure. This array is used to store the same
1021 * set of soft rings that are present in srs_tx_soft_rings[] array but
1022 * in a different manner. The soft ring associated with the pseudo Tx
1023 * ring is saved at mr_index (of the pseudo ring) in st_soft_rings[]
1024 * array. This helps in quickly getting the soft ring associated with the
1025 * Tx ring when aggr_find_tx_ring() returns the pseudo Tx ring that is to
1026 * be used for transmit.
1027 */
1028 mac_tx_mode_t mac_tx_mode_list[] = {
1036 };
1038 /*
1039 * Soft Ring Set (SRS) - The Run time code that deals with
1040 * dynamic polling from the hardware, bandwidth enforcement,
1041 * fanout etc.
1042 *
1043 * We try to use H/W classification on NIC and assign traffic for
1044 * a MAC address to a particular Rx ring or ring group. There is a
1045 * 1-1 mapping between a SRS and a Rx ring. The SRS dynamically
1046 * switches the underlying Rx ring between interrupt and
1047 * polling mode and enforces any specified B/W control.
1048 *
1049 * There is always a SRS created and tied to each H/W and S/W rule.
1050 * Whenever we create a H/W rule, we always add the the same rule to
1051 * S/W classifier and tie a SRS to it.
1052 *
1053 * In case a B/W control is specified, it is broken into bytes
1054 * per ticks and as soon as the quota for a tick is exhausted,
1055 * the underlying Rx ring is forced into poll mode for remainder of
1056 * the tick. The SRS poll thread only polls for bytes that are
1057 * allowed to come in the SRS. We typically let 4x the configured
1058 * B/W worth of packets to come in the SRS (to prevent unnecessary
1059 * drops due to bursts) but only process the specified amount.
1060 *
1061 * A MAC client (e.g. a VNIC or aggr) can have 1 or more
1062 * Rx rings (and corresponding SRSs) assigned to it. The SRS
1063 * in turn can have softrings to do protocol level fanout or
1064 * softrings to do S/W based fanout or both. In case the NIC
1065 * has no Rx rings, we do S/W classification to respective SRS.
1066 * The S/W classification rule is always setup and ready. This
1067 * allows the MAC layer to reassign Rx rings whenever needed
1068 * but packets still continue to flow via the default path and
1069 * getting S/W classified to correct SRS.
1070 *
1071 * The SRS's are used on both Tx and Rx side. They use the same
1072 * data structure but the processing routines have slightly different
1073 * semantics due to the fact that Rx side needs to do dynamic
1074 * polling etc.
1075 *
1076 * Dynamic Polling Notes
1077 * =====================
1078 *
1079 * Each Soft ring set is capable of switching its Rx ring between
1080 * interrupt and poll mode and actively 'polls' for packets in
1081 * poll mode. If the SRS is implementing a B/W limit, it makes
1082 * sure that only Max allowed packets are pulled in poll mode
1083 * and goes to poll mode as soon as B/W limit is exceeded. As
1084 * such, there are no overheads to implement B/W limits.
1085 *
1086 * In poll mode, its better to keep the pipeline going where the
1087 * SRS worker thread keeps processing packets and poll thread
1088 * keeps bringing more packets (specially if they get to run
1089 * on different CPUs). This also prevents the overheads associated
1090 * by excessive signalling (on NUMA machines, this can be
1091 * pretty devastating). The exception is latency optimized case
1092 * where worker thread does no work and interrupt and poll thread
1093 * are allowed to do their own drain.
1094 *
1095 * We use the following policy to control Dynamic Polling:
1096 * 1) We switch to poll mode anytime the processing
1097 * thread causes a backlog to build up in SRS and
1098 * its associated Soft Rings (sr_poll_pkt_cnt > 0).
1099 * 2) As long as the backlog stays under the low water
1100 * mark (sr_lowat), we poll the H/W for more packets.
1101 * 3) If the backlog (sr_poll_pkt_cnt) exceeds low
1102 * water mark, we stay in poll mode but don't poll
1103 * the H/W for more packets.
1104 * 4) Anytime in polling mode, if we poll the H/W for
1105 * packets and find nothing plus we have an existing
1106 * backlog (sr_poll_pkt_cnt > 0), we stay in polling
1107 * mode but don't poll the H/W for packets anymore
1108 * (let the polling thread go to sleep).
1109 * 5) Once the backlog is relived (packets are processed)
1110 * we reenable polling (by signalling the poll thread)
1111 * only when the backlog dips below sr_poll_thres.
1112 * 6) sr_hiwat is used exclusively when we are not
1113 * polling capable and is used to decide when to
1114 * drop packets so the SRS queue length doesn't grow
1115 * infinitely.
1116 *
1117 * NOTE: Also see the block level comment on top of mac_soft_ring.c
1118 */
1120 /*
1121 * mac_latency_optimize
1122 *
1123 * Controls whether the poll thread can process the packets inline
1124 * or let the SRS worker thread do the processing. This applies if
1125 * the SRS was not being processed. For latency sensitive traffic,
1126 * this needs to be true to allow inline processing. For throughput
1127 * under load, this should be false.
1128 *
1129 * This (and other similar) tunable should be rolled into a link
1130 * or flow specific workload hint that can be set using dladm
1131 * linkprop (instead of multiple such tunables).
1132 */
1135 /*
1136 * MAC_RX_SRS_ENQUEUE_CHAIN and MAC_TX_SRS_ENQUEUE_CHAIN
1137 *
1138 * queue a mp or chain in soft ring set and increment the
1139 * local count (srs_count) for the SRS and the shared counter
1140 * (srs_poll_pkt_cnt - shared between SRS and its soft rings
1141 * to track the total unprocessed packets for polling to work
1142 * correctly).
1143 *
1144 * The size (total bytes queued) counters are incremented only
1145 * if we are doing B/W control.
1146 */
1147 #define MAC_SRS_ENQUEUE_CHAIN(mac_srs, head, tail, count, sz) { \
1148 ASSERT(MUTEX_HELD(&(mac_srs)->srs_lock)); \
1149 if ((mac_srs)->srs_last != NULL) \
1150 (mac_srs)->srs_last->b_next = (head); \
1151 else \
1152 (mac_srs)->srs_first = (head); \
1153 (mac_srs)->srs_last = (tail); \
1154 (mac_srs)->srs_count += count; \
1155 }
1157 #define MAC_RX_SRS_ENQUEUE_CHAIN(mac_srs, head, tail, count, sz) { \
1158 mac_srs_rx_t *srs_rx = &(mac_srs)->srs_rx; \
1159 \
1160 MAC_SRS_ENQUEUE_CHAIN(mac_srs, head, tail, count, sz); \
1161 srs_rx->sr_poll_pkt_cnt += count; \
1162 ASSERT(srs_rx->sr_poll_pkt_cnt > 0); \
1163 if ((mac_srs)->srs_type & SRST_BW_CONTROL) { \
1164 (mac_srs)->srs_size += (sz); \
1165 mutex_enter(&(mac_srs)->srs_bw->mac_bw_lock); \
1166 (mac_srs)->srs_bw->mac_bw_sz += (sz); \
1167 mutex_exit(&(mac_srs)->srs_bw->mac_bw_lock); \
1168 } \
1169 }
1171 #define MAC_TX_SRS_ENQUEUE_CHAIN(mac_srs, head, tail, count, sz) { \
1172 mac_srs->srs_state |= SRS_ENQUEUED; \
1173 MAC_SRS_ENQUEUE_CHAIN(mac_srs, head, tail, count, sz); \
1174 if ((mac_srs)->srs_type & SRST_BW_CONTROL) { \
1175 (mac_srs)->srs_size += (sz); \
1176 (mac_srs)->srs_bw->mac_bw_sz += (sz); \
1177 } \
1178 }
1180 /*
1181 * Turn polling on routines
1182 */
1183 #define MAC_SRS_POLLING_ON(mac_srs) { \
1184 ASSERT(MUTEX_HELD(&(mac_srs)->srs_lock)); \
1185 if (((mac_srs)->srs_state & \
1186 (SRS_POLLING_CAPAB|SRS_POLLING)) == SRS_POLLING_CAPAB) { \
1187 (mac_srs)->srs_state |= SRS_POLLING; \
1188 (void) mac_hwring_disable_intr((mac_ring_handle_t) \
1189 (mac_srs)->srs_ring); \
1190 (mac_srs)->srs_rx.sr_poll_on++; \
1191 } \
1192 }
1194 #define MAC_SRS_WORKER_POLLING_ON(mac_srs) { \
1195 ASSERT(MUTEX_HELD(&(mac_srs)->srs_lock)); \
1196 if (((mac_srs)->srs_state & \
1197 (SRS_POLLING_CAPAB|SRS_WORKER|SRS_POLLING)) == \
1198 (SRS_POLLING_CAPAB|SRS_WORKER)) { \
1199 (mac_srs)->srs_state |= SRS_POLLING; \
1200 (void) mac_hwring_disable_intr((mac_ring_handle_t) \
1201 (mac_srs)->srs_ring); \
1202 (mac_srs)->srs_rx.sr_worker_poll_on++; \
1203 } \
1204 }
1206 /*
1207 * MAC_SRS_POLL_RING
1208 *
1209 * Signal the SRS poll thread to poll the underlying H/W ring
1210 * provided it wasn't already polling (SRS_GET_PKTS was set).
1211 *
1212 * Poll thread gets to run only from mac_rx_srs_drain() and only
1213 * if the drain was being done by the worker thread.
1214 */
1215 #define MAC_SRS_POLL_RING(mac_srs) { \
1216 mac_srs_rx_t *srs_rx = &(mac_srs)->srs_rx; \
1217 \
1218 ASSERT(MUTEX_HELD(&(mac_srs)->srs_lock)); \
1219 srs_rx->sr_poll_thr_sig++; \
1220 if (((mac_srs)->srs_state & \
1221 (SRS_POLLING_CAPAB|SRS_WORKER|SRS_GET_PKTS)) == \
1222 (SRS_WORKER|SRS_POLLING_CAPAB)) { \
1223 (mac_srs)->srs_state |= SRS_GET_PKTS; \
1224 cv_signal(&(mac_srs)->srs_cv); \
1225 } else { \
1226 srs_rx->sr_poll_thr_busy++; \
1227 } \
1228 }
1230 /*
1231 * MAC_SRS_CHECK_BW_CONTROL
1232 *
1233 * Check to see if next tick has started so we can reset the
1234 * SRS_BW_ENFORCED flag and allow more packets to come in the
1235 * system.
1236 */
1237 #define MAC_SRS_CHECK_BW_CONTROL(mac_srs) { \
1238 ASSERT(MUTEX_HELD(&(mac_srs)->srs_lock)); \
1239 ASSERT(((mac_srs)->srs_type & SRST_TX) || \
1240 MUTEX_HELD(&(mac_srs)->srs_bw->mac_bw_lock)); \
1241 clock_t now = ddi_get_lbolt(); \
1242 if ((mac_srs)->srs_bw->mac_bw_curr_time != now) { \
1243 (mac_srs)->srs_bw->mac_bw_curr_time = now; \
1244 (mac_srs)->srs_bw->mac_bw_used = 0; \
1245 if ((mac_srs)->srs_bw->mac_bw_state & SRS_BW_ENFORCED) \
1246 (mac_srs)->srs_bw->mac_bw_state &= ~SRS_BW_ENFORCED; \
1247 } \
1248 }
1250 /*
1251 * MAC_SRS_WORKER_WAKEUP
1252 *
1253 * Wake up the SRS worker thread to process the queue as long as
1254 * no one else is processing the queue. If we are optimizing for
1255 * latency, we wake up the worker thread immediately or else we
1256 * wait mac_srs_worker_wakeup_ticks before worker thread gets
1257 * woken up.
1258 */
1260 #define MAC_SRS_WORKER_WAKEUP(mac_srs) { \
1261 ASSERT(MUTEX_HELD(&(mac_srs)->srs_lock)); \
1262 if (!((mac_srs)->srs_state & SRS_PROC) && \
1263 (mac_srs)->srs_tid == NULL) { \
1264 if (((mac_srs)->srs_state & SRS_LATENCY_OPT) || \
1265 (mac_srs_worker_wakeup_ticks == 0)) \
1266 cv_signal(&(mac_srs)->srs_async); \
1267 else \
1268 (mac_srs)->srs_tid = \
1269 timeout(mac_srs_fire, (mac_srs), \
1270 mac_srs_worker_wakeup_ticks); \
1271 } \
1272 }
1274 #define TX_BANDWIDTH_MODE(mac_srs) \
1275 ((mac_srs)->srs_tx.st_mode == SRS_TX_BW || \
1276 (mac_srs)->srs_tx.st_mode == SRS_TX_BW_FANOUT || \
1277 (mac_srs)->srs_tx.st_mode == SRS_TX_BW_AGGR)
1279 #define TX_SRS_TO_SOFT_RING(mac_srs, head, hint) { \
1280 if (tx_mode == SRS_TX_BW_FANOUT) \
1281 (void) mac_tx_fanout_mode(mac_srs, head, hint, 0, NULL);\
1282 else \
1283 (void) mac_tx_aggr_mode(mac_srs, head, hint, 0, NULL); \
1284 }
1286 /*
1287 * MAC_TX_SRS_BLOCK
1288 *
1289 * Always called from mac_tx_srs_drain() function. SRS_TX_BLOCKED
1290 * will be set only if srs_tx_woken_up is FALSE. If
1291 * srs_tx_woken_up is TRUE, it indicates that the wakeup arrived
1292 * before we grabbed srs_lock to set SRS_TX_BLOCKED. We need to
1293 * attempt to transmit again and not setting SRS_TX_BLOCKED does
1294 * that.
1295 */
1296 #define MAC_TX_SRS_BLOCK(srs, mp) { \
1297 ASSERT(MUTEX_HELD(&(srs)->srs_lock)); \
1298 if ((srs)->srs_tx.st_woken_up) { \
1299 (srs)->srs_tx.st_woken_up = B_FALSE; \
1300 } else { \
1301 ASSERT(!((srs)->srs_state & SRS_TX_BLOCKED)); \
1302 (srs)->srs_state |= SRS_TX_BLOCKED; \
1303 (srs)->srs_tx.st_stat.mts_blockcnt++; \
1304 } \
1305 }
1307 /*
1308 * MAC_TX_SRS_TEST_HIWAT
1309 *
1310 * Called before queueing a packet onto Tx SRS to test and set
1311 * SRS_TX_HIWAT if srs_count exceeds srs_tx_hiwat.
1312 */
1313 #define MAC_TX_SRS_TEST_HIWAT(srs, mp, tail, cnt, sz, cookie) { \
1314 boolean_t enqueue = 1; \
1315 \
1316 if ((srs)->srs_count > (srs)->srs_tx.st_hiwat) { \
1317 /* \
1318 * flow-controlled. Store srs in cookie so that it \
1319 * can be returned as mac_tx_cookie_t to client \
1321 (srs)->srs_state |= SRS_TX_HIWAT; \
1322 cookie = (mac_tx_cookie_t)srs; \
1323 (srs)->srs_tx.st_hiwat_cnt++; \
1324 if ((srs)->srs_count > (srs)->srs_tx.st_max_q_cnt) { \
1326 (srs)->srs_tx.st_stat.mts_sdrops += cnt; \
1327 /* \
1328 * b_prev may be set to the fanout hint \
1329 * hence can't use freemsg directly \
1331 mac_pkt_drop(NULL, NULL, mp_chain, B_FALSE); \
1332 DTRACE_PROBE1(tx_queued_hiwat, \
1333 mac_soft_ring_set_t *, srs); \
1334 enqueue = 0; \
1335 } \
1336 } \
1337 if (enqueue) \
1338 MAC_TX_SRS_ENQUEUE_CHAIN(srs, mp, tail, cnt, sz); \
1339 }
1341 /* Some utility macros */
1342 #define MAC_SRS_BW_LOCK(srs) \
1343 if (!(srs->srs_type & SRST_TX)) \
1344 mutex_enter(&srs->srs_bw->mac_bw_lock);
1346 #define MAC_SRS_BW_UNLOCK(srs) \
1347 if (!(srs->srs_type & SRST_TX)) \
1348 mutex_exit(&srs->srs_bw->mac_bw_lock);
1350 #define MAC_TX_SRS_DROP_MESSAGE(srs, mp, cookie) { \
1351 mac_pkt_drop(NULL, NULL, mp, B_FALSE); \
1353 mac_srs->srs_tx.st_stat.mts_sdrops++; \
1354 cookie = (mac_tx_cookie_t)srs; \
1355 }
1357 #define MAC_TX_SET_NO_ENQUEUE(srs, mp_chain, ret_mp, cookie) { \
1358 mac_srs->srs_state |= SRS_TX_WAKEUP_CLIENT; \
1359 cookie = (mac_tx_cookie_t)srs; \
1360 *ret_mp = mp_chain; \
1361 }
1363 /*
1364 * MAC_RX_SRS_TOODEEP
1365 *
1366 * Macro called as part of receive-side processing to determine if handling
1367 * can occur in situ (in the interrupt thread) or if it should be left to a
1368 * worker thread. Note that the constant used to make this determination is
1369 * not entirely made-up, and is a result of some emprical validation. That
1370 * said, the constant is left as a static variable to allow it to be
1371 * dynamically tuned in the field if and as needed.
1372 */
1376 #ifndef STACK_GROWTH_DOWN
1377 #error Downward stack growth assumed.
1378 #endif
1380 #define MAC_RX_SRS_TOODEEP() (STACK_BIAS + (uintptr_t)getfp() - \
1381 (uintptr_t)curthread->t_stkbase < mac_rx_srs_stack_needed && \
1382 ++mac_rx_srs_stack_toodeep)
1385 /*
1386 * Drop the rx packet and advance to the next one in the chain.
1387 */
1388 static void
1390 {
1401 }
1403 /* DATAPATH RUNTIME ROUTINES */
1405 /*
1406 * mac_srs_fire
1407 *
1408 * Timer callback routine for waking up the SRS worker thread.
1409 */
1410 static void
1412 {
1419 }
1426 }
1428 /*
1429 * 'hint' is fanout_hint (type of uint64_t) which is given by the TCP/IP stack,
1430 * and it is used on the TX path.
1431 */
1432 #define HASH_HINT(hint) \
1433 ((hint) ^ ((hint) >> 24) ^ ((hint) >> 16) ^ ((hint) >> 8))
1436 /*
1437 * hash based on the src address, dst address and the port information.
1438 */
1439 #define HASH_ADDR(src, dst, ports) \
1440 (ntohl((src) + (dst)) ^ ((ports) >> 24) ^ ((ports) >> 16) ^ \
1441 ((ports) >> 8) ^ (ports))
1443 #define COMPUTE_INDEX(key, sz) (key % sz)
1445 #define FANOUT_ENQUEUE_MP(head, tail, cnt, bw_ctl, sz, sz0, mp) { \
1446 if ((tail) != NULL) { \
1447 ASSERT((tail)->b_next == NULL); \
1448 (tail)->b_next = (mp); \
1449 } else { \
1450 ASSERT((head) == NULL); \
1451 (head) = (mp); \
1452 } \
1453 (tail) = (mp); \
1454 (cnt)++; \
1455 if ((bw_ctl)) \
1456 (sz) += (sz0); \
1457 }
1459 #define MAC_FANOUT_DEFAULT 0
1460 #define MAC_FANOUT_RND_ROBIN 1
1463 #define MAX_SR_TYPES 3
1464 /* fanout types for port based hashing */
1467 V4_UDP,
1468 OTH,
1469 UNDEF
1470 };
1472 /*
1473 * Pair of local and remote ports in the transport header
1474 */
1475 #define PORTS_SIZE 4
1477 /*
1478 * mac_rx_srs_proto_fanout
1479 *
1480 * This routine delivers packets destined to an SRS into one of the
1481 * protocol soft rings.
1482 *
1483 * Given a chain of packets we need to split it up into multiple sub chains
1484 * destined into TCP, UDP or OTH soft ring. Instead of entering
1485 * the soft ring one packet at a time, we want to enter it in the form of a
1486 * chain otherwise we get this start/stop behaviour where the worker thread
1487 * goes to sleep and then next packets comes in forcing it to wake up etc.
1488 */
1489 static void
1491 {
1504 boolean_t bw_ctl;
1505 boolean_t hw_classified;
1506 boolean_t dls_bypass;
1507 boolean_t is_ether;
1508 boolean_t is_unicast;
1515 /*
1516 * If we don't have a Rx ring, S/W classification would have done
1517 * its job and its a packet meant for us. If we were polling on
1518 * the default ring (i.e. there was a ring assigned to this SRS),
1519 * then we need to make sure that the mac address really belongs
1520 * to us.
1521 */
1525 /*
1526 * Special clients (eg. VLAN, non ether, etc) need DLS
1527 * processing in the Rx path. SRST_DLS_BYPASS will be clear for
1528 * such SRSs. Another way of disabling bypass is to set the
1529 * MCIS_RX_BYPASS_DISABLE flag.
1530 */
1539 /*
1540 * We got a chain from SRS that we need to send to the soft rings.
1541 * Since squeues for TCP & IPv4 sap poll their soft rings (for
1542 * performance reasons), we need to separate out v4_tcp, v4_udp
1543 * and the rest goes in other.
1544 */
1554 /*
1555 * At this point we can be sure the packet at least
1556 * has an ether header.
1557 */
1561 }
1564 /*
1565 * Determine if this is a VLAN or non-VLAN packet.
1566 */
1571 /*
1572 * Check if the VID of the packet, if any,
1573 * belongs to this client.
1574 */
1579 }
1582 }
1583 is_unicast =
1587 mac_header_info_t mhi;
1593 }
1598 }
1604 }
1607 /*
1608 * If we are H/W classified, but we have promisc
1609 * on, then we need to check for the unicast address.
1610 */
1622 }
1623 }
1625 /*
1626 * This needs to become a contract with the driver for
1627 * the fast path.
1628 *
1629 * In the normal case the packet will have at least the L2
1630 * header and the IP + Transport header in the same mblk.
1631 * This is usually the case when the NIC driver sends up
1632 * the packet. This is also true when the stack generates
1633 * a packet that is looped back and when the stack uses the
1634 * fastpath mechanism. The normal case is optimized for
1635 * performance and may bypass DLS. All other cases go through
1636 * the 'OTH' type path without DLS bypass.
1637 */
1647 }
1650 /*
1651 * We look for at least 4 bytes past the IP header to get
1652 * the port information. If we get an IP fragment, we don't
1653 * have the port information, and we use just the protocol
1654 * information.
1655 */
1668 }
1672 }
1688 }
1691 }
1692 }
1693 }
1697 /*
1698 * mac_rx_srs_long_fanout
1699 *
1700 * The fanout routine for VLANs, and for anything else that isn't performing
1701 * explicit dls bypass. Returns -1 on an error (drop the packet due to a
1702 * malformed packet), 0 on success, with values written in *indx and *type.
1703 */
1704 static int
1707 {
1711 uint_t hash;
1717 boolean_t v6;
1731 }
1737 /*
1738 * The first mblk_t only includes the mac header.
1739 * Note that it is safe to change the mp pointer here,
1740 * as the subsequent operation does not assume mp
1741 * points to the start of the mac header.
1742 */
1745 /*
1746 * Make sure the IP header points to an entire one.
1747 */
1756 }
1760 }
1764 /*
1765 * If either the IP header is not aligned, or it does not hold
1766 * the complete simple structure (a pullupmsg() is not an
1767 * option since it would result in an unaligned IP header),
1768 * fanout to the default ring.
1769 *
1770 * Note that this may cause packet reordering.
1771 */
1774 fanout_unaligned++;
1776 }
1778 /*
1779 * Extract next-header, full header length, and source-hash value
1780 * using v4/v6 specific fields.
1781 */
1787 /*
1788 * Do src based fanout if below tunable is set to B_TRUE or
1789 * when mac_ip_hdr_length_v6() fails because of malformed
1790 * packets or because mblks need to be concatenated using
1791 * pullupmsg().
1792 *
1793 * Perform a version check to prevent parsing weirdness...
1794 */
1797 NULL)) {
1799 }
1806 /*
1807 * Catch IPv4 fragment case here. IPv6 has nexthdr == FRAG
1808 * for its equivalent case.
1809 */
1813 }
1814 }
1819 /* If the transport is one of below, we do port/SPI based fanout */
1825 /*
1826 * If the ports or SPI in the transport header is not part of
1827 * the mblk, do src_based_fanout, instead of calling
1828 * pullupmsg().
1829 */
1832 /* FALLTHRU */
1835 }
1854 }
1857 }
1860 src_dst_based_fanout:
1865 }
1867 /*
1868 * mac_rx_srs_fanout
1869 *
1870 * This routine delivers packets destined to an SRS into a soft ring member
1871 * of the set.
1872 *
1873 * Given a chain of packets we need to split it up into multiple sub chains
1874 * destined for one of the TCP, UDP or OTH soft rings. Instead of entering
1875 * the soft ring one packet at a time, we want to enter it in the form of a
1876 * chain otherwise we get this start/stop behaviour where the worker thread
1877 * goes to sleep and then next packets comes in forcing it to wake up etc.
1878 *
1879 * Note:
1880 * Since we know what is the maximum fanout possible, we create a 2D array
1881 * of 'softring types * MAX_SR_FANOUT' for the head, tail, cnt and sz
1882 * variables so that we can enter the softrings with chain. We need the
1883 * MAX_SR_FANOUT so we can allocate the arrays on the stack (a kmem_alloc
1884 * for each packet would be expensive). If we ever want to have the
1885 * ability to have unlimited fanout, we should probably declare a head,
1886 * tail, cnt, sz with each soft ring (a data struct which contains a softring
1887 * along with these members) and create an array of this uber struct so we
1888 * don't have to do kmem_alloc.
1889 */
1896 static void
1898 {
1904 uint_t indx;
1908 uint_t hash;
1915 boolean_t bw_ctl;
1916 boolean_t hw_classified;
1917 boolean_t dls_bypass;
1918 boolean_t is_ether;
1919 boolean_t is_unicast;
1927 /*
1928 * If we don't have a Rx ring, S/W classification would have done
1929 * its job and its a packet meant for us. If we were polling on
1930 * the default ring (i.e. there was a ring assigned to this SRS),
1931 * then we need to make sure that the mac address really belongs
1932 * to us.
1933 */
1937 /*
1938 * Special clients (eg. VLAN, non ether, etc) need DLS
1939 * processing in the Rx path. SRST_DLS_BYPASS will be clear for
1940 * such SRSs. Another way of disabling bypass is to set the
1941 * MCIS_RX_BYPASS_DISABLE flag.
1942 */
1946 /*
1947 * Since the softrings are never destroyed and we always
1948 * create equal number of softrings for TCP, UDP and rest,
1949 * its OK to check one of them for count and use it without
1950 * any lock. In future, if soft rings get destroyed because
1951 * of reduction in fanout, we will need to ensure that happens
1952 * behind the SRS_PROC.
1953 */
1961 /*
1962 * We got a chain from SRS that we need to send to the soft rings.
1963 * Since squeues for TCP & IPv4 sap poll their soft rings (for
1964 * performance reasons), we need to separate out v4_tcp, v4_udp
1965 * and the rest goes in other.
1966 */
1976 /*
1977 * At this point we can be sure the packet at least
1978 * has an ether header.
1979 */
1983 }
1986 /*
1987 * Determine if this is a VLAN or non-VLAN packet.
1988 */
1993 /*
1994 * Check if the VID of the packet, if any,
1995 * belongs to this client.
1996 */
2001 }
2004 }
2005 is_unicast =
2009 mac_header_info_t mhi;
2015 }
2020 }
2027 }
2033 }
2036 /*
2037 * If we are using the default Rx ring where H/W or S/W
2038 * classification has not happened, we need to verify if
2039 * this unicast packet really belongs to us.
2040 */
2042 /*
2043 * If we are H/W classified, but we have promisc
2044 * on, then we need to check for the unicast address.
2045 */
2057 }
2058 }
2060 /*
2061 * This needs to become a contract with the driver for
2062 * the fast path.
2063 */
2068 fanout_oth1++;
2069 }
2084 }
2085 frag_offset_flags =
2090 fanout_oth3++;
2092 }
2097 fanout_oth4++;
2099 }
2100 }
2107 }
2113 }
2117 /*
2118 * XXX-Sunay: We should hold srs_lock since ring_count
2119 * below can change. But if we are always called from
2120 * mac_rx_srs_drain and SRS_PROC is set, then we can
2121 * enforce that ring_count can't be changed i.e.
2122 * to change fanout type or ring count, the calling
2123 * thread needs to be behind SRS_PROC.
2124 */
2127 /*
2128 * Note that for ESP, we fanout on SPI and it is at the
2129 * same offset as the 2x16-bit ports. So it is clumped
2130 * along with TCP, UDP and SCTP.
2131 */
2150 }
2157 }
2161 }
2173 softring =
2177 softring =
2181 softring =
2184 }
2188 }
2189 }
2190 }
2191 }
2193 #define SRS_BYTES_TO_PICKUP 150000
2196 /*
2197 * mac_rx_srs_poll_ring
2198 *
2199 * This SRS Poll thread uses this routine to poll the underlying hardware
2200 * Rx ring to get a chain of packets. It can inline process that chain
2201 * if mac_latency_optimize is set (default) or signal the SRS worker thread
2202 * to do the remaining processing.
2203 *
2204 * Since packets come in the system via interrupt or poll path, we also
2205 * update the stats and deal with promiscous clients here.
2206 */
2207 void
2209 {
2214 callb_cpr_t cprinfo;
2215 ssize_t bytes_to_pickup;
2223 start:
2235 check_again:
2237 /*
2238 * We pick as many bytes as we are allowed to queue.
2239 * Its possible that we will exceed the total
2240 * packets queued in case this SRS is part of the
2241 * Rx ring group since > 1 poll thread can be pulling
2242 * upto the max allowed packets at the same time
2243 * but that should be OK.
2244 */
2246 bytes_to_pickup =
2249 /*
2250 * We shouldn't have been signalled if we
2251 * have 0 or less bytes to pick but since
2252 * some of the bytes accounting is driver
2253 * dependant, we do the safety check.
2254 */
2259 /*
2260 * ToDO: Need to change the polling API
2261 * to add a packet count and a flag which
2262 * tells the driver whether we want packets
2263 * based on a count, or bytes, or all the
2264 * packets queued in the driver/HW. This
2265 * way, we never have to check the limits
2266 * on poll path. We truly let only as many
2267 * packets enter the system as we are willing
2268 * to process or queue.
2269 *
2270 * Something along the lines of
2271 * pkts_to_pickup = mac_soft_ring_max_q_cnt -
2272 * mac_srs->srs_poll_pkt_cnt
2273 */
2275 /*
2276 * Since we are not doing B/W control, pick
2277 * as many packets as allowed.
2278 */
2280 }
2282 /* Poll the underlying Hardware */
2288 SRS_POLL_THR_OWNER);
2297 count++;
2298 }
2307 /*
2308 * If there are any promiscuous mode callbacks
2309 * defined for this MAC client, pass them a copy
2310 * if appropriate and also update the counters.
2311 */
2318 }
2319 }
2324 }
2331 else
2333 }
2335 /*
2336 * We are guaranteed that SRS_PROC will be set if we
2337 * are here. Also, poll thread gets to run only if
2338 * the drain was being done by a worker thread although
2339 * its possible that worker thread is still running
2340 * and poll thread was sent down to keep the pipeline
2341 * going instead of doing a complete drain and then
2342 * trying to poll the NIC.
2343 *
2344 * So we need to check SRS_WORKER flag to make sure
2345 * that the worker thread is not processing the queue
2346 * in parallel to us. The flags and conditions are
2347 * protected by the srs_lock to prevent any race. We
2348 * ensure that we don't drop the srs_lock from now
2349 * till the end and similarly we don't drop the srs_lock
2350 * in mac_rx_srs_drain() till similar condition check
2351 * are complete. The mac_rx_srs_drain() needs to ensure
2352 * that SRS_WORKER flag remains set as long as its
2353 * processing the queue.
2354 */
2357 /*
2358 * We have packets to process and worker thread
2359 * is not running. Check to see if poll thread is
2360 * allowed to process.
2361 */
2369 }
2370 /*
2371 * We are already above low water mark
2372 * so stay in the polling mode but no
2373 * need to poll. Once we dip below
2374 * the polling threshold, the processing
2375 * thread (soft ring) will signal us
2376 * to poll again (MAC_UPDATE_SRS_COUNT)
2377 */
2380 /*
2381 * In B/W control case, its possible
2382 * that the backlog built up due to
2383 * B/W limit being reached and packets
2384 * are queued only in SRS. In this case,
2385 * we should schedule worker thread
2386 * since no one else will wake us up.
2387 */
2393 }
2395 /*
2396 * Wakeup the worker thread for more processing.
2397 * We optimize for throughput in this case.
2398 */
2402 }
2405 /*
2406 * There is nothing queued in SRS and
2407 * no worker thread running. Plus we
2408 * didn't get anything from the H/W
2409 * as well (head == NULL);
2410 */
2415 /*
2416 * If we have a packets in soft ring, don't allow
2417 * more packets to come into this SRS by keeping the
2418 * interrupts off but not polling the H/W. The
2419 * poll thread will get signaled as soon as
2420 * srs_poll_pkt_cnt dips below poll threshold.
2421 */
2426 /*
2427 * We know nothing is queued in SRS
2428 * since we are here after checking
2429 * srs_first is NULL. The backlog
2430 * is entirely due to packets queued
2431 * in Soft ring which will wake us up
2432 * and get the interface out of polling
2433 * mode once the backlog dips below
2434 * sr_poll_thres.
2435 */
2437 }
2439 /*
2440 * Worker thread is already running.
2441 * Nothing much to do. If the polling
2442 * was enabled, worker thread will deal
2443 * with that.
2444 */
2447 }
2448 }
2449 done:
2452 /*
2453 * If this is a temporary quiesce then wait for the restart signal
2454 * from the srs worker. Then clear the flags and signal the srs worker
2455 * to ensure a positive handshake and go back to start.
2456 */
2470 }
2471 }
2473 /*
2474 * mac_srs_pick_chain
2475 *
2476 * In Bandwidth control case, checks how many packets can be processed
2477 * and return them in a sub chain.
2478 */
2482 {
2505 }
2507 /*
2508 * Can't clear the entire backlog.
2509 * Need to find how many packets to pick
2510 */
2518 SRS_BW_ENFORCED;
2520 }
2522 /*
2523 * The _size & cnt is decremented from the softrings
2524 * when they send up the packet for polling to work
2525 * properly.
2526 */
2528 cnt++;
2533 else
2537 }
2549 }
2551 /*
2552 * mac_rx_srs_drain
2553 *
2554 * The SRS drain routine. Gets to run to clear the queue. Any thread
2555 * (worker, interrupt, poll) can call this based on processing model.
2556 * The first thing we do is disable interrupts if possible and then
2557 * drain the queue. we also try to poll the underlying hardware if
2558 * there is a dedicated hardware Rx ring assigned to this SRS.
2559 *
2560 * There is a equivalent drain routine in bandwidth control mode
2561 * mac_rx_srs_drain_bw. There is some code duplication between the two
2562 * routines but they are highly performance sensitive and are easier
2563 * to read/debug if they stay separate. Any code changes here might
2564 * also apply to mac_rx_srs_drain_bw as well.
2565 */
2566 void
2568 {
2571 timeout_id_t tid;
2579 /* If we are blanked i.e. can't do upcalls, then we are done */
2584 }
2591 /*
2592 * In the normal case, the SRS worker thread does no
2593 * work and we wait for a backlog to build up before
2594 * we switch into polling mode. In case we are
2595 * optimizing for throughput, we use the worker thread
2596 * as well. The goal is to let worker thread process
2597 * the queue and poll thread to feed packets into
2598 * the queue. As such, we should signal the poll
2599 * thread to try and get more packets.
2600 *
2601 * We could have pulled this check in the POLL_RING
2602 * macro itself but keeping it explicit here makes
2603 * the architecture more human understandable.
2604 */
2606 }
2608 again:
2625 /*
2626 * mcip is NULL for broadcast and multicast flows. The promisc
2627 * callbacks for broadcast and multicast packets are delivered from
2628 * mac_rx() and we don't need to worry about that case in this path
2629 */
2635 }
2640 }
2641 }
2643 /*
2644 * Check if SRS itself is doing the processing
2645 * This direct path does not apply when subflows are present. In this
2646 * case, packets need to be dispatched to a soft ring according to the
2647 * flow's bandwidth and other resources contraints.
2648 */
2650 mac_direct_rx_t proc;
2652 mac_resource_handle_t arg2;
2654 /*
2655 * This is the case when a Rx is directly
2656 * assigned and we have a fully classified
2657 * protocol chain. We can deal with it in
2658 * one shot.
2659 */
2669 }
2672 /*
2673 * Decrement the size and count here itelf
2674 * since the packet has been processed.
2675 */
2682 /* Some kind of softrings based fanout is required */
2687 }
2689 /*
2690 * Since the fanout routines can deal with chains,
2691 * shoot the entire chain up.
2692 */
2695 else
2698 }
2702 /*
2703 * More packets arrived while we were clearing the
2704 * SRS. This can be possible because of one of
2705 * three conditions below:
2706 * 1) The driver is using multiple worker threads
2707 * to send the packets to us.
2708 * 2) The driver has a race in switching
2709 * between interrupt and polling mode or
2710 * 3) Packets are arriving in this SRS via the
2711 * S/W classification as well.
2712 *
2713 * We should switch to polling mode and see if we
2714 * need to send the poll thread down. Also, signal
2715 * the worker thread to process whats just arrived.
2716 */
2721 }
2723 /*
2724 * If we didn't signal the poll thread, we need
2725 * to deal with the pending packets ourselves.
2726 */
2733 }
2734 }
2736 out:
2738 /*
2739 * Poll thread is already running. Leave the
2740 * SRS_RPOC set and hand over the control to
2741 * poll thread.
2742 */
2746 }
2748 /*
2749 * Even if there are no packets queued in SRS, we
2750 * need to make sure that the shared counter is
2751 * clear and any associated softrings have cleared
2752 * all the backlog. Otherwise, leave the interface
2753 * in polling mode and the poll thread will get
2754 * signalled once the count goes down to zero.
2755 *
2756 * If someone is already draining the queue (SRS_PROC is
2757 * set) when the srs_poll_pkt_cnt goes down to zero,
2758 * then it means that drain is already running and we
2759 * will turn off polling at that time if there is
2760 * no backlog.
2761 *
2762 * As long as there are packets queued either
2763 * in soft ring set or its soft rings, we will leave
2764 * the interface in polling mode (even if the drain
2765 * was done being the interrupt thread). We signal
2766 * the poll thread as well if we have dipped below
2767 * low water mark.
2768 *
2769 * NOTE: We can't use the MAC_SRS_POLLING_ON macro
2770 * since that turn polling on only for worker thread.
2771 * Its not worth turning polling on for interrupt
2772 * thread (since NIC will not issue another interrupt)
2773 * unless a backlog builds up.
2774 */
2783 }
2785 /* Nothing else to do. Get out of poll mode */
2789 }
2791 /*
2792 * mac_rx_srs_drain_bw
2793 *
2794 * The SRS BW drain routine. Gets to run to clear the queue. Any thread
2795 * (worker, interrupt, poll) can call this based on processing model.
2796 * The first thing we do is disable interrupts if possible and then
2797 * drain the queue. we also try to poll the underlying hardware if
2798 * there is a dedicated hardware Rx ring assigned to this SRS.
2799 *
2800 * There is a equivalent drain routine in non bandwidth control mode
2801 * mac_rx_srs_drain. There is some code duplication between the two
2802 * routines but they are highly performance sensitive and are easier
2803 * to read/debug if they stay separate. Any code changes here might
2804 * also apply to mac_rx_srs_drain as well.
2805 */
2806 void
2808 {
2811 timeout_id_t tid;
2820 again:
2821 /* Check if we are doing B/W control */
2837 }
2840 /* If we are blanked i.e. can't do upcalls, then we are done */
2845 }
2850 /*
2851 * We couldn't pick up a single packet.
2852 */
2857 /*
2858 * Seems like configured B/W doesn't
2859 * even allow processing of 1 packet
2860 * per tick.
2861 *
2862 * XXX: raise the limit to processing
2863 * at least 1 packet per tick.
2864 */
2870 "raised B/W limit to %d since not even a "
2871 "single packet can be processed per "
2875 }
2878 }
2883 /* zero bandwidth: drop all and return to interrupt mode */
2895 }
2903 /*
2904 * mcip is NULL for broadcast and multicast flows. The promisc
2905 * callbacks for broadcast and multicast packets are delivered from
2906 * mac_rx() and we don't need to worry about that case in this path
2907 */
2913 }
2918 }
2919 }
2921 /*
2922 * Check if SRS itself is doing the processing
2923 * This direct path does not apply when subflows are present. In this
2924 * case, packets need to be dispatched to a soft ring according to the
2925 * flow's bandwidth and other resources contraints.
2926 */
2928 mac_direct_rx_t proc;
2930 mac_resource_handle_t arg2;
2932 /*
2933 * This is the case when a Rx is directly
2934 * assigned and we have a fully classified
2935 * protocol chain. We can deal with it in
2936 * one shot.
2937 */
2947 }
2950 /*
2951 * Decrement the size and count here itelf
2952 * since the packet has been processed.
2953 */
2962 /* Some kind of softrings based fanout is required */
2967 }
2969 /*
2970 * Since the fanout routines can deal with chains,
2971 * shoot the entire chain up.
2972 */
2975 else
2978 }
2980 /*
2981 * Send the poll thread to pick up any packets arrived
2982 * so far. This also serves as the last check in case
2983 * nothing else is queued in the SRS. The poll thread
2984 * is signalled only in the case the drain was done
2985 * by the worker thread and SRS_WORKER is set. The
2986 * worker thread can run in parallel as long as the
2987 * SRS_WORKER flag is set. We we have nothing else to
2988 * process, we can exit while leaving SRS_PROC set
2989 * which gives the poll thread control to process and
2990 * cleanup once it returns from the NIC.
2991 *
2992 * If we have nothing else to process, we need to
2993 * ensure that we keep holding the srs_lock till
2994 * all the checks below are done and control is
2995 * handed to the poll thread if it was running.
2996 */
3008 }
3009 }
3010 }
3013 done:
3016 /*
3017 * Poll thread is already running. Leave the
3018 * SRS_RPOC set and hand over the control to
3019 * poll thread.
3020 */
3023 }
3025 /*
3026 * If we can't process packets because we have exceeded
3027 * B/W limit for this tick, just set the timeout
3028 * and leave.
3029 *
3030 * Even if there are no packets queued in SRS, we
3031 * need to make sure that the shared counter is
3032 * clear and any associated softrings have cleared
3033 * all the backlog. Otherwise, leave the interface
3034 * in polling mode and the poll thread will get
3035 * signalled once the count goes down to zero.
3036 *
3037 * If someone is already draining the queue (SRS_PROC is
3038 * set) when the srs_poll_pkt_cnt goes down to zero,
3039 * then it means that drain is already running and we
3040 * will turn off polling at that time if there is
3041 * no backlog. As long as there are packets queued either
3042 * is soft ring set or its soft rings, we will leave
3043 * the interface in polling mode.
3044 */
3057 }
3060 leave_poll:
3062 /* Nothing else to do. Get out of poll mode */
3065 }
3067 /*
3068 * mac_srs_worker
3069 *
3070 * The SRS worker routine. Drains the queue when no one else is
3071 * processing it.
3072 */
3073 void
3075 {
3078 callb_cpr_t cprinfo;
3079 boolean_t bw_ctl_flag;
3084 start:
3093 }
3094 /*
3095 * The SRS_BW_ENFORCED flag may change since we have dropped
3096 * the mac_bw_lock. However the drain function can handle both
3097 * a drainable SRS or a bandwidth controlled SRS, and the
3098 * effect of scheduling a timeout is to wakeup the worker
3099 * thread which in turn will call the drain function. Since
3100 * we release the srs_lock atomically only in the cv_wait there
3101 * isn't a fear of waiting for ever.
3102 */
3107 /*
3108 * If we have packets queued and we are here
3109 * because B/W control is in place, we better
3110 * schedule the worker wakeup after 1 tick
3111 * to see if bandwidth control can be relaxed.
3112 */
3114 /*
3115 * We need to ensure that a timer is already
3116 * scheduled or we force schedule one for
3117 * later so that we can continue processing
3118 * after this quanta is over.
3119 */
3122 }
3123 wait:
3137 SRS_BW_ENFORCED) {
3139 }
3141 SRS_BW_ENFORCED;
3143 }
3144 }
3149 }
3150 done:
3151 /*
3152 * The Rx SRS quiesce logic first cuts off packet supply to the SRS
3153 * from both hard and soft classifications and waits for such threads
3154 * to finish before signaling the worker. So at this point the only
3155 * thread left that could be competing with the worker is the poll
3156 * thread. In the case of Tx, there shouldn't be any thread holding
3157 * SRS_PROC at this point.
3158 */
3163 /*
3164 * Poll thread still owns the SRS and is still running
3165 */
3168 SRS_POLL_THR_OWNER));
3169 }
3171 /*
3172 * Wait for the SRS_RESTART or SRS_CONDEMNED signal from the initiator
3173 * of the quiesce operation
3174 */
3183 }
3189 /* The macro drops the srs_lock */
3192 }
3194 /*
3195 * mac_rx_srs_subflow_process
3196 *
3197 * Receive side routine called from interrupt path when there are
3198 * sub flows present on this SRS.
3199 */
3200 /* ARGSUSED */
3201 void
3204 {
3215 /*
3216 * We need to determine the SRS for every packet
3217 * by walking the flow table, if we don't get any,
3218 * then we proceed using the SRS we came with.
3219 */
3223 /*
3224 * We will increment the stats for the mactching subflow.
3225 * when we get the bytes/pkt count for the classified packets
3226 * later in mac_rx_srs_process.
3227 */
3239 }
3241 /*
3242 * A null indicates, this is for the mac_srs itself.
3243 * XXX-venu : probably assert for fe_rx_srs_cnt == 0.
3244 */
3248 loopback);
3253 }
3259 }
3260 /* Last chain */
3269 }
3270 }
3272 /*
3273 * mac_rx_srs_process
3274 *
3275 * Receive side routine called from the interrupt path.
3276 *
3277 * loopback is set to force a context switch on the loopback
3278 * path between MAC clients.
3279 */
3280 /* ARGSUSED */
3281 void
3283 boolean_t loopback)
3284 {
3294 /*
3295 * Set the tail, count and sz. We set the sz irrespective
3296 * of whether we are doing B/W control or not for the
3297 * purpose of updating the stats.
3298 */
3302 count++;
3305 }
3316 }
3318 /*
3319 * If the SRS in already being processed; has been blanked;
3320 * can be processed by worker thread only; or the B/W limit
3321 * has been reached, then queue the chain and check if
3322 * worker thread needs to be awakend.
3323 */
3330 /* zero bandwidth: drop all */
3355 count1++;
3358 }
3368 /* Can't pick up any */
3370 }
3372 /* Drop any packet over the threshold */
3378 }
3379 }
3383 }
3384 }
3386 /*
3387 * If the total number of packets queued in the SRS and
3388 * its associated soft rings exceeds the max allowed,
3389 * then drop the chain. If we are polling capable, this
3390 * shouldn't be happening.
3391 */
3402 }
3407 /*
3408 * If we are coming via loopback, if we are not optimizing for
3409 * latency, or if our stack is running deep, we should signal
3410 * the worker thread.
3411 */
3414 /*
3415 * For loopback, We need to let the worker take
3416 * over as we don't want to continue in the same
3417 * thread even if we can. This could lead to stack
3418 * overflows and may also end up using
3419 * resources (cpu) incorrectly.
3420 */
3423 /*
3424 * Seems like no one is processing the SRS and
3425 * there is no backlog. We also inline process
3426 * our packet if its a single packet in non
3427 * latency optimized case (in latency optimized
3428 * case, we inline process chains of any size).
3429 */
3431 }
3432 }
3434 }
3436 /* TX SIDE ROUTINES (RUNTIME) */
3438 /*
3439 * mac_tx_srs_no_desc
3440 *
3441 * This routine is called by Tx single ring default mode
3442 * when Tx ring runs out of descs.
3443 */
3444 mac_tx_cookie_t
3447 {
3463 /*
3464 * If TX_QUEUED is not set, queue the
3465 * packet and let mac_tx_srs_drain()
3466 * set the TX_BLOCKED bit for the
3467 * reasons explained above. Otherwise,
3468 * return the mblks.
3469 */
3476 }
3480 }
3483 }
3485 }
3487 /*
3488 * mac_tx_srs_enqueue
3489 *
3490 * This routine is called when Tx SRS is operating in either serializer
3491 * or bandwidth mode. In serializer mode, a packet will get enqueued
3492 * when a thread cannot enter SRS exclusively. In bandwidth mode,
3493 * packets gets queued if allowed byte-count limit for a tick is
3494 * exceeded. The action that gets taken when MAC_DROP_ON_NO_DESC and
3495 * MAC_TX_NO_ENQUEUE is set is different than when operaing in either
3496 * the default mode or fanout mode. Here packets get dropped or
3497 * returned back to the caller only after hi-watermark worth of data
3498 * is queued.
3499 */
3500 static mac_tx_cookie_t
3503 {
3509 /*
3510 * Ignore fanout hint if we don't have multiple tx rings.
3511 */
3524 }
3534 }
3536 /*
3537 * If you are BW_ENFORCED, just enqueue the
3538 * packet. srs_worker will drain it at the
3539 * prescribed rate. Before enqueueing, save
3540 * the fanout hint.
3541 */
3545 }
3549 }
3551 /*
3552 * There are seven tx modes:
3553 *
3554 * 1) Default mode (SRS_TX_DEFAULT)
3555 * 2) Serialization mode (SRS_TX_SERIALIZE)
3556 * 3) Fanout mode (SRS_TX_FANOUT)
3557 * 4) Bandwdith mode (SRS_TX_BW)
3558 * 5) Fanout and Bandwidth mode (SRS_TX_BW_FANOUT)
3559 * 6) aggr Tx mode (SRS_TX_AGGR)
3560 * 7) aggr Tx bw mode (SRS_TX_BW_AGGR)
3561 *
3562 * The tx mode in which an SRS operates is decided in mac_tx_srs_setup()
3563 * based on the number of Tx rings requested for an SRS and whether
3564 * bandwidth control is requested or not.
3565 *
3566 * The default mode (i.e., no fanout/no bandwidth) is used when the
3567 * underlying NIC does not have Tx rings or just one Tx ring. In this mode,
3568 * the SRS acts as a pass-thru. Packets will go directly to mac_tx_send().
3569 * When the underlying Tx ring runs out of Tx descs, it starts queueing up
3570 * packets in SRS. When flow-control is relieved, the srs_worker drains
3571 * the queued packets and informs blocked clients to restart sending
3572 * packets.
3573 *
3574 * In the SRS_TX_SERIALIZE mode, all calls to mac_tx() are serialized. This
3575 * mode is used when the link has no Tx rings or only one Tx ring.
3576 *
3577 * In the SRS_TX_FANOUT mode, packets will be fanned out to multiple
3578 * Tx rings. Each Tx ring will have a soft ring associated with it.
3579 * These soft rings will be hung off the Tx SRS. Queueing if it happens
3580 * due to lack of Tx desc will be in individual soft ring (and not srs)
3581 * associated with Tx ring.
3582 *
3583 * In the TX_BW mode, tx srs will allow packets to go down to Tx ring
3584 * only if bw is available. Otherwise the packets will be queued in
3585 * SRS. If fanout to multiple Tx rings is configured, the packets will
3586 * be fanned out among the soft rings associated with the Tx rings.
3587 *
3588 * In SRS_TX_AGGR mode, mac_tx_aggr_mode() routine is called. This routine
3589 * invokes an aggr function, aggr_find_tx_ring(), to find a pseudo Tx ring
3590 * belonging to a port on which the packet has to be sent. Aggr will
3591 * always have a pseudo Tx ring associated with it even when it is an
3592 * aggregation over a single NIC that has no Tx rings. Even in such a
3593 * case, the single pseudo Tx ring will have a soft ring associated with
3594 * it and the soft ring will hang off the SRS.
3595 *
3596 * If a bandwidth is specified for an aggr, SRS_TX_BW_AGGR mode is used.
3597 * In this mode, the bandwidth is first applied on the outgoing packets
3598 * and later mac_tx_addr_mode() function is called to send the packet out
3599 * of one of the pseudo Tx rings.
3600 *
3601 * Four flags are used in srs_state for indicating flow control
3602 * conditions : SRS_TX_BLOCKED, SRS_TX_HIWAT, SRS_TX_WAKEUP_CLIENT.
3603 * SRS_TX_BLOCKED indicates out of Tx descs. SRS expects a wakeup from the
3604 * driver below.
3605 * SRS_TX_HIWAT indicates packet count enqueued in Tx SRS exceeded Tx hiwat
3606 * and flow-control pressure is applied back to clients. The clients expect
3607 * wakeup when flow-control is relieved.
3608 * SRS_TX_WAKEUP_CLIENT get set when (flag == MAC_TX_NO_ENQUEUE) and mblk
3609 * got returned back to client either due to lack of Tx descs or due to bw
3610 * control reasons. The clients expect a wakeup when condition is relieved.
3611 *
3612 * The fourth argument to mac_tx() is the flag. Normally it will be 0 but
3613 * some clients set the following values too: MAC_DROP_ON_NO_DESC,
3614 * MAC_TX_NO_ENQUEUE
3615 * Mac clients that do not want packets to be enqueued in the mac layer set
3616 * MAC_DROP_ON_NO_DESC value. The packets won't be queued in the Tx SRS or
3617 * Tx soft rings but instead get dropped when the NIC runs out of desc. The
3618 * behaviour of this flag is different when the Tx is running in serializer
3619 * or bandwidth mode. Under these (Serializer, bandwidth) modes, the packet
3620 * get dropped when Tx high watermark is reached.
3621 * There are some mac clients like vsw, aggr that want the mblks to be
3622 * returned back to clients instead of being queued in Tx SRS (or Tx soft
3623 * rings) under flow-control (i.e., out of desc or exceeding bw limits)
3624 * conditions. These clients call mac_tx() with MAC_TX_NO_ENQUEUE flag set.
3625 * In the default and Tx fanout mode, the un-transmitted mblks will be
3626 * returned back to the clients when the driver runs out of Tx descs.
3627 * SRS_TX_WAKEUP_CLIENT (or S_RING_WAKEUP_CLIENT) will be set in SRS (or
3628 * soft ring) so that the clients can be woken up when Tx desc become
3629 * available. When running in serializer or bandwidth mode mode,
3630 * SRS_TX_WAKEUP_CLIENT will be set when tx hi-watermark is reached.
3631 */
3633 mac_tx_func_t
3635 {
3637 }
3639 /* ARGSUSED */
3640 static mac_tx_cookie_t
3643 {
3645 mac_tx_stats_t stats;
3650 /* Regular case with a single Tx ring */
3651 /*
3652 * SRS_TX_BLOCKED is set when underlying NIC runs
3653 * out of Tx descs and messages start getting
3654 * queued. It won't get reset until
3655 * tx_srs_drain() completely drains out the
3656 * messages.
3657 */
3659 /* Tx descs/resources not available */
3666 }
3667 /*
3668 * While we were computing mblk count, the
3669 * flow control condition got relieved.
3670 * Continue with the transmission.
3671 */
3673 }
3678 /*
3679 * Multiple threads could be here sending packets.
3680 * Under such conditions, it is not possible to
3681 * automically set SRS_TX_BLOCKED bit to indicate
3682 * out of tx desc condition. To atomically set
3683 * this, we queue the returned packet and do
3684 * the setting of SRS_TX_BLOCKED in
3685 * mac_tx_srs_drain().
3686 */
3692 }
3696 }
3698 /*
3699 * mac_tx_serialize_mode
3700 *
3701 * This is an experimental mode implemented as per the request of PAE.
3702 * In this mode, all callers attempting to send a packet to the NIC
3703 * will get serialized. Only one thread at any time will access the
3704 * NIC to send the packet out.
3705 */
3706 /* ARGSUSED */
3707 static mac_tx_cookie_t
3710 {
3711 mac_tx_stats_t stats;
3715 /* Single ring, serialize below */
3720 /*
3721 * In serialization mode, queue all packets until
3722 * TX_HIWAT is set.
3723 * If drop bit is set, drop if TX_HIWAT is set.
3724 * If no_enqueue is set, still enqueue until hiwat
3725 * is set and return mblks after TX_HIWAT is set.
3726 */
3731 }
3732 /*
3733 * No packets queued, nothing on proc and no flow
3734 * control condition. Fast-path, ok. Do inline
3735 * processing.
3736 */
3748 }
3750 /*
3751 * We processed inline our packet and a new
3752 * packet/s got queued while we were
3753 * processing. Wakeup srs worker
3754 */
3756 }
3763 }
3765 /*
3766 * mac_tx_fanout_mode
3767 *
3768 * In this mode, the SRS will have access to multiple Tx rings to send
3769 * the packet out. The fanout hint that is passed as an argument is
3770 * used to find an appropriate ring to fanout the traffic. Each Tx
3771 * ring, in turn, will have a soft ring associated with it. If a Tx
3772 * ring runs out of Tx desc's the returned packet will be queued in
3773 * the soft ring associated with that Tx ring. The srs itself will not
3774 * queue any packets.
3775 */
3777 #define MAC_TX_SOFT_RING_PROCESS(chain) { \
3778 index = COMPUTE_INDEX(hash, mac_srs->srs_tx_ring_count), \
3779 softring = mac_srs->srs_tx_soft_rings[index]; \
3780 cookie = mac_tx_soft_ring_process(softring, chain, flag, ret_mp); \
3781 DTRACE_PROBE2(tx__fanout, uint64_t, hash, uint_t, index); \
3782 }
3784 static mac_tx_cookie_t
3787 {
3790 uint_t index;
3796 /*
3797 * The hint is specified by the caller, simply pass the
3798 * whole chain to the soft ring.
3799 */
3807 /*
3808 * Compute the hash from the contents (headers) of the
3809 * packets of the mblk chain. Split the chains into
3810 * subchains of the same conversation.
3811 *
3812 * Since there may be more than one ring used for
3813 * sub-chains of the same call, and since the caller
3814 * does not maintain per conversation state since it
3815 * passed a zero hint, unsent subchains will be
3816 * dropped.
3817 */
3830 B_TRUE);
3832 /*
3833 * Starting a different subchain, send current
3834 * chain out.
3835 */
3840 }
3842 /* add packet to subchain */
3847 }
3850 /* send last subchain */
3854 }
3857 }
3860 }
3862 /*
3863 * mac_tx_bw_mode
3864 *
3865 * In the bandwidth mode, Tx srs will allow packets to go down to Tx ring
3866 * only if bw is available. Otherwise the packets will be queued in
3867 * SRS. If the SRS has multiple Tx rings, then packets will get fanned
3868 * out to a Tx rings.
3869 */
3870 static mac_tx_cookie_t
3873 {
3884 /*
3885 * zero bandwidth, no traffic is sent: drop the packets,
3886 * or return the whole chain if the caller requests all
3887 * unsent packets back.
3888 */
3894 }
3903 }
3914 /*
3915 * Wakeup worker thread. Note that worker
3916 * thread has to be woken up so that it
3917 * can fire up the timer to be woken up
3918 * on the next tick. Also once
3919 * BW_ENFORCED is set, it can only be
3920 * reset by srs_worker thread. Until then
3921 * all packets will get queued up in SRS
3922 * and hence this this code path won't be
3923 * entered until BW_ENFORCED is reset.
3924 */
3928 }
3942 ret_mp));
3947 mac_tx_stats_t stats;
3957 else
3963 }
3967 }
3968 }
3970 /*
3971 * mac_tx_aggr_mode
3972 *
3973 * This routine invokes an aggr function, aggr_find_tx_ring(), to find
3974 * a (pseudo) Tx ring belonging to a port on which the packet has to
3975 * be sent. aggr_find_tx_ring() first finds the outgoing port based on
3976 * L2/L3/L4 policy and then uses the fanout_hint passed to it to pick
3977 * a Tx ring from the selected port.
3978 *
3979 * Note that a port can be deleted from the aggregation. In such a case,
3980 * the aggregation layer first separates the port from the rest of the
3981 * ports making sure that port (and thus any Tx rings associated with
3982 * it) won't get selected in the call to aggr_find_tx_ring() function.
3983 * Later calls are made to mac_group_rem_ring() passing pseudo Tx ring
3984 * handles one by one which in turn will quiesce the Tx SRS and remove
3985 * the soft ring associated with the pseudo Tx ring. Unlike Rx side
3986 * where a cookie is used to protect against mac_rx_ring() calls on
3987 * rings that have been removed, no such cookie is needed on the Tx
3988 * side as the pseudo Tx ring won't be available anymore to
3989 * aggr_find_tx_ring() once the port has been removed.
3990 */
3991 static mac_tx_cookie_t
3994 {
3996 mac_tx_ring_fn_t find_tx_ring_fn;
4007 }
4009 void
4011 {
4015 /* Wakeup callback registered clients */
4021 }
4024 }
4026 /* ARGSUSED */
4027 void
4029 {
4033 uint_t saved_pkt_count;
4034 mac_tx_stats_t stats;
4060 /* Device out of tx desc, set block */
4073 }
4074 }
4076 /*
4077 * We are here because the timer fired and we have some data
4078 * to tranmit. Also mac_tx_srs_worker should have reset
4079 * SRS_BW_ENFORCED flag
4080 */
4092 saved_pkt_count++;
4104 }
4107 }
4120 uint_t size_sent;
4122 /* Device out of tx desc, set block */
4136 size_sent;
4139 }
4144 }
4145 }
4150 /*
4151 * We are here because the timer fired and we
4152 * have some quota to tranmit.
4153 */
4174 }
4187 }
4190 }
4198 }
4199 }
4200 /*
4201 * SRS_TX_FANOUT case not considered here because packets
4202 * won't be queued in the SRS for this case. Packets will
4203 * be sent directly to soft rings underneath and if there
4204 * is any queueing at all, it would be in Tx side soft
4205 * rings.
4206 */
4208 /*
4209 * When srs_count becomes 0, reset SRS_TX_HIWAT and
4210 * SRS_TX_WAKEUP_CLIENT and wakeup registered clients.
4211 */
4220 }
4226 /*
4227 * If the client is not the primary MAC client, then we
4228 * need to send the notification to the clients upper
4229 * MAC, i.e. mci_upper_mip.
4230 */
4233 }
4235 }
4237 }
4239 /*
4240 * Given a packet, get the flow_entry that identifies the flow
4241 * to which that packet belongs. The flow_entry will contain
4242 * the transmit function to be used to send the packet. If the
4243 * function returns NULL, the packet should be sent using the
4244 * underlying NIC.
4245 */
4248 {
4253 /*
4254 * Do classification on the packet.
4255 */
4260 /*
4261 * This flent might just be an additional one on the MAC client,
4262 * i.e. for classification purposes (different fdesc), however
4263 * the resources, SRS et. al., are in the mci_flent, so if
4264 * this isn't the mci_flent, we need to get it.
4265 */
4272 }
4275 }
4277 /*
4278 * This macro is only meant to be used by mac_tx_send().
4279 */
4280 #define CHECK_VID_AND_ADD_TAG(mp) { \
4281 if (vid_check) { \
4282 int err = 0; \
4283 \
4284 MAC_VID_CHECK(src_mcip, (mp), err); \
4285 if (err != 0) { \
4286 freemsg((mp)); \
4287 (mp) = next; \
4288 oerrors++; \
4289 continue; \
4290 } \
4291 } \
4292 if (add_tag) { \
4293 (mp) = mac_add_vlan_tag((mp), 0, vid); \
4294 if ((mp) == NULL) { \
4295 (mp) = next; \
4296 oerrors++; \
4297 continue; \
4298 } \
4299 } \
4300 }
4302 mblk_t *
4305 {
4321 }
4323 /*
4324 * Fastpath: if there's only one client, we simply send
4325 * the packet down to the underlying NIC.
4326 */
4335 opackets++;
4342 /*
4343 * If the driver is out of descriptors and does a
4344 * partial send it will return a chain of unsent
4345 * mblks. Adjust the accounting stats.
4346 */
4348 opackets--;
4352 }
4354 }
4356 }
4358 /*
4359 * No fastpath, we either have more than one MAC client
4360 * defined on top of the same MAC, or one or more MAC
4361 * client promiscuous callbacks.
4362 */
4375 opackets++;
4380 /*
4381 * Find the destination.
4382 */
4395 else
4398 mac_header_info_t mhi;
4404 }
4406 /*
4407 * Got a matching flow. It's either another
4408 * MAC client, or a broadcast/multicast flow.
4409 * Make sure the packet size is within the
4410 * allowed size. If not drop the packet and
4411 * move to next packet.
4412 */
4415 oerrors++;
4422 }
4425 /*
4426 * The vnic_bcast_send function expects
4427 * to receive the sender MAC client
4428 * as value for arg2.
4429 */
4431 B_TRUE);
4433 /*
4434 * loopback the packet to a local MAC
4435 * client. We force a context switch
4436 * if both source and destination MAC
4437 * clients are used by IP, i.e.
4438 * bypass is set.
4439 */
4440 boolean_t do_switch;
4444 /*
4445 * Check if there are promiscuous mode
4446 * callbacks defined. This check is
4447 * done here in the 'else' case and
4448 * not in other cases because this
4449 * path is for local loopback
4450 * communication which does not go
4451 * through MAC_TX(). For paths that go
4452 * through MAC_TX(), the promisc_list
4453 * check is done inside the MAC_TX()
4454 * macro.
4455 */
4468 }
4469 }
4472 /*
4473 * Unknown destination, send via the underlying
4474 * NIC.
4475 */
4478 /*
4479 * Adjust for the last packet that
4480 * could not be transmitted
4481 */
4482 opackets--;
4486 }
4487 }
4489 }
4491 done:
4496 }
4498 /*
4499 * mac_tx_srs_ring_present
4500 *
4501 * Returns whether the specified ring is part of the specified SRS.
4502 */
4503 boolean_t
4505 {
4516 }
4519 }
4521 /*
4522 * mac_tx_srs_get_soft_ring
4523 *
4524 * Returns the TX soft ring associated with the given ring, if present.
4525 */
4526 mac_soft_ring_t *
4528 {
4539 }
4542 }
4544 /*
4545 * mac_tx_srs_wakeup
4546 *
4547 * Called when Tx desc become available. Wakeup the appropriate worker
4548 * thread after resetting the SRS_TX_BLOCKED/S_RING_BLOCK bit in the
4549 * state field.
4550 */
4551 void
4553 {
4559 /*
4560 * srs_tx_ring_count == 0 is the single ring mode case. In
4561 * this mode, there will not be Tx soft rings associated
4562 * with the SRS.
4563 */
4570 }
4571 /*
4572 * A wakeup can come before tx_srs_drain() could
4573 * grab srs lock and set SRS_TX_BLOCKED. So
4574 * always set woken_up flag when we come here.
4575 */
4579 }
4581 /*
4582 * If you are here, it is for FANOUT, BW_FANOUT,
4583 * AGGR_MODE or AGGR_BW_MODE case
4584 */
4593 }
4595 }
4597 }
4599 }
4601 /*
4602 * Once the driver is done draining, send a MAC_NOTE_TX notification to unleash
4603 * the blocked clients again.
4604 */
4605 void
4607 {
4609 }
4611 /*
4612 * RX SOFTRING RELATED FUNCTIONS
4613 *
4614 * These functions really belong in mac_soft_ring.c and here for
4615 * a short period.
4616 */
4618 #define SOFT_RING_ENQUEUE_CHAIN(ringp, mp, tail, cnt, sz) { \
4619 /* \
4620 * Enqueue our mblk chain. \
4622 ASSERT(MUTEX_HELD(&(ringp)->s_ring_lock)); \
4623 \
4624 if ((ringp)->s_ring_last != NULL) \
4625 (ringp)->s_ring_last->b_next = (mp); \
4626 else \
4627 (ringp)->s_ring_first = (mp); \
4628 (ringp)->s_ring_last = (tail); \
4629 (ringp)->s_ring_count += (cnt); \
4630 ASSERT((ringp)->s_ring_count > 0); \
4631 if ((ringp)->s_ring_type & ST_RING_BW_CTL) { \
4632 (ringp)->s_ring_size += sz; \
4633 } \
4634 }
4636 /*
4637 * Default entry point to deliver a packet chain to a MAC client.
4638 * If the MAC client has flows, do the classification with these
4639 * flows as well.
4640 */
4641 /* ARGSUSED */
4642 void
4645 {
4650 /*
4651 * If the client has exactly one VID associated with it
4652 * and striping of VLAN header is not disabled,
4653 * remove the VLAN tag from the packet before
4654 * passing it on to the client's receive callback.
4655 * Note that this needs to be done after we dispatch
4656 * the packet to the promiscuous listeners of the
4657 * client, since they expect to see the whole
4658 * frame including the VLAN headers.
4659 */
4661 }
4664 }
4666 /*
4667 * mac_rx_soft_ring_process
4668 *
4669 * process a chain for a given soft ring. The number of packets queued
4670 * in the SRS and its associated soft rings (including this one) is
4671 * very small (tracked by srs_poll_pkt_cnt), then allow the entering
4672 * thread (interrupt or poll thread) to do inline processing. This
4673 * helps keep the latency down under low load.
4674 *
4675 * The proc and arg for each mblk is already stored in the mblk in
4676 * appropriate places.
4677 */
4678 /* ARGSUSED */
4679 void
4682 {
4683 mac_direct_rx_t proc;
4685 mac_resource_handle_t arg2;
4698 /* If on processor or blanking on, then enqueue and return */
4704 }
4708 /*
4709 * See if anything is already queued. If we are the
4710 * first packet, do inline processing else queue the
4711 * packet and do the drain.
4712 */
4714 /*
4715 * Fast-path, ok to process and nothing queued.
4716 */
4722 /*
4723 * We are the chain of 1 packet so
4724 * go through this fast path.
4725 */
4731 /*
4732 * If we have a soft ring set which is doing
4733 * bandwidth control, we need to decrement
4734 * srs_size and count so it the SRS can have a
4735 * accurate idea of what is the real data
4736 * queued between SRS and its soft rings. We
4737 * decrement the counters only when the packet
4738 * gets processed by both SRS and the soft ring.
4739 */
4753 /*
4754 * We processed inline our packet and
4755 * nothing new has arrived or our
4756 * receiver doesn't want to receive
4757 * any packets. We are done.
4758 */
4761 }
4765 }
4767 /*
4768 * We are here because either we couldn't do inline
4769 * processing (because something was already
4770 * queued), or we had a chain of more than one
4771 * packet, or something else arrived after we were
4772 * done with inline processing.
4773 */
4781 /* ST_RING_WORKER_ONLY case */
4785 }
4786 }
4788 /*
4789 * TX SOFTRING RELATED FUNCTIONS
4790 *
4791 * These functions really belong in mac_soft_ring.c and here for
4792 * a short period.
4793 */
4795 #define TX_SOFT_RING_ENQUEUE_CHAIN(ringp, mp, tail, cnt, sz) { \
4796 ASSERT(MUTEX_HELD(&ringp->s_ring_lock)); \
4797 ringp->s_ring_state |= S_RING_ENQUEUED; \
4798 SOFT_RING_ENQUEUE_CHAIN(ringp, mp_chain, tail, cnt, sz); \
4799 }
4801 /*
4802 * mac_tx_sring_queued
4803 *
4804 * When we are out of transmit descriptors and we already have a
4805 * queue that exceeds hiwat (or the client called us with
4806 * MAC_TX_NO_ENQUEUE or MAC_DROP_ON_NO_DESC flag), return the
4807 * soft ring pointer as the opaque cookie for the client enable
4808 * flow control.
4809 */
4810 static mac_tx_cookie_t
4813 {
4825 /* increment freed stats */
4833 /*
4834 * If QUEUED is not set, queue the packet
4835 * and let mac_tx_soft_ring_drain() set
4836 * the TX_BLOCKED bit for the reasons
4837 * explained above. Otherwise, return the
4838 * mblks.
4839 */
4847 }
4852 /*
4853 * flow-controlled. Store ringp in cookie
4854 * so that it can be returned as
4855 * mac_tx_cookie_t to client
4856 */
4862 /* increment freed stats */
4864 /*
4865 * b_prev may be set to the fanout hint
4866 * hence can't use freemsg directly
4867 */
4873 }
4874 }
4878 }
4879 }
4882 }
4884 }
4887 /*
4888 * mac_tx_soft_ring_process
4889 *
4890 * This routine is called when fanning out outgoing traffic among
4891 * multipe Tx rings.
4892 * Note that a soft ring is associated with a h/w Tx ring.
4893 */
4894 mac_tx_cookie_t
4897 {
4907 /*
4908 * The following modes can come here: SRS_TX_BW_FANOUT,
4909 * SRS_TX_FANOUT, SRS_TX_AGGR, SRS_TX_BW_AGGR.
4910 */
4918 /* Serialization mode */
4926 }
4930 /*
4931 * If ring is blocked due to lack of Tx
4932 * descs, just return. Worker thread
4933 * will get scheduled when Tx desc's
4934 * become available.
4935 */
4938 }
4943 /* Default fanout mode */
4944 /*
4945 * S_RING_BLOCKED is set when underlying NIC runs
4946 * out of Tx descs and messages start getting
4947 * queued. It won't get reset until
4948 * tx_srs_drain() completely drains out the
4949 * messages.
4950 */
4951 mac_tx_stats_t stats;
4954 /* Tx descs/resources not available */
4961 }
4962 /*
4963 * While we were computing mblk count, the
4964 * flow control condition got relieved.
4965 * Continue with the transmission.
4966 */
4968 }
4973 /*
4974 * Multiple threads could be here sending packets.
4975 * Under such conditions, it is not possible to
4976 * automically set S_RING_BLOCKED bit to indicate
4977 * out of tx desc condition. To atomically set
4978 * this, we queue the returned packet and do
4979 * the setting of S_RING_BLOCKED in
4980 * mac_tx_soft_ring_drain().
4981 */
4984 cookie =
4988 }
4993 }
4994 }