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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20130310004904.de508bfa.billfink@mindspring.com>
Date:	Sun, 10 Mar 2013 00:49:04 -0500
From:	Bill Fink <billfink@...dspring.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	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 Sun, 10 Mar 2013, Eric Dumazet wrote:

> On Sat, 2013-03-09 at 20:53 -0800, Vimal wrote:
> > Ok, do you have suggestions on how to do this?  Maybe a better way to
> > do this would be to introduce an additional "multipler" option for
> > rates, which is set to 1 as default, so actual rate can be computed as
> > multipler * rate supplied.
> 
> How an old program, in binary form, will automatically knows it has to
> change its behavior to use an inexistent field ?
> 
> I can use an old distro, and update kernel to upstream kernel, it must
> continue to work.

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.

						-Bill
--
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