Having applied this to HEAD I find that with the following test:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 24 2016
I'll give this a benchmark in the Sentex lab.
Mar 23 2016
Mar 22 2016
Updates to get all the return values out.
Mar 21 2016
Address comments from bz@
Update m_getcl provider to also pass the flags.
Mar 19 2016
Add the mbuf.d translation file.
Add translators.
Mar 16 2016
I've added Olivier as a reviewer because I'm hoping he'll test this patch and give us some updated performance numbers.
It looks like most of the issues are addressed and this can go in. I've not run the code but I have read it over.
Mar 14 2016
Mar 9 2016
4102 has already gone in. It's time to push this in as well.
Mar 4 2016
Mar 3 2016
Feb 25 2016
Feb 22 2016
Feb 20 2016
I wonder if you can get some pmc results on this code to see what's causing the difference? I suspect caching issues, but that's just a guess. I'm going to move forward with a change to how this all works in HEAD, following the suggestion in the comment. that will take a while to work out because icmp_error() likes to free mbufs and if we have one on the stack that will not go well.
Feb 19 2016
I'm not sure how that trace could be related to this but if I can get a core dump it might help.
What I found in my setup was that this reduced performance by 5% but that is a pull back from a 25% increase. Can you also compare this against plain forwarding on 10.2? The comparisons that matter are:
Feb 18 2016
Thanks.
Feb 13 2016
If someone wants this to happen it has to be taken up by the project NOW. The original author has moved on. Or, you know, we could just abandon good work on this for the Nth time.
Feb 10 2016
We are programming in C and not assembler. Please make the requested change to a typically C idiom.
Feb 5 2016
If the performance is the same then I think using the tried and true algorithm wins out over putting a new one in specifically just for this case.
Feb 4 2016
Feb 3 2016
Approved.
Jan 21 2016
I'm a bit confused by this proposal. No protocol I know of has a port field larger than 16 bits. How and where might this be applied?
Jan 20 2016
Can we see some numbers that support switching from the well known, and validated, qsort() to this private version of mergesort? If this is a win then we probably want an abstracted version of this to sit along side our qsort.
Jan 19 2016
Jan 18 2016
Has this been updated based on all the recent rototilling?
Jan 17 2016
I'm down with this but I will also push the other reviewers to take a look before committing.
Jan 15 2016
Accepted on behalf of core@
Jan 14 2016
This is