- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 10 2016
Jan 9 2016
Jan 8 2016
Jan 7 2016
Do pre-commit sync: fix NOINET case.
In D4605#102190, @hselasky wrote:Ping - any reviewers active on this one?
sorry, will take a look today.
Jan 5 2016
In D4794#101759, @bz wrote:People had been asking for this for IPv4 and I did the patch but never committed it as the penalty was noticeable. We should not lose these features in favour of simplicity but make them perform well when designing things. Having had per-address counters has been very valuable in the last years for IPv6 to debug and account various things.
I've updated the patch.
IPv6 accounting for most common case (non-fragmented packets) should be slightly better (no ifa ref/unref cost). It is still costy, however, due to IF_ADDR_RLOCK() which is rwlock.
Sending frags is also accounted the same way which may degrade performance for that path.
Update IPv6 part (add precise accounting using newly-added in6_accountoifa()) per bz@ comments.
In D4794#101759, @bz wrote:This is a straight reject to the idea from my view. Sorry.
People had been asking for this for IPv4 and I did the patch but never committed it as the penalty was noticeable. We should not lose these features in favour of simplicity but make them perform well when designing things. Having had per-address counters has been very valuable in the last years for IPv6 to debug and account various things. And sorry, using a firewall is not a solution.
I thought it won't be easy but I had to start with something :)
Okay. So for IPv6 situation is not that complicated:
function like inc_ia6_countrers(ifp, addr, opackets, obytes) which internally finds appropriate ifa under ifaddr lock and increments pcpu counters under that lock, w/o the need to do heavy refcounting. It would both improve the performance and increase accuracy.
Jan 4 2016
Jan 3 2016
Jan 1 2016
Dec 31 2015
Do pre-commit sync.
Dec 28 2015
Sorry, I totally missed the point that I have to commit it myself :)
Dec 23 2015
Update once again to clarify arp_fillheader() behavior.
Finally fix ip_arpintr() reply error handling.
Address glebius@ comments and sync to recent HEAD.
Dec 21 2015
Mark, big thanks for adding QSFP28 stuff.
Looks OK to me (minor comment below).
Dec 17 2015
Dec 16 2015
Dec 14 2015
Dec 13 2015
In D4102#95769, @mike-karels.net wrote:I haven't reviewed this as closely as I should. However, if I read this correctly, this is a new caching mechanism that:
- is not currently used for caching
Mike,
Thanks for the comments.
I probably should have written more detailed summary. Let me try to rephrase it.
Update patch to reflect recent netinet6/ lltable changes.
Dec 12 2015
Thanks for updating the patch!
Looks OK, several small comments inline
Update diff to exclude infiniband part and address comments.
Dec 11 2015
According to the summary, it looks ok. Ensuring entire inet6/ code would work in all similar cases require (probably much) more work :)
Dec 9 2015
Dec 8 2015
Dec 6 2015
Thanks for reviewing that one.
Dec 5 2015
Update to sync with recent changes.
Remove sbin/ifconfig debug.
Do pre-commit sync.
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.
2 kmacy:
Yes, avoiding route lookup is of course faster. The question is "how much benefit can we get from avoiding it and is is worth doing".
Also, I'm not against caching at all, I'm against the proposed caching implementation.
2 gnn:
projects/routing is not about "improve forwarding" , it is about improving any rtable/lltable lookup, regardless if is TCP or raw ip or forwarding. This change is about optimising TCP-only workloads while keeping other things slow and making it harder to change this in general.
2 mike-carels.
What I'm saying is that " take full advantage of what's there now," actually means "make things harder for those who want to fix routing".
For routing stuff you need to hide llentries/rtes and you changes exposes them back.
Passing 'struct rtentry' is not used in hot path, there are no ro_lle consumers other that af_inet flowtable for ethernet.
The last bit of change needed to start projects/routing merge to HEAD is in D4102 and is exactly about eliminating ro_lle .
Dec 3 2015
Okay, let me be a bit more specific. I'm against taking some internal structures from code doing lookups/prepends, lock them somehow and pretend that it is "caching". Caching in general might not that bad but I'd like to see the difference between lookups and cached approach. I did some tests a year ago on how actually radix slows things. I customised lookup function to always return the same route and I didn't see any significant increase on projects/routing branch (which probably means that we have other more significant problems like NUMA or batching mbufs or ..). Also note that it will be possible to change actual lookup to something different than radix (say, array/hash optimised for typical "1 interface, 1 [default] route" case).
Also, theoretically you can cache/reference nexthop structure returned by one of fib_* lookup functions, but again, I'm not sure it is worth the efforts.
Dec 2 2015
There are other things depending on that change. However, I don't really need IB changes at this stage - converting any specific networking technology is purely optional. Since I proposed sort of generic API that should suit for all cases, it would be strange to convert only ethernet - that's why I needed some other part.
So, if code updating is supposed to take more than several weeks, I will just split this review into ethernet part and IB part.
Nov 30 2015
Nov 29 2015
I believe that this is wrong way of doing things.
Nov 26 2015
Hans, any progress on testing infiniband? :)