I have no objection against this. Just one test case to test - create several EBR partitions (e.g. s5, s6, s7), then remove one from the middle (i.e. s6), then create two smaller in this free space (and then optionally reboot, and see what we will have after reboot).
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 26 2020
May 25 2020
May 22 2020
May 20 2020
I'll try to test this and commit with small modifications after weekend. Thanks!
May 14 2020
May 6 2020
It seems rt_pktsent is already unused in head/, thus its removal is reasonable. According to your calculations for offsets, this change can give some performance boost, and I'll try to measure it in the lab, but I'm not sure this will happen very soon. Also maybe is it worth to add some explicit alignment requirements to rtentry structure or some of its fields? We can use __aligned(CACHE_LINE_SIZE)
I also agree that these messages should be removed. But moving them to nd6 debugging seems wrong.
JFYI, this code will be removed when refactoring to the epoch(9) will be finished.
Apr 23 2020
Do you have performance test results for already existing linux implementation?
From a quick look it seems to me there will be bottleneck regarding locking that seems can be reduced using CK and epoch. But this task can be done in future, if you plan support this code.
Apr 16 2020
Apr 14 2020
Apr 13 2020
Apr 11 2020
In D24232#535905, @melifaro wrote:I'm going to commit it on Sunday, April 12 unless anyone has any objection.
Apr 9 2020
Apr 7 2020
Apr 6 2020
Apr 2 2020
Apr 1 2020
Mar 31 2020
Mar 26 2020
Mar 24 2020
Mar 20 2020
how did you test this change?
Feb 28 2020
Looks good to me. But I'd wait for @melifaro, there are several places where this KPI is used and I didn't check how it can affect it :)
This code, probably, was written with hope of depreciation of scope embedding into addresses.
If you plan to remove these, please leave the comment that returned address has embedded scope.
Also you will probably want to remove related XXX hack from fast forwarding code.
Feb 25 2020
It seems some of these macros should be fixed to respect style(9) and use tab instead of space after #define.
Feb 19 2020
Also, how did test your changes? :)
NAT64 currently is not widely used, thus changes here can break something and you will know about breakage when it will be not so easy to fix, e.g. after release.
In D23737#521593, @neel_neelc.org wrote:Here, I also compare the destination addresses. Is this what you want?
Feb 18 2020
The patch is not correct. IPv4 address can be embedded in different places depending from configuration.
Feb 10 2020
Feb 3 2020
Jan 23 2020
Dec 26 2019
Dec 23 2019
Dec 18 2019
I meant this thread: https://lists.freebsd.org/pipermail/freebsd-net/2019-October/054632.html
We removed this code two years ago, since it adds big penalty for routers where are tens of thousands IPv6 routes.
However, someone in the mail list recently complained that we have not a method for route expiring, probably we can rework this code to implement such feature.
Dec 17 2019
Dec 13 2019
Dec 12 2019
Dec 10 2019
Update the patch.
Dec 8 2019
Dec 6 2019
Dec 2 2019
Nov 27 2019
Nov 26 2019
Nov 22 2019
Since replay field is optional, I think you need add the check that it is not NULL.
Nov 19 2019
Nov 18 2019
I think there is no need in such comment.
LGTM.
Nov 14 2019
Nov 13 2019
The most of code that uses m_pullup() does check first, that the call is needed. Do you think that now it is considered as light enough, to do not check this?
Nov 7 2019
Nov 6 2019
Make address copying also conditional for consistency.
Add comment describing the goal of condition.
Nov 5 2019
In D22243#486266, @lutz_donnerhacke.de wrote:If copying the LL addr is happening every time a parent interface is added (bcopy) , why not schedule the update too unconditionally?
It will only happen on changing the parent interface anyway.
Oct 21 2019
Oct 18 2019
Oct 15 2019
Oct 1 2019
I'm agree with the change, but I have doubts that we have fixed all places in the kernel, where zone id is checked and properly initialized. Usually we keep zone id embedded in the address. Do you have some tests to check this code?