sowmini
Brussels ndd compatibility changes are in Nevada 90
More good news- the fixes for
PSARC/2008/171 Brussels: NDD compatiblity support
and
PSARC/2008/175 Brussels framework enhancements to get/set defaults
have been put back into snv_90. With these changes, ethernet drivers which have used ndd(1m) to configure MII parameters no longer have to provide code to hande ND_SET and ND_GET ioctls - the GLDv3 layer will automatically translate the ndd ioctls into equivalent setprop/getprop commands and invoke the drivers registered entry points.
For design details, check out the nddcompat design doc at the OpenSolaris Brussels project page.
We've also put out a White Paper summarizing what features are available through Brussels, and when/how one would use them. Hope you find the information useful!
Coming soon: Brussels Persistence, so that you can just tune once, and have the setting available for the next restart.
Posted at 02:08PM May 02, 2008 by sowmini in Personal | Comments[0]
Brussels support for nge driver now available in nv86.
Miles Xu and Jason King have putback changes to plug nge into the Brussels framework in SNV yesterday, so that snv86 will now have an nge driver that is configurable through Brussels!
Check out Miles blog describing this new feature!
Posted at 05:39PM Mar 26, 2008 by sowmini in Sun | Comments[0]
Brussels framework putback to snv_83!
PSARC 2007/429 was putback Jan 24 2008! This putback provides a configuration framework for administering network drivers through the GLDv3 framework in Solaris Nevada. This feature should be available on bfu archives built on/after Jan 25 2008, and in snv_83.
This feature has a few ramifications for Network device-driver developers:Project teams that propose new network drivers should no longer need to provide ndd(1m) entry points for administering their driver. Instead, such drivers should provide setprop and getprop entry points as defned in PSARC 2007/429.
The putback of PSARC 2007/429 also converts the bge driver to the Brussels framework, so that the recommended method for administering properties of the bge driver is using the dladm(1m) command.
Information about the Brussels framework, including documentation of the driver interfaces for Brussels can be found at http://opensolaris.org/os/project/brussels
A preview of the draft dladm(1M) man page is also available for those wishing to use the new features introduced by the Brussels/Clearview projects at http://www.opensolaris.org/os/project/clearview/dladm-uv-brussels.1m.txt
What's next?
- convert more drivers to plug into the Brussels framework- e1000g and igb drivers are next on the pipeline with more to come soon,
- implement the Peristence feature by leveraging on the dlmgmtd provided by Project Clearview. This will allow dladm(1m) to be used for persistently setting tunable values, and the setting will automatically be incorporated at the next restart of the driver (or reboot)
- For legacy drivers, we will clean up the ioctl code path so that the ndd ioctl goes through the Brussels framework (though we will continue to provide legacy support for existing ndd usage in datalink drivers). Details coming soon!
- Phase 0 cleanup of ndd abuse/deficiencies in the TCP/IP layer: e.g., inappropriately use of ndd(1m) in debugging kernel data-structures, when better tools like dtrace and mdb are available, we have a profusion of ndd commands (e.g., for /dev/rts) that are poorly documented and understood. Shrinking this abuse to the bare essentials will place us in a better situation to evaluate alternatives/enhancements to ndd(1m)
Posted at 07:04AM Jan 25, 2008 by sowmini in Sun | Comments[0]
Interactive GUI prototype for Brussels
Brussels has just put out an interactive mock-up of a GUI prototype- we're looking for feedback from our users!
[Read More]
Posted at 07:04AM Nov 09, 2007 by sowmini in Personal | Comments[0]
Brussels and data link administration
Solaris has a lot of cutting-edge tunable features implemented in its network drivers, but administering these features remains a somewhat chaotic story.Even a frequently tuned property like Jumbo Frame MTU can be quite a bear to administer, as Shantnu recently discovered.
And there are more of these instances. For example, driver writers are frequently confused about the expected semantics for ethernet flow-control in solaris . Even Solaris engineers are sometimes confounded by the existing definitions.
The good news is that Sun is working on improving these interfaces and bringing in a cleaner administrative interface. The project is Brussels and its objectives are to pull together the best of the exisiting methods, so that
- like ndd, we can configure properties on the fly,
- like driver.conf, we can configure properties like Jumbo Frames (but without the teeth gnashing syntax) and have them persist across reboot
- leverage from the flexible syntax and other features (like the show- subcommands) introduced in dladm(1m), while making this play nicely with smf
- have a uniform, intuitive syntax for configuring properties (no more head scratching over whether its link_duplex or link_mode, and if it should be 0 for half-duplex, or 1 for half-duplex!)
The most important requirement to make this succesful is feedback from Administrators about what you would like to see implemented in Brussels- so please contribute your input! Here are some examples of the improvements being introduced by Brussels..
For
example, Brussels introduces the "show-ether" sub-command in dladm that
will allow the administrator to view the status of the ethernet
network. In the vanilla invocation, # dladm show-ether bge1
LINK PTYPE STATE AUTO SPEED-DUPLEX PAUSE
bge1 current up yes 1G-f tx
Which
says that the bge1 interface is UP (i.e., the driver is is RUNNING)
with autonegotiation enabled, speed 1Gbps, full duplex. It also
shows that flow control is in the "tx" (Transmit) direction only, i.e.,
we will send pause frames when congested, but ignore any received pause
frames from the peer.
I can get "extended" output :# dladm show-ether -x bge1
The
additional rows tell me the hardware capabilities of the local endpoint
("capable") , those advertised to the peer ("adv") and those advertised
by the peer ("peeradv").Note that the speed-duplex capabilites of bge1
are (1G, full duplex), (1G, half-duplex), (1000 Mbps, full duplex),
(1000 Mbps, half duplex), (10 Mbps, full duplex), (10Mbps, half
duplex). Although my bge1 driver is capable of bi-directional
flow-control, it has been administratively configured to advertise TX
only. Since the peer is advertising bi-directional flow control,
I try:
LINK PTYPE STATE AUTO SPEED-DUPLEX PAUSE
bge1 current up yes 1G-f tx
-- capable -- yes 1G-fh,100M-fh,10M-fh bi
-- adv -- yes 1G-f tx
-- peeradv -- yes 1G-f bi
# dladm set-linkprop -p flowctrl=bad bge1 # I have a syntax error!
So I correct my error, and now have the state:
dladm: warning: link property 'flowctrl' must be one of: no,rx,tx,bi# dladm set-linkprop -p flowctrl=bi bge1
# dladm show-ether -x bge1
LINK PTYPE STATE AUTO SPEED-DUPLEX PAUSE
bge1 current up yes 1G-f both
-- capable -- yes 1G-fh,100M-fh,10M-fh both
-- adv -- yes 1G-f both
-- peeradv -- yes 1G-f both
We are also adding better observability into the kernel state- see Artem's blog
on the new mdb macros that will make it possible to look at a crash
dump or a running kernel's mdb state and figure out what customizations
(including Private properties, known only to the driver!) have been
applied.
Posted at 09:59AM Oct 11, 2007 by sowmini in Sun | Comments[0]
surya delivered into Nevada!
Surya has been delivered into snv, and should be available via SX 11/06!
For
my next challenge, I'm going to look at the problem of providing a
simple, intuitive interface for driver configuration .. the current
methods (there are more than one of these!) involve arcane
incantations, sometimes done via <driver>.conf files, sometimes
via ndd, sometimes via kstat(1m), sometimes via system(4), and,
on occasion, through all of these methods! All of this is needlessly
complex: dladm(1m) interfaces should be used to provide a
standardized interface for driver configuration.. watch this space for details !
Posted at 05:46AM Nov 25, 2006 by sowmini in Sun | Comments[0]
Introduction
I've been in the kernel networking group at Sun for about 6 years now,
working on various aspects of routing (in.routed, zebra/quagga,
forwarding table performance). In the past, I have worked in
diverse companies on various aspects of networking, including
Parametric Technology Corp where I worked
on interfaces to SUNRPC libraries for CAD tools, in DEC/Compaq
where I was doing kernel networking for Tru64 UNIX (IPv6, iptunnels,
802.3ad, kernel routing), and even briefly at
LANL where I worked on PVM/MPI.
My current passion is the Surya project, where Sangeeta Misra and I
are attempting to stream-line the packet-processing path, while
replacing the existing forwarding-table data-structures/code with
the FreeBSD radix tree. Check out the details in the
design document.
My other pastime is to train myself to become a dtrace "power user".
I'm putting together a
DTrace Networking Cookbook
Contributions of all shapes and sizes are invited!
Posted at 01:37PM May 04, 2006 by sowmini in Sun | Comments[1]