User Details
- User Since
- Jun 15 2015, 5:39 PM (362 w, 7 h)
Thu, May 12
LGTM, thanks!
Feb 28 2022
update as mentioned
created new review instead of update
Feb 21 2022
Feb 14 2022
thanks a lot :)
Jan 31 2022
We have multiple reports that this causes throughput regressions when in use on 13-STABLE as opposed to 13.0-RELEASE where it is not present. We have had this commit reverted and speeds are back to normal for our OPNsense users. For more info see https://forum.opnsense.org/index.php?topic=26364.0
Jan 27 2022
fqpie_callout_cleanup() should exhibit the same issue
Jan 4 2022
Dec 14 2021
I was thinking the same at first but the locking introduced in https://cgit.freebsd.org/src/commit/sys/netpfil/ipfw/dn_aqm_pie.c?id=12be18c7d594 looks arbitrary and isn't anywhere else in those two files. It was added to "protect" the ref_count manipulation, but if you look at the other ref_count modification in that file these are also done without (obvious) locks.
Dec 10 2021
Nov 18 2021
Just as a comment: With all these ties to RSS defines I'm not sure where that leaves the RSS feature with regard to its multiple hardware/software use cases but there's no point in blocking this with no visible consumers. I'll make sure to give this a test once it hits main.
Oct 28 2021
Sep 27 2021
Thanks for the find! Looks reasonable to bring in. I will try to get more test coverage from our users, though feedback was low on this particular hang ;(
Sep 15 2021
Added motivation for checking for untagged priority to the filter program comments.
add comment about need to test for VID 0 presence
Sep 14 2021
Not sure about omitting the match on a NAT rule, but doing it inside the log code was definitely wrong.
void REASON_SET by directly passing PFRES_MATCH
Sep 8 2021
But to be fair both rules are matching accounting-wise unless we assume that only "pass" can account for "match".
Sep 2 2021
There is an older discussion about it here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224961
Aug 19 2021
- skip to end on vlanid != 0 and add comments
Aug 18 2021
Correct. Here is the test:
- lease declaration skip fixes
Use EVL_VLID_MASK as suggested
OpenBSD added the single htons() while adding write filter, but nowhere else. I suspect the fragmentation check is mostly correct so this doesn't matter in the real world.
constify filters and avoid static length variables
Appreciate the reviews :) Unfortunately I'm not a committer so is someone willing to help out? Thanks in advance.
Aug 17 2021
fixed partial length on tx
Another one refactored
Aug 16 2021
Aug 14 2021
That would be great, thanks!
Aug 13 2021
The only other script is the DNS script and it looks like -u already does append the sender address to that script's data.
now avoids raw access to ntopbuf from scripts call
Aug 12 2021
Merged into https://reviews.freebsd.org/D31501
Much nicer, thanks! Added Stephan as reviewer who originally worked on this to give it a go.
Aug 11 2021
Apr 23 2021
On second thought: maybe I'm mixing up hardware. I'm not sure, but in either case 12.x does seem not exhibit this issue judging from the complete lack of user reports.
@kbowling for us https://cgit.freebsd.org/src/commit/?id=0aa7d3ff9ea resolved the issue back then and has not come back. Is this meant to replace it or to be applied on top? I can test it on the specific hardware, but unsure if this will be inconclusive for the mentioned reason
Sep 10 2020
Thanks for the update :)
Oct 24 2018
Oct 22 2018
@skozlov feel free to take maintainership of net/intel-em-kmod and thanks for working on these modules! :)
Oct 21 2018
"if:0" and "(if:0)" have separate implementations. the one for "if:0" is missing, see ifa_lookup() in sbin/pfctl/pfctl_parser.c
Oct 12 2018
Oct 7 2018
Looks good, thanks!
Jul 23 2018
We all invest time so thank you for the offer. Yes, I am OK with that.
I do not wish to acknowledge the advertising in the commit message.
I'm sorry, I'm playing by the rules that FreeBSD imposes on its external contributors.
There's a PR here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229904
Feb 13 2018
Any news on this? :)
Jan 31 2018
Seeing this after migration...
Aug 29 2017
this one is stable, thank you @ale