Having applied this to HEAD I find that with the following test:

I'll give this a benchmark in the Sentex lab.

Updates to get all the return values out.

Address comments from bz@

Update m_getcl provider to also pass the flags.

Add the mbuf.d translation file.

Add translators.

I've added Olivier as a reviewer because I'm hoping he'll test this patch and give us some updated performance numbers.

Do it.

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.

4102 has already gone in. It's time to push this in as well.

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.

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:

Thanks.

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.

Thank you.

We are programming in C and not assembler. Please make the requested change to a typically C idiom.

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.

Approved.

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?

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.

Has this been updated based on all the recent rototilling?

I'm down with this but I will also push the other reviewers to take a look before committing.

Accepted on behalf of core@

This is