Date: Fri, 20 Mar 2015 12:04:44 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Hans Petter Selasky <hps@selasky.org> Cc: Emeric POUPON <emeric.poupon@stormshield.eu>, freebsd-net <freebsd-net@freebsd.org> Subject: Re: Fragment questions Message-ID: <CAJ-Vmo=a6nzfRFH1cu0VefGk1opJf4WAt6u7ugT0uRMbjWvA-A@mail.gmail.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
On 20 March 2015 at 11:56, Hans Petter Selasky <hps@selasky.org> wrote: > 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. >> > > Hi, > > Maybe we can have the V_ip_id per CPU and use the lower 8-bits as random CPU > core number? Hm, someone with more cycles to spend on analysing the repercussions from this should investigate it. I think in the short term using an atomic is fine, as it's no worse than what is currently there. But as we get more PPS unlocked and happening we may need to fix it. -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=a6nzfRFH1cu0VefGk1opJf4WAt6u7ugT0uRMbjWvA-A>