Monday July 14, 2008

New in snv_93: dladm link property persistence

I once joined a pickup basketball game and one of my teammates only noticed me after three or four possessions. Another teammate tried to be supportive and used the word "stealth" to characterize my role in the game (my own choice was "zero impact"). Story of my life.

But sometimes that's a good thing. A lot of OS improvements are like that, incremental in nature, not visible to most users, but contributing to the overall movement towards better future. Not quite the shouting from the rooftops material, but noteworthy to geeks and search engines.

Such is my recent putback, a followup to the earlier Brussels framework putback. Originally, properties set via dladm set-linkprop were not guaranteed to persist when a link was unplumbed and later replumbed. One would have to reapply the properties using the undocumented init-linkprop subcommand:

ifconfig link0 plumb
dladm init-linkprop

My putback makes it automatic. No need to reapply the properties manually anymore.

What happens under the hood is a bit more complicated. dladm shows you all links the system knows about:

# dladm show-link
LINK        CLASS    MTU    STATE    OVER
bge0        phys     1500   up       --
iprb0       phys     1500   unknown  --
iprb1       phys     1500   unknown  --

This information, along with link properties, is stored in /etc/dladm/datalink.conf. The kernel, however, only needs to know about links that are currently in use. What the kernel knows can be extracted from mdb:

# mdb -k
> *i_dls_devnet_id_hash::modhash -e | ::modent -v | ::print dls_devnet_t dd_spa
dd_spa = [ "bge0/0" ]

Generally, a link becomes in use when its corresponding device file under /dev/net is first opened. That's what happens, for instance, when you plumb the link. This is the moment the kernel learns about the link. This is also the moment a new thread is launched, which communicates with the datalink management daemon, dlmgmtd(1M). It requests the daemon to perform the equivalent of dladm init-linkprop for this new link. The daemon extracts property data from datalink.conf and pushes it into the kernel.

There are still two cases when persistence is not guaranteed: wifi links and private properties. The following CRs have been filed and are being worked on:

6691666 link property persistence for wifi drivers
6688428 dladm init-linkprop ignores private properties

(2008-07-14 12:10:57.0) Permalink

Wednesday October 03, 2007

Kicking it Brussels-style

After 7 years of pretending to know something about I/O, I decided to see if I can pull the same trick with networking. The first project I chose to sabotage is Brussels. Project's mission can be described with a thousand words, but, the creative type that I am, I drew you a cool picture:

The first bit of code I've just contributed (here's the webrev) is mainly for the MAC services module. I added per-link property handles, which the network drivers can use like so:

    err = mac_prop_init("driver", instance, &handle);
    val = mac_prop_get_uint64(handle, "property");
    mac_prop_fini(handle);

For each plumbed link, MAC keeps a list of properties that ever entered the kernel. Pointers to these lists are stored in a hash table, using link name as a key. I also added MDB support for these data structures. The mac_proplist walker walks the hash table entries, and the mac_prop walker walks the property list, so you can say stuff like:

> ::walk mac_proplist | ::walk mac_prop | ::print mac_prop_t

Even more convenient is the new ::mac_prop dcmd (which internally uses the above walkers):

> ::help mac_prop

NAME
   mac_prop - display MAC properties of a link or all links

SYNOPSIS
   ::mac_prop [link]

ATTRIBUTES

   Target: kvm
   Module: mac
   Interface Stability: Unstable

 > ::mac_prop
            ADDR LINK             PROPERTY         SIZE VALUE
fffffffec7d80480 bge0             default_mtu      8    1500
fffffffec7d80a80 bge0             adv_autoneg_cap  1    1
 >

There wasn't an existing MDB module for MAC, so I created it too. Here's a good opportunity for other contributors to the MAC layer, hint hint, to add more MAC data structures to MDB.

(2007-10-03 16:40:52.0) Permalink