On Fri, Jan 09, 2009 at 12:30:21AM -0500, Jeff Garzik wrote:
quoted text
>
> Actually it's just the opposite -- _the_ most common complaint from  
> users and driver developers of the ethtool interface, over the years,  
> has been that there is no way to collect all the modifications and then  
> commit it to hardware all in one go.

Yes that's a problem for flags that require the drivers to reset
itself.

quoted text
> Each new ethtool command added often winds up pausing and resetting the  
> hardware completely, and ETHTOOL_SGRO is no exception.

But as I explained before, GRO (like GSO) is purely a software
setting, it has nothing to do with the driver at all.  In other
words we don't need the driver to reset or do anything.

If anything by going into the driver's set_flags function as you
suggested may cause a spurious reset that wouldn't have happened
otherwise.

So for software flags like GSO/GRO at least, I don't see any
benefit in going to a multi-bit interface.  On the flip side,
I see potential complications with a multi-bit interfaces that
simply don't exist with a single-bit interface.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html