[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <513F3BE1.2080409@genband.com>
Date: Tue, 12 Mar 2013 08:29:53 -0600
From: Chris Friesen <chris.friesen@...band.com>
To: Eric Dumazet <eric.dumazet@...il.com>
CC: Bill Fink <billfink@...dspring.com>, Vimal <j.vimal@...il.com>,
netdev@...r.kernel.org, shemminger <shemminger@...tta.com>
Subject: Re: [PATCH] Rate should be u64 to avoid integer overflow at high
speeds (>= ~35Gbit)
On 03/09/2013 11:54 PM, Eric Dumazet wrote:
> On Sun, 2013-03-10 at 00:49 -0500, Bill Fink wrote:
>
>> I don't see the problem. An old program would not know about
>> the new multiplier, would thus get the default multiplier of 1,
>> and get the same behavior as always, with the same limitation
>> of ~34 Gbps. But someone with a newer tc/kernel could for example
>> specify a multiplier of 10, which would then support rates up to
>> about 340 Gbps. It sounds like a reasonable approach to me.
>
> Hopefully, some of us see the problem here and are able to reject
> patches before breaking user land.
The only problem I see is that you can't set the multiplier with a new
tool and then query the rate with old tools.
But you're going to run into that problem with the old tools no matter
what you do--and not doing anything is a crappy option as well.
Some kind of multiplier or shift makes as much sense as anything else.
With old tools you get current behaviour, with new tools you can specify
a multiplying factor to trade off resolution vs precision.
Chris
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists