On Jun 9, 2009, at 1:47 PM, Garrett D'Amore wrote:
> Vasumathi Sundaram wrote:
>> Garrett D'Amore wrote:
>>> Do we really need to touch the framework for this? I'm of the
>>> opinion that these debugging overrides might better be handled as
>>> driver-private tunables ("private properties"), without making the
>>> framework aware of them explicitly.
>>>
>>> Admittedly, its not that big a deal one way or the other....
>>>
>>> - Garrett
>>>
>>> Sebastien Roy wrote:
>>>> I'm sponsoring this fast-track for Vasumathi Sundaram, the timer
>>>> expires
>>>> on 06/15/2009.
>>>>
>>>> LSO and HW TX Checksum properties in dladm
>>>> ------------------------------------------
>>>>
>>>> 1. Summary
>>>> ----------
>>>>
>>>> This case proposes to add two properties "lso" and "hw_tx_cksum" to
>>>> dladm, to allow the LSO and Transmit HW checksum properties of the
>>>> driver to be updated on the fly at runtime.
>>>>
>>>> Release binding:
>>>> Patch
>>>>
>>>> 2. Description
>>>> --------------
>>>>
>>>> To ensure the correct operation of any driver that supports LSO and
>>>> hardware checksum, it is often required to turn the properties on
>>>> or
>>>> off for debugging. An example will be the nxge driver, that has
>>>> different values for the hardware checksum capability to workaround
>>>> hardware bugs.
>>>>
>>>> Currently, to enable/disable the Transmit HW checksums and LSO
>>>> properties in a driver, the driver's .conf file needs to be
>>>> updated to
>>>> set the capabilities, and the interface has to be unplumbed and
>>>> plumbed for the settings to take effect. When the interface is
>>>> replumbed, the driver announces its LSO/HW Checksum capabilities to
>>>> GLD which is then passed up to its clients.
>>>>
>>>> Since dladm provides more consistent interfaces to set link
>>>> properties, LSO and TX HW checksum should be added as link
>>>> properties
>>>> that can be enabled or disabled at runtime without requiring to
>>>> modify
>>>> the driver's .conf file and the unplumb/plumb sequence.
>>>>
>>>> To support this, the command 'dladm show-linkprop' will now display
>>>> two additional properties "lso" and "hw_tx_cksum" for each driver.
>>>> This is achieved by adding two new MAC properties MAC_PROP_LSO and
>>>> MAC_PROP_HCKSUM to the enum mac_prop_id_t in
>>>> /usr/src/uts/common/sys/mac.h. These properties will apply to all
>>>> datalinks of type DL_ETHER.
>>>>
>>>> Each driver that supports LSO and TX Hardware checksum should
>>>> include
>>>> cases for MAC_PROP_LSO and MAC_PROP_TX_HCKSUM in
>>>> <driver>_m_setprop()
>>>> and <driver>_m_getprop() callback functions to set and get the
>>>> current
>>>> and possible values. dladm will not list these properties for those
>>>> drivers that do not support them. Whenever one of these
>>>> properties is
>>>> enabled or disabled through <driver>_m_setprop(), the driver should
>>>> call mac_capab_update (MAC_NOTE_CAPAB_CHG) to initiate capability
>>>> renegotiation with upper layers, which prevents the needs for the
>>>> unplumb-plumb of the interface.
>>>>
>>>> 3. Interface changes
>>>> --------------------
>>>>
>>>> | Interfaces
>>>> Exported |
>>>> |______________________|__________________________|
>>>> _______________________|
>>>> | Interface | Classification |
>>>> Comments |
>>>> |______________________|__________________________|
>>>> _______________________|
>>>> | |
>>>> | |
>>>> | MAC_PROP_LSO | Consolidation Private | <sys/
>>>> mac.h> |
>>>> | MAC_PROP_HCKSUM | Consolidation Private | <sys/
>>>> mac.h> |
>>>> | lso | Committed | dladm
>>>> property name |
>>>> | hw_tx_cksum | Committed | dladm
>>>> property name |
>>>> |______________________|__________________________|
>>>> _______________________|
>>>>
>>>>
>>>> A sample output is as follows:
>>>> LINK PROPERTY PERMS VALUE
>>>> DEFAULT POSSIBLE
>>>> e1000g0 lso rw 1
>>>> 1 1,0
>>>> e1000g0 hw_tx_cksum rw 1
>>>> 1 1,0
>>>>
>>>>
>>>>
>>>
>> There is a mail thread in opensolaris.org from where came the
>> motivation for making these part of dladm.
>> http://www.opensolaris.org/jive/thread.jspa?threadID=91957&tstart=75
>>
>> To cite Andrew Gallatin from the thread,
>> "...in general, I agree there should be some way to change what
>> stateless offloads are in use at runtime. Solaris is way behind
>> here. For example, the BSDs do it via ifconfig (to disable
>> TSO on "mxge0": ifconfig mxge0 -tso), Linux does it via the
>> horribly cryptic ethtool (to disable TSO on eth2:
>> ethtool -K eth2 tso off)."
>>
>> It seems there are a lot of people who want to do this often and
>> making them public will make it easier.
>
> "often"? I think the only people who need this are individual
> driver developers. What is needed is a driver tunable (which can be
> per driver private) to enable it, and then a renegotiation with IP
> for the device capabilities.
Disagree on the driver tunable aspect. As pointed out, other OSes make
this a configurable aspect during run time. Relegating *SO options
(and other such features) in Solaris to bound-to-be-inconsistent
driver.conf variables, effectively requiring a reboot to have changes
take effect, is sub-optimal.
See jumbo frames as an example. Management of that is now consistent
through dladm where in the past you had to do any combination of /etc/
system or driver.conf voodoo. Jumbo is a feature. VLAN tagging is a
feature. WhateverSO is also a feature. Features should be manageable
through dladm and consistent property names across drivers, regardless
of how useful one may think this could be.
Sure, the setting could possibly be turned on or off on a live system
via ndd, but I guarantee you given history that different drivers will
call that variable by different, private names (inconsistency) and not
all might allow it to be changed on-the-fly (more inconsistency).
The setting should default to 'driver knows best' and be available for
changing through dladm.
/dale
> - Garrett
>>
>> -Vasumathi
>
> _______________________________________________
> opensolaris-arc mailing list
> opensolaris-arc at opensolaris.org
