Wiki code for Brussels White Paper

Hide Line numbers
1: = OpenSolaris Project Brussels: A Uniform Interface for Driver Administration Through the dladm Command
2: 
3: The Driver Configuration Framework component of the Brussels project became available in SXCE build 83 and is included in the OpenSolarisTM release. The Framework component provides users the following benefits when configuring drivers that use the GLDv3 framework:
4: 
5: * A single user interface, dladm, is used to configure network driver properties.
6: * A uniform syntax is used regardless of the properties: dladm //subcommand// //properties// //data-link//.
7: * The dladm interface is applied to both public and private properties of the driver.
8: * Using the tool on a specific driver does not disrupt other network connections.
9: 
10: This article elaborates on the administrative features provided by the Brussels project.
11: 
12: === Introduction and Problem Description
13: 
14: Prior to the Brussels implementation, configuring data–link parameters on a machine running the SolarisTM Operating System (Solaris OS) was needlessly difficult. Commands and interfaces were cryptic and inconsistent across the drivers, and the process often required service interruption to all connected networks, regardless of whether the connecting link was actually being impacted by the change.
15: 
16: An example of the deficiencies in these administrative methods is the refining of interface maximum transmission unit (MTU) that is typically done to enable support for the Jumbo Frame MTU. The complications are evident as described in [[an inquiry in the Sun Managers Mailing List>>http://www.sunmanagers.org/pipermail/summaries/2003-December/004776.html]].
17: 
18: === Overview of NIC Driver Properties
19: 
20: NIC driver properties that configurable by using the dladm command fall into one of two categories:
21: 
22: * **Public properties** that can be applied to any driver of the given media type such as link speed, autonegotiation for Ethernet, or the MTU size that can be applied to all data-link drivers.
23: * **Private properties** that are particular to a certain subset of drivers for a given media type. These properties can be specific to that subset because they are closely related either to the hardware that is associated with the driver or to the details of the driver implementation itself, such as debugging-related tunables.
24: 
25: Properties of a NIC driver are typically set with default values. However, certain networking scenarios might require you to change specific property settings of a NIC. These property settings can be either public or private properties. For example, a NIC might be communicating with an old switch that does not properly perform autonegotiation. Or, a switch might have been configured to support Jumbo frames. Or, driver specific properties that regulate packet transmission or packet receiving might need to be modified for the given driver. With the implementation of the Brussels project, these settings can now be reset by a single administrative tool, dladm.
26: 
27: === dladm Subcommands to Administer NIC Properties
28: 
29: For NIC drivers that have been converted to the GLDv3 framework, properties are configured by using the dladm command. This command enables you to configure the properties dynamically without causing any network disruption on other NICs of similar types. The values that you set are stored in a dladm repository and persist even after you reboot the system or unplumb the interface. Therefore, use dladm as the preferred command to configure NICs, instead of the ndd command.
30: 
31: To administer NIC drivers, you use the following dladm subcommands:
32: 
33: * dladm show-linkprop displays the properties that are associated with the data link.
34: * dladm set-linkprop sets values for specified data-link properties.
35: * dladm reset-linkprop restores property settings to the default values.
36: * dladm show-ether displays Ethernet parameter settings of a data link.
37: 
38: For more information about these commands, see the dladm(1M) man page.
39: 
40: ----
41: 
42: **Note - **Customizing NIC properties by using the dladm command is supported only in network drivers that have been converted to the GLDv3 framework, such as the following:
43: 
44: * bge – supported in SXCE build 83
45: * nge – supported in SXCE build 86
46: * e1000g – supported in SXCE build 88
47: * nxge – supported in SXCE build 88
48: 
49: Work continues to make other drivers become supported in the Brussels implementation. To confirm whether your specific driver supports this feature, refer to the driver’s man page.
50: 
51: ----
52: 
53: The following section provides procedures to set certain NIC driver properties. The selected properties are public and common to all NIC drivers. A separate section describes driver specific properties and also provides procedures to configure selected private properties of the e1000g driver..
54: 
55: === Procedures and Examples
56: 
57: The following section provides procedures with examples that show how to configure public drivers by using the dladm command.
58: 
59: ==== How to Enable Support for Jumbo Frames
60: 
61: Enabling support for Jumbo frames in a network setup is a common task for most network scenarios. Support for Jumbo frames requires increasing the size of a data link’s maximum transmission unit (MTU). The following procedure includes the use of customized names to identify data links, a feature that is introduced by the [[Clearview project>>Project clearview.WebHome]]. This [[Clearview overview document>>attach:Project clearview.docs@vnameoverview.pdf]] introduces the concept of customized link names.
62: 
63: 1. **On the system that has the link whose MTU you want to modify, assume the System Administrator role.**
64: The System Administrator role includes the Network Management profile. To create the role and assign the role to a user, see [[Chapter 9, Using Role-Based Access Control (Tasks) in //System Administration Guide: Security Services//>>http://docs.sun.com/app/docs/doc/819-3321/rbactask-1?a=view]].
65: 1. **Identify the specific Ethernet device whose MTU size you need to reset, display the links in the system.**
66: 
67: {{{
68: # **dladm show-phys**
69: }}}
70: 
71: You might need to perform this step if your network configuration uses customized names for data links. With customized names, data links are no longer necessarily identified by their hardware-based names. For example, the Ethernet device is bge0. However, the data link over the device is renamed net0. Therefore, you would need to configure the MTU size of net0. Refer to the documentation in the [[Clearview project page in OpenSolaris>>Project clearview.docs]] for examples of configuration tasks on data links that use customized names.
72: 1. **(Optional) Display the data link’s current MTU size and other properties.**
73: 1* **To display a specific property of a data link, use the following syntax:**
74: 
75: {{{
76: **dladm show-linkprop -p **//property// //data-link//
77: }}}
78: 
79: This command displays the settings of the property that you specify.
80: 1* **To display several selected properties of the data link, use the following syntax:**
81: 
82: {{{
83: # **dladm show-link **//data-link//
84: }}}
85: 
86: This command displays data-link information, including MTU size.
87: ----
88: **Note - **See How to Display Data Link in the [[Project Clearview documentation page>>Project clearview.docs]] for additional examples of the use of the dladm show-link syntax to display data-link information.
89: ----
90: 1. **Unplumb the interface that is configured over the data link.**
91: 
92: {{{
93: # **ifconfig **//interface// unplumb
94: }}}
95: 
96: 1. **Change the value of the link’s MTU size to 9000, the value for Jumbo frames.**
97: 
98: {{{
99: # **dladm set-linkprop -p mtu=9000 **//data-link//
100: }}}
101: 
102: 1. ** Plumb the IP interface over the link.**
103: 
104: {{{
105: # **ifconfig **//interface// plumb //IP-address// up
106: }}}
107: 
108: For additional options that you can use with the ifconfig command, see the ifconfig(1M) man page.
109: 1. **(Optional) Verify that the interface uses the new MTU size by using one of the command syntaxes in Step 3.**
110: 
111: {{{
112: # **dladm show-linkprop -p mtu **//data-link//
113: }}}
114: 
115: 1. **(Optional) Display the link’s current Ethernet settings.**
116: 
117: {{{
118: # **dladm show-ether **//data-link//
119: }}}
120: 
121: Example 1 Enabling Support for Jumbo Frames
122: 
123: The following example of enabling support for Jumbo frames builds on the following scenario:
124: 
125: * The system has two bge NICS: bge0 and bge1.
126: * The device bge0 is used as a primary interface, while the device bge1 is used for test purposes.
127: * You want to enable support for Jumbo frames on bge1, while you retain the default MTU size of the primary interface.
128: * The network configuration uses customized names for data links. The link name of bge0 is net0. The link name of bge1 is web1.
129: 
130: {{{
131: # **dladm show-phys**
132: LINK       MEDIA        STATE     SPEED     DUPLEX     DEVICE
133: net0       ether        up        100Mb     full       bge0
134: itops1     ether        up        100Mb     full       qfe3
135: web1       ether        up        100Mb     full       bge1
136: 
137: # **dladm show-linkprop -p mtu web1**
138: LINK     PROPERTY     VALUE     DEFAULT     POSSIBLE
139: web1     mtu          1500      1500        ~--
140: 
141: # **ifconfig web1 unplumb**
142: # **dladm set-linkprop -p mtu=9000 web1**
143: # **ifconfig web1 plumb 10.10.1.2/24 up**
144: 
145: # **dladm show-link web1**
146: LINK     CLASS     MTU      STATE     OVER
147: web1     phys      9000     up        ~--
148: }}}
149: 
150: Notice that the MTU value is now 9000. In this example, the dladm command enabled you to change web1’s MTU size directly. The previous method would have required you to unplumb net0 as well, which would have unnecessarily disrupted the primary interface’s operations.
151: 
152: ==== How to Change Link Speed Parameters
153: 
154: Most network setups consist of a combination of systems with varying speed capabilities. For example, the advertised speed between an older system and a newer system might need to be changed to a lower setting to allow communication. By default, all the speed and duplex capabilities of a NIC card are advertised. This procedure shows how to turn off the gigabit capabilities and advertise only the megabit capabilities.
155: 
156: 1. **On the system that has the NIC whose properties you want to modify, assume the System Administrator role.**
157: 1. **(Optional) Display the current status of the property you want to modify.**
158: 
159: {{{
160: # **dladm show-linkprop -p **//property// //data-link//
161: }}}
162: 
163: 1. **To advertise lower speed capabilities, turn off the higher speed capabilities to prevent them from being advertised.**
164: 
165: {{{
166: # **dladm set-linkprop -p **//property//=//value1// //data-link//
167: }}}
168: 
169: Example 2 Disabling Advertisement of a NIC’s Gigabit Capabilities
170: 
171: This example shows how you can prevent the link web1 from advertising gigabit capabilities.
172: 
173: {{{
174: # **dladm show-linkprop -p adv_1000fdx_cap web1**
175: LINK     PROPERTY             VALUE     DEFAULT     POSSIBLE
176: web1     adv_1000fdx_cap      1         ~--          1,0
177: 
178: # **dladm show-linkprop -p adv_1000hdx_cap web1**
179: LINK     PROPERTY             VALUE     DEFAULT     POSSIBLE
180: web1     adv_1000hdx_cap      1         ~--          1,0
181: }}}
182: 
183: The properties that advertise the link’s gigabit capabilities are adv_1000fdx_cap and adv_1000hdx_cap. To disable these properties from being advertised, you would type the following commands:
184: 
185: {{{
186: # **dladm set-linkprop -p adv_1000fdx_cap=0 web1**
187: # **dladm set-linkprop -p adv_1000hdx_cap=0 web1**
188: }}}
189: 
190: Listing the Ethernet parameter settings would display the following output:
191: 
192: {{{
193: # **dladm show-ether web1**
194: LINK     PTYPE       STATE    AUTO  SPEED-DUPLEX             PAUSE
195: web1     current     up       yes   1G-f                     both
196: }}}
197: 
198: ==== How to Obtain Status Information About NIC Properties
199: 
200: You can obtain information about the NIC driver’s properties by displaying either the Ethernet parameter settings or the link properties.
201: 
202: 1. **On the system that has the NIC whose properties you want to modify, assume the System Administrator role.**
203: 1. **To obtain information about the Ethernet parameter settings, use the following command:**
204: 
205: {{{
206: # **dladm show-ether [-x] **//data-link//
207: }}}
208: 
209: where the -x option includes additional parameter information about the link. Without the -x option, only the current parameter settings are displayed.
210: 1. **To obtain information about all the properties of the link, use the following command:**
211: 
212: {{{
213: # **dladm show-linkprop **//data-link//
214: }}}
215: 
216: Example 3 Displaying Ethernet Parameter Settings
217: 
218: This example display an extended list of parameter information about a specified link.
219: 
220: {{{
221: # **dladm show-ether -x web1**
222: LINK     PTYPE       STATE    AUTO  SPEED-DUPLEX             PAUSE
223: web1     current     up       yes   1G-f                     both
224: ~--       capable     ~--       yes   1G-fh,100M-fh,10M-fh     both
225: ~--       adv         ~--       yes   100M-fh,10M-fh           both
226: ~--       peeradv     ~--       yes   100M-f,10M-f             both
227: }}}
228: 
229: With the -x option, the command also displays the built-in capabilities of the specified link, as well as the capabilities that are currently advertised between the host and the link partner. The following information is displayed:
230: 
231: * For the Ethernet device’s current state, the link is up and functioning at 1 gigabits per second at full duplex. Its autonegotiation capability is enabled and has bidirectional flow control, in which both host and link partner can send and receive pause frames.
232: * Regardless of the current setting, the capabilities of the Ethernet device are listed. The negotiation type can be set to automatic, the device can support speeds of 1 gigabits per second, 100 megabits per second, and 10 megabits per second, at both full and half duplex. Likewise, pause frames can be received or sent in both directions between host and link partner.
233: * The following capabilities of web1 are advertised: autonegotiation, speed-duplex, and flow control of pause frames.
234: * Similarly, the link partner advertises the following capabilities: autonegotiation, speed-duplex, and flow control of pause frames.
235: 
236: Example 4 Displaying Link Properties
237: 
238: This example shows how to list all the properties of a link. If you want to display only a specific property, you use the -p option with the specific property that you want to monitor.
239: 
240: {{{
241: # **dladm show-linkprop web1**
242: LINK     PROPERTY             VALUE       DEFAULT     POSSIBLE
243: web1     speed                1000        ~--          ~--
244: web1     autopush             ~--          ~--          ~--
245: web1     zone                 ~--          ~--          ~--
246: web1     duplex               half        ~--          half,full
247: web1     state                unknown     up          up,down
248: web1     adv_autoneg_cap      1           1           1,0
249: web1     mtu                  1500        1500        ~--
250: web1     flowctrl             no          bi          no,tx,rx,bi
251: web1     adv_1000fdx_cap      1           1           1,0
252: web1     en_1000fdx_cap       1           1           1,0
253: web1     adv_1000hdx_cap      1           1           1,0
254: web1     en_1000hdx_cap       1           1           1,0
255: web1     adv_100fdx_cap       0           0           1,0
256: web1     en_100fdx_cap        0           0           1,0
257: web1     adv_100hdx_cap       0           0           1,0
258: web1     en_100hdx_cap        0           0           1,0
259: web1     adv_10fdx_cap        0           0           1,0
260: web1     en_10fdx_cap         0           0           1,0
261: web1     adv_10hdx_cap        0           0           1,0
262: web1     en_10hdx_cap         0           0           1,0
263: }}}
264: 
265: The settings for the speed and duplex capabilities of the link are manually configured on the enabled-speed properties which are labeled en_*_cap. For example, en_1000fdx_cap is the property for the gigabit full-duplex capability, and en_100hdx_cap is the property for the 100 megabits half-duplex capability. The settings of these enabled speed properties are advertised between the host and its link partner by corresponding advertised speed properties, which are labeled adv_*_cap such as adv_1000fdx_cap and adv_100hdx_cap. Normally, the settings of a given enabled speed property and the corresponding advertised property are identical. However, if a NIC supports some advanced features such as Power Management, those features might set limits on the bits that are actually advertised between the host and its link partner. For example, with Power Management, the values of the adv_*_cap properties might only be a subset of the values of the en_*_cap properties. For more details about the enabled and advertised speed properties, see the dladm(1M) man page.
266: 
267: === Configuring Properties Specific to the e1000g Driver
268: 
269: Brussels support for the e1000g driver is available in SXCE build 88. The driver is widely used on many Sun platforms to support the Intel® PRO/1000 Gigabit NICs, such as the Sun FireTM X4200 server, the Sun NetraTM X4450 server, and the Sun Fire T2000 server.
270: 
271: Previously, the e1000g driver, like many other NIC drivers, was configured by using the ndd command and by defining property settings in the driver’s e1000g.conf configuration file. This driver is now converted to the GLDv3 framework. Thus, the administration of its configuration can be uniformly performed just as other similarly converted drivers with the dladm command.
272: 
273: The same command can be used to adjust parameters that are specific to the e1000g driver. For example, you might need to configure the driver to use Direct Memory Access (DMA) binding for transmission instead of the bcopy mode. Likewise, you might need to reset certain interrupt parameters to improve the performance of the driver. See the procedures that show how to configure these parameters.
274: 
275: ----
276: 
277: **Note - **The nxge driver has become Brussels-supported in SXCE build 88. The driver, which is widely used on many platforms, also has nxge-specific properties. The following procedures about configuring private properties apply to the e1000g driver. However, the general procedures can also apply to the nxge driver.
278: 
279: ----
280: 
281: === Procedures and Example
282: 
283: This section provides procedures and an example that show how to configure selected private properties of the e1000g driver.
284: 
285: ==== How to Set the e1000g Driver to Use Direct Memory Access Binding
286: 
287: Bulk traffic, such as file transfers, normally involves negotiation of large packets across the network. In such cases, you can obtain better performance from the e1000g driver by configuring it to automatically use DMA binding.
288: 
289: In the following procedure, a threshold is defined for packet fragment sizes. If a fragment size surpasses the threshold, then DMA binding is used for transmitting. If a fragment size is within the threshold, then bcopy mode is used, where the fragment data is copied to the preallocated transmit buffer. For more details about this threshold and other tunables, see the [[e1000 tunables list>>Project brussels.e1000]] in OpenSolaris.
290: 
291: To set the threshold, perform the following steps:
292: 
293: 1. **On the system that has the NIC whose properties you want to modify, assume the System Administrator role.**
294: 1. **Set the appropriate value for the _tx_bcopy_threshold property.**
295: 
296: {{{
297: # **dladm set-linkprop -p _tx_bcopy_threshold=**//value// //e1000g-data-link//
298: }}}
299: 
300: For this property, the valid values for the threshold range from 60 through 2048.
301: ----
302: **Note - **As with configuring public properties, the interface must also be unplumbed before private property settings can be modified.
303: ----
304: 1. **(Optional) Verify the new threshold value.**
305: 
306: {{{
307: # **dladm show-linkprop -p _tx_bcopy_threshold **//e1000g-data-link//
308: }}}
309: 
310: ==== How to Manually Set the Interrupt Rate
311: 
312: Parameters that regulate the rate at which interrupts are delivered by the e1000g driver also affect network and system performance. Typically network packets are delivered to the upper layer of the stack by generating an interrupt for every packet. In turn the interrupt rate, by default, is automatically adjusted by the GLD layer in the kernel. However, this mode might not be desirable in all network traffic conditions. For a discussion of this issue, refer to this document ([[http://www.stanford.edu/class/cs240/readings/mogul.pdf>>http://www.stanford.edu/class/cs240/readings/mogul.pdf]]) that was presented at the USENIX technical conference in 1996. Thus, in certain circumstances, setting the interrupt rate manually becomes necessary to obtain better performance.
313: 
314: To define the interrupt rate, you set the following parameters:
315: 
316: * _intr_throttling_rate determines the delay between interrupt assertions regardless of network traffic conditions.
317: * _intr_adaptive determines whether automatic tuning of the interrupt throttling rate is enabled. By default, this parameter is enabled.
318: 
319: 1. **On the system that has the NIC whose driver properties you want to modify, assume the System Administrator role.**
320: 1. **If necessary, identify the device whose driver property you want to modify.**
321: 
322: {{{
323: # **dladm show-phys**
324: }}}
325: 
326: 1. **Disable automatic tuning of the interrupt throttling rate.**
327: 
328: {{{
329: # **dladm set-linkprop -p _intr_adaptive=0 **//e1000g-data-link//
330: }}}
331: 
332: ----
333: **Note - **When automatic tuning of the interrupt throttling rate is enabled, then any value that is set for the parameter _intr_throttling_rate is ignored.
334: ----
335: 1. **Unplumb the network interface.**
336: 1. **Set the value for the minimum inter interrupt level.**
337: 
338: {{{
339: # **dladm set-linkprop -p _intr_throttling_rate=**//value// //e1000g-data-link//
340: }}}
341: 
342: ----
343: **Note - **The default value of the _intr_throttling_rate parameter is 550 on SPARC® based systems and 260 on x86 based systems. Setting the minimum inter-interrupt level to 0 disables the interrupt throttling logic.
344: ----
345: 1. **Plumb the interface and configure an IP address for the interface.**
346: 1. **(Optional) Display the threshold’s new settings.**
347: 
348: Example 5 Configuring for DMA Binding and Setting the Interrupt Throttling Rate
349: 
350: This example uses an x86 based system with an e1000g NIC. The driver is configured with a threshold setting toggle between using DMA binding or the bcopy mode for transmitting packets. The setting for the interrupt throttling rate is also modified. Further, the e1000g data link has been renamed with a customized name. Therefore, the configuration is performed on the data link by referring to the customized name, public0.
351: 
352: {{{
353: # **dladm show-phys**
354: LINK       MEDIA        STATE     SPEED     DUPLEX     DEVICE
355: public0    ether        up        100Mb     full       e1000g0
356: 
357: # **dladm show-linkprop -p _tx_bcopy_threshold public0**
358: LINK        PROPERTY                VALUE     DEFAULT     POSSIBLE
359: public0     _tx_bcopy_threshold     512       512         ~--
360: 
361: # **dladm show-linkprop -p _intr-throttling_rate**
362: LINK        PROPERTY                  VALUE     DEFAULT     POSSIBLE
363: public0     _intr-throttling_rate     260       260         ~--
364: 
365: # **ifconfig public0 unplumb**
366: # **dladm set-linkprop -p _tx_bcopy_threshold=1024 public0**
367: # **dladm set-linkprop -p _intr_adaptive=0 public0**
368: # **dladm set-linkprop -p _intr-throttling_rate=1024 public0**
369: # **ifconfig public0 plumb 10.10.1.2/24 up**
370: 
371: # **dladm show-linkprop -p _tx_bocopy_threshold=1024 public0**
372: LINK        PROPERTY                VALUE     DEFAULT     POSSIBLE
373: public0     _tx_bcopy_threshold     1024      512         ~--
374: 
375: # **dladm show-linkprop -p _intr_adaptive public0**
376: LINK        PROPERTY           VALUE     DEFAULT     POSSIBLE
377: public0     _intr-adaptive     0         1           ~--
378: 
379: # **dladm show-linkprop -p _intr-throttling_rate**
380: LINK        PROPERTY                  VALUE     DEFAULT     POSSIBLE
381: public0     _intr-throttling_rate     1024      260         ~--
382: }}}
383: 
384: === Ongoing Work
385: 
386: The Brussels ndd compat component will provide additional functionality in the Framework for legacy support of the ndd(1m) commands so that drivers will not have to include complex and undocumented interfaces to support the ndd command.
387: 
388: Also, the Brussels Persistence component will add additional functionality to allow the property settings to be automatically applied across reboot and driver restart.
389: 
390: Future articles will describe the details of the Framework, as well as the methods used to provide ndd compatibility and persistent property settings.
391: 
392: Work also continues to provide a GUI to administer data links. A prototype of the GUI is available at the OpenSolaris project page. The prototype is an interactive GUI for demonstration purposes. Please send feedback to the [[Brussels discussion list>>mailto:brussels-dev@opensolaris.org]].
393: 
394: Access to the Brussels-supported command-line interfaces is now available in the OpenSolaris 2008.05 release.
OpenSolaris

Top Menu

Wiki code for Brussels White Paper

Search

Collectives

Community Group

Project

User Group

Subsites

Project brussels Pages
