Re: [PATCH] Rate should be u64 to avoid integer overflow at high speeds (>= ~35Gbit)

[Eric Dumazet <eric.dumazet@gmail.com>]

On Wed, 2013-03-13 at 02:01 -0400, Bill Fink wrote:

> The last time this was discussed appears to be (on 2011-03-28):
> 
> 	http://marc.info/?l=linux-netdev&m=130128741907282&w=2
> 
> where Maciej Żenczykowski argued that creating a new 64-bit
> Netlink attribute for this would be much more complex than for
> the IFLA_STATS64 support.  There was no reply.
> 
> Providing a new multiplier/shift parameter would be a simple
> way to extend support for higher rates, and would not break
> existing user space that doesn't require the higher rates.
> I imagine the user would not explicitly specify the multiplier/
> shift parameter, but would just normally specify the desired
> rate, and a newer tc would figure out what multiplier/shift
> to use if a high enough rate demanded it.  To maintain user
> space compatibility, the kernel should report back the same
> rate and multiplier/shift it was given, and the newer tc would
> convert it back to the user's originally specified rate.  Older
> user space that was fine with the ~34 Gbps rate limitation would
> always have the default multiplier of 1 or shift of 0 bits, and
> would see the exact same unmultiplied/unshifted rate it always
> did.


We already said no to such a hack. Maybe its not clear enough ?

netlink allows us to a proper way, and Thomas Graf explained how we
expect the thing to be done.

Yes, this is not a one liner patch, its a bit more of work, and its how
it will be done when someone does the job.


> I also believe 32 bits of precision is significant enough
> at these higher data rates.
> 

This has nothing to do with the issue. Thats an implementation detail in
the kernel. And frankly with 64bit arches we better use 64bit native
fields, instead of adding arbitrary limits.

We are speaking of the netlink message itself and old binaries.