Yes, sure! I will test it tomorrow and tell you the results. However, keep in mind I did not see any performance impact with the previous patch.
Regards, ----- Mail original ----- De: "Gleb Smirnoff" <gleb...@freebsd.org> À: "Emeric POUPON" <emeric.pou...@stormshield.eu> Cc: "Slawa Olhovchenkov" <s...@zxy.spb.ru>, "Hans Petter Selasky" <h...@selasky.org>, "Adrian Chadd" <adr...@freebsd.org>, src-committ...@freebsd.org, "Ian Lepore" <i...@freebsd.org>, svn-src-all@freebsd.org, svn-src-h...@freebsd.org, "Fabien Thomas" <fabi...@freebsd.org> Envoyé: Lundi 30 Mars 2015 17:27:07 Objet: Re: svn commit: r280759 - head/sys/netinet On Mon, Mar 30, 2015 at 05:23:48PM +0200, Emeric POUPON wrote: E> Hello, E> E> Sorry for late response, I didn't notice this issue was discussed here. E> E> In one of our tests, we have several (up to 12) cpu that emit packets with the same src, dst and protocol to a remote host. E> We did this patch since we observed bad packet reassembly on the remote host, due to different fragments emitted with the same ip id. E> It was an IPsec test (emitting ESP packets) but I guess we could easily reproduce this problem using several "ping -i 0 -s BIG_SIZE_HERE DST" commands running in parallel. E> E> Even if we reached something like 1M pps, it is likely that we did not see any performance penalty since the IPsec stack is quite time consuming. E> Now, the question is: is there a real performance issue here or is it likely to be hidden by other problems? E> E> If it is a real problem, maybe an acceptable tradeoff would be to make the counter per CPU and: E> - initialize it with the cpu id, E> - increment it by the number of cpus. E> E> What do you think? I already posted a patch that makes the counter per CPU. Can you please test it? -- Totus tuus, Glebius. _______________________________________________ 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"
