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.
- Garrett
>
> -Vasumathi
