Please align the constants in the header file
Fri, Apr 20
Update the maxentries sysctl once the hashtable has been init in order to reflect the actual size used.
Fri, Apr 13
Thu, Apr 12
Can you provide some numbers what benefits you have with this patch?
Wed, Apr 11
Well, as I said, I have no views on what the value should be. I defaulted to keeping the old value, but if you've got a good reason to change it that's fine by me.
Tue, Apr 10
AFAIU, the patch has been neither finished nor submitted to master.
The last activity was more than a year ago, so should it be considered as abandoned?
Are there any plans to add the feature into the kernel?
Fri, Apr 6
Split in to many separate reviews.
Thu, Apr 5
OK from manpages. Bump the .Dd when you do the actual commit (once network has approved, too). Thanks for working on this!
Wed, Apr 4
Mar 23 2018
Mar 21 2018
Looks good to me.
Mar 20 2018
I've made it work with additional changes, but don't have a workload + hardware combo that benefits from the reduction in cache misses.
Mar 19 2018
Keep the old hooks so other pfil users don't need to change. Allow pf to use the new style of hook, with the flags argument.
Mar 14 2018
Mar 3 2018
I have no specific views on what the value should be. The remark mostly comes from the desire to avoid having the kernel enforce policy. It's only a small extra step here for more flexibility.
I think I'd make net.inet.carp.dscp be an integer, with a default value of (the value of) IPTOS_LOWDELAY.
Mar 2 2018
Would it make sense to set the DSCP value to the value configured in 'net.inet.carp.dscp' rather than a hardcoded value?
Feb 27 2018
Fixed default setting of new sysctl in man page.
Jan 31 2018
Now I'm confused. This isn't about loop detection. This is about detecting if a PFIL_OUT packet is being forwarded or output.
Jan 30 2018
I'm against the last proposal. It is not costless to tag each forwarded packet and then remove the tag. This will seriously hit the performance.
Jan 29 2018
(Apologies; last comment on this matter)
I guess the "cost should be relatively low" comment is kind of wrong. OUT hooks that care about whether it's forwarded or not will take a hit if it's not forwarded and the tag is not present, but I have no idea how heavy this would be- I have no notion of how heavily used mbuf tags are. =)
Jan 27 2018
I'm not sure I see how this would create confusion. This merely presents more information about the packet, and where the netpfil hook being called from.
While i have not much time lately to spend on this, i still think this is the wrong way of doing things since it just creates confusion.
pf(4) has already knows about mbuf_tag(9) and uses it. I would strongly suggest using them until a proper _FWD hook comes to life and allows removing all the 'hacks' in pf(4) and possibly elsewhere.
Jan 26 2018
Having had time to review it again, I think it looks good. This iteration exposes it as a flag to describes the path the packet's taken, rather than exposing it as the direction the packet is going in and having places where it was necessary to then mask that fact by flipping dir back to OUT where paths didn't yet know about FWD
Sorry, removal of manpages was unintentional- caches, grrrr.
Based around a suggestion from Kyle Evans (who also did all of the work), introduce a flags variable to the pfil callbacks. Keep using PFIL_OUT for forwarded packets, but set the PFIL_FWD flag for them. This allows pf to work out if a packet is being forwarded or not, with essentially no changes to other netpfil consumers.
Jan 6 2018
More context. No changes to the diff.
While this is needed i do not agree that the modifications on the stack and packet filters should be so hackish.
Can you please update the patch with additional context according to https://wiki.freebsd.org/Phabricator#Create_a_Revision_via_Web_Interface