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.
In D4306#121368, @mike-karels.net wrote:This change does not affect forwarding, just TCP and UDP termination. It makes the most difference when TSO is not enabled.
Mar 19 2016
This change does not affect forwarding, just TCP and UDP termination. It makes the most difference when TSO is not enabled.
In my standard forwarding scenario (2 static routes), I didn't see improvement neither regression with this patch (about -1% with pf or ipfw):
Mar 18 2016
Fix user-level include of in_pcb.h
rt_gen_t was in an ifdef _KERNEL
Argh, I see what I did. I ended up with the wrong version of route.h in /usr/include.
Mar 16 2016
I've sync my -head source to 296935, then applyed this patch without problem, but buildworld failed:
I've added Olivier as a reviewer because I'm hoping he'll test this patch and give us some updated performance numbers.
Mar 14 2016
Update to match head, fix UDP/IPv4 locking
Move definitions to match movement in header files.
Mar 9 2016
4102 has already gone in. It's time to push this in as well.
Feb 15 2016
OK, I missed the malloc/copy in if_ethersubr.c. So there isn't a problem with pointers to freed memory, but the L2 code still has the issue as the routing code with copying the pointers to/from the route structure.
Feb 9 2016
In D4490#111292, @mike-karels.net wrote:I'll respond to other parts soon. But I want to correct this:About L2 caching: this approach is very wrong. Caching a pointer and length to the L2 header allows no way to validate or invalidate the cache. What happens when the L2 entry times out and is deleted?
I invalidate all cached context. See if_llatbl.c.
This is not effective. Consider the following:
Thread A checks the routing generation number in ip_output. Thread B then increments the generation count of all the routing tables (the bigger hammer approach!)
I'll respond to other parts soon. But I want to correct this:
Feb 7 2016
In D4490#111105, @mike-karels.net wrote:About L3 caching:
I think my approach, including a "struct route" in the in_pcb, is both simpler and more correct.
I dislike building a "struct route" on the stack and then moving fields to and from that structure from the pcb. I think it is wrong to compare the route using the in_pcb destination address, as that may have changed (e.g. in the UDP case). The struct route contains the previously-looked-up destination, which is necessary.
About L3 caching:
Feb 4 2016
Could Mike point out what his patch provides that this doesn't - apart from the lookup on bound UDP? This provides L2 caching which is important.
Updated to (I hope) address all the comments and compile against the most recent HEAD. This has been used in ISLN's internal incast testing and I'm hoping to get LL and NFLX to test.
Feb 3 2016
Jan 23 2016
This revision does several things:
Dec 22 2015
Where do we want to do the review? Here or on D4490?
Dec 16 2015
Some in-line comments from a quick pass.
Dec 15 2015
Dec 14 2015
Dec 12 2015
Thanks for updating the patch!
Looks OK, several small comments inline
Dec 11 2015
Dec 8 2015
I'll upload a new patch against D4102 and then Mike can do similarly then we'll have a inpcb route caching showdown.
Randall: see also D4306 for another approach.
Dec 7 2015
I am *very* glad to see a cached route coming back in :-)
Dec 5 2015
I will review 4102 ASAP.
restore 40 line context
convert tcp_timer_activate to sbintime
Dec 4 2015
Meant D4102 in last comment
The only thing that stops projects/routing work from landing is D4102 which conflicts with this particular patch.
I do not believe that this, or Matt's, change should make doing the right thing with the routing system any more difficult than it already is. I think it's time we pushed either this change or the associated change into the tree. The other routing work is longer term.
Dec 3 2015
Dec 1 2015
In D4295#90577, @kmacy wrote:In D4295#90451, @hiren wrote:@kmacy I don't think iflib is part of -head yet. I see this patch includes references to sys/net/iflib* which also don't exist in -head yet. Can this patch be applied cleanly to -head? if not, I'd be great to have that done.
It's not part of HEAD yet. The objective here is to elucidate the mechanism. I haven't been able to test it under real load yet. Do you really want to run with scissors? :D
I'm adding a "looks good to me" here for the Intel Reviewers as this adds functionality in the stack and the modification to the driver is required.
Nov 30 2015
The changes look good. I'd split them in multiple patches/commit, more or less following the structure you outlined in the summary, but thanks for sending out a single one so we can have the whole picture.
IIRC there were objections to change ticks from 32-bits to 64-bits so you may want to ask feedback from a more general audience.
Other than that, I'm fine with (a splitted version of this) getting in.
Nov 28 2015
In D4295#90451, @hiren wrote:@kmacy I don't think iflib is part of -head yet. I see this patch includes references to sys/net/iflib* which also don't exist in -head yet. Can this patch be applied cleanly to -head? if not, I'd be great to have that done.
Nov 27 2015
@kmacy I don't think iflib is part of -head yet. I see this patch includes references to sys/net/iflib* which also don't exist in -head yet. Can this patch be applied cleanly to -head? if not, I'd be great to have that done.
A couple of comments in-line after a very quick glance. I'll try to take a better look next week.