On Sun, 8 May 2016, Ben Hutchings wrote:
> > Would a patch that maps 0 to 'no coalescing' be acceptable? That is: > > > > rx-usecs = 0 -> coalescing disabled. > > rx-usecs = 1 -> default (chosen by the device). > > rx-usecs = 2 -> adaptive coalescing. > > rx-usecs = 3 -> static coalescing. > > I still don't like it much. For the 3 special values (0 isn't really > special): > > 1 = default: When the driver sets the virtual device to this mode, can it > then read back what the actual settings are, or are they hidden? If it can, > then userland can also read the defaults and explicitly return to them later. > But I do see the usefulness of an explicit request to reset to defaults. > > 2 = adaptive coalescing: There are already fields to request adaptive > coalescing; you should support them. > > 3 = static coalescing: I don't understand what this means. static refers to the number of packets to batch before raising an interrupt - which maps to existing tx_max_coaleced_frames. Have sent out v2 of the patch that no longer uses special values of rx-usecs to distinguish between the coalescing modes. Existing ethtool_coalesce fields are used as appropriate instead. In v2, driver can no longer issue "revert to defaults" command (think such a mechanism might be useful addition but belongs to ethtool framework). Thanks, Shri
