@skozlov feel free to take maintainership of net/intel-em-kmod and thanks for working on these modules! :)

"if:0" and "(if:0)" have separate implementations. the one for "if:0" is missing, see ifa_lookup() in sbin/pfctl/pfctl_parser.c

Looks good, thanks!

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

Any news on this? :)

Seeing this after migration...

this one is stable, thank you @ale

No, I'm not asking for support that would take a few weeks of ping pong in a bug tracker, if any. This is real world feedback for this review. Take it or leave it. :)

Thanks, but we've narrowed it down to this commit.

We do seem to have a persistent problem with this patch in some PPPoE environments that will cause a crash in ng_pppoe_rcvdata_ether():

Nevermind, now it displays correctly. Please commit. :)

can you rebase this patch? it looks off with the update to 3.2.2 and no OPTIONS_DEFINE like it was already applied

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220025
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220026

So FWIW I stand by the approval of the previous version that does not use REDIS_CONFIGURE_ENABLE.

looks good, will accept after typo fix :)

• correctly build against GENERIC

I've updated the TUNNELBLICK patch to work with 2.4, it was just a clash with the new code formatting. Looks good so far, runtime test is pending.

• omit empty reads for ip[6]_get_fwdtag
• error out safely on failure

• use else if

• complete conversion

• requested changes

I've answered in the mail thread, but asking here specifically again: why not make it even simpler?

Closing for a fresh start on this with a KBI suggested by @ae

I'm not doubting these changes, I just saw that enabling hyperscan for suricata is problematic for non SSE3 archs and there's no way around this :/

From what we can tell, especially the "illegal instruction trouble" (see below), we need a suricata-hs package that adds hyperscan without tainting the original package and make the new one amd64 only.

Still looking for actionable advice. Thanks in advance.

Where are we on this? Within the scope of this specific code up for review: what else should be done?

There's two things here:

@eri This is *not* about dummynet at all. This patch doesn't even cover anything other than making PACKET_TAG_IPFORWARD usable from a non-ipfw perspective, one could also call it "universally reusable".

Almost, because ip[6]_output also skips the pending pfil hooks in the direction :/

Maybe to elaborate just a bit more:

I'm not sure I understand.

I've only adhered to the Phabricator wiki guideline "Please make sure that your changeset does one thing (and one thing only) so that the review process goes smoothly. Small and self-contained changes are much easier to review!".

@eri Asking for feedback.

@eri I'm kindly requesting the required input :)

@eri which change are you requesting?

• pf: keep fastroute compat stubs, don't break ABI

Ok, I'll open a bug report for the MFC.

I just hit this and noticed it was never MFC'd. Can this be pushed to STABLE?

Thanks! Are there any plans to MFC this to stable/10 as well?

It's highly likely that LLE_EXCLUSIVE is always set since la_preempt is being modified. The other code branch of arpresolve() calling arprequest() is modifying/unlocking la in the same way. Cheers for tracking this down.