> On 28 Mar 2015, at 17:23 , John-Mark Gurney <j...@funkthat.com> wrote: > > Gleb Smirnoff wrote this message on Sat, Mar 28, 2015 at 11:34 +0300: >> On Fri, Mar 27, 2015 at 01:26:59PM +0000, Fabien Thomas wrote: >> F> Author: fabient >> F> Date: Fri Mar 27 13:26:59 2015 >> F> New Revision: 280759 >> F> URL: https://svnweb.freebsd.org/changeset/base/280759 >> F> >> F> Log: >> F> On multi CPU systems, we may emit successive packets with the same id. >> F> Fix the race by using an atomic operation. >> F> >> F> Differential Revision: https://reviews.freebsd.org/D2141 >> F> Obtained from: emeric.pou...@stormshield.eu >> F> MFC after: 1 week >> F> Sponsored by: Stormshield >> >> The D2141 says that benchmarking were done in presence of IPSEC, which >> of course is the bottleneck and performance of this instruction can't >> be benchmarked in its presence. Anyway, I believe that results of >> right benchmark would still show little difference between atomic and >> non-atomic increment of a shared value. >> >> I think we can use per-cpu ID counters, each CPU incrementing its >> own. If we start with random values, then probability of two packets with >> the same ID emitting at the allowed timeframe will be acceptably small. > > Please do not use per-cpu id counters.. That will just push the > duplicate ids to being more rare, but just as much of a problem... > > Please read: > https://tools.ietf.org/html/rfc6864 > > And then implement one hased upon source/dest/protocol…
and if someone is interested in reviving this as well (read the old thread from then on net@) https://people.freebsd.org/~bz/20110313-01-rfc6056.diff — Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend." _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
