Date: Wed, 25 Mar 2015 13:03:37 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Hans Petter Selasky <hps@selasky.org> Cc: Emeric POUPON <emeric.poupon@stormshield.eu>, freebsd-net <freebsd-net@freebsd.org>, Adrian Chadd <adrian@freebsd.org> Subject: Re: Fragment questions Message-ID: <20150325200337.GE51048@funkthat.com> In-Reply-To: <550C6D65.6070409@selasky.org> References: <522774578.25519037.1426765109046.JavaMail.zimbra@stormshield.eu> <550AC709.1050404@selasky.org> <2047974073.25663527.1426858267777.JavaMail.zimbra@stormshield.eu> <550C5FC6.6020401@selasky.org> <CAJ-Vmo=LkFc4sqbBSVeLE=7adV1nCuRDUO4ECUv8r6EYp=Oezw@mail.gmail.com> <550C6D65.6070409@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hans Petter Selasky wrote this message on Fri, Mar 20, 2015 at 19:56 +0100: > On 03/20/15 19:02, Adrian Chadd wrote: > > On 20 March 2015 at 10:58, Hans Petter Selasky <hps@selasky.org> wrote: > >> On 03/20/15 14:31, Emeric POUPON wrote: > >>> > >>> - in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use > >>> randomized id. > >> > >>> In multi core systems, we may emit successive packets with the same id. > >> > >> Will using a mutex or an atomic macro fix this issue when incrementing the > >> V_ip_id ? > > > > It will, but it'll ping-pong between multiple cores and slow things > > down at high pps. > > Maybe we can have the V_ip_id per CPU and use the lower 8-bits as random > CPU core number? ip id's only need to be unique for fragments to a specific source address/destination address/protocol tuple... so, using different id buckets per above hash would be best... Take a look at: https://tools.ietf.org/html/rfc6864 Which is a good read for addressing this issue... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150325200337.GE51048>