Here are my notes on the problem so far. Nothing incredibly new, just an
attempt to systematize what we already know.
-Artem
Problem:
Typically, link properties are "pushed" into drivers via ioctl, which is
what dladm {init,set}-linkprop do. Sometimes, however, drivers need to
actively request ("pull") properties.
Constraints:
C1. There are no kernel APIs to retrieve link properties from the
backing store (we can read linkprop.conf today, but that will break when
the store moves to SMF) - which means that before driver requests can be
satisfied, properties must be pushed into the kernel by some userland
agent. There is no way around that.
C2. Drivers may need properties as early as attach(9E).
So any solution revolves around caching properties in the kernel, in one
form or another.
1. Promiscuous caching
Populate kernel cache with all properties at boot time and refresh it
every time libdladm updates the backing store.
Pros:
- Simple
Cons:
- Wastes kernel memory. (What if we use pageable memory via segkp?
Network drivers should be able to tolerate page faults if they don't
access properties from interrupt context.)
2. Selective caching
Constraint C2 makes selective caching hard, because device configuration
is kernel-driven and nothing in userland can predict when a particular
device is attached in order to pre-populate cache for that device. (E.g.
hooking into 'ifconfig plumb' is not an option, because so many other
system activities can trigger network driver load-and-attach, like an
innocent 'ls /dev/bge*').
2.1. In our current Brussels prototype, drivers explicitly request the
mac layer to populate property cache for {macname,instance}. It can be
done at any point, including attach(9E). The mac layer performs a door
call to the userland daemon, which pushes the corresponding properties
into the kernel before returning the door call. Cached properties are
removed upon mac_unregister().
Pros:
- Saves kernel memory
- No impact on drivers that don't pull properties
Cons:
- Daemon, kernel->user dependency, door file in /etc: lots of
redundant cruft to solve a small problem.
2.2. DACF pre-attach
DACF only provides post-attach, but it was proposed that pre-attach
could be added, and used to load link properties before instance
attach(9E) is invoked. DACF is a purely kernel framework, with no ties
to userland.
Cons:
- Assumes macname == driver name (2.1 allows them to be different)
- Loading properties into the kernel pre-attach does not provide any
apparent benefits compared to loading them during attach. Why bother
with extending DACF?
