In D53089#1248199, @kgalazka wrote:

In D53089#1244212, @gallatin wrote:

In D53089#1244032, @adrian wrote:

what are you seeing? I remember ixl RSS being buggy!

A valid rss type set with a 0 flowid for connections nginx accepts. Not sure why ixl can't calculate a proper hash in that case, but it can be worked around by checking to see if the flowid (rss hash result) is valid.

See https://reviews.freebsd.org/D54442

Thanks a lot for the fix! Did you see that issue on X710 or X722 interface? As far as I understand X722 HW supports more PCTYPEs. They were enabled by default when RSS was undefined, but it looks that they are not covered when rss_gethashconfig is used.

Bravo. Anything we can do to make iflib simpler is a good thing in my book!

• use atomic_store rather than atomic_set, as per @markj 's feedback
• update man page date

• Updated to document tx_defer_mfree separately

• rebased diff
• added documentation for tx_defer_mfree sysctl

In D54356#1246570, @ziaee wrote:

Note that deferred mbuf freeing is not enabled by default, and can be

enabled using the dev.$DEV.$UNIT.iflib.tx_defer_mfree sysctl.

Can you put tx_defer_mfree in iflib(4) in this commit?

In D53089#1244032, @adrian wrote:

what are you seeing? I remember ixl RSS being buggy!

In D53089#1242869, @zarychtam_plan-b.pwste.edu.pl wrote:

Is it safe for MFC to stable/15 ? I see no plans for the MFC, I see that cherry-picking works fine, but there are clearly no plans for MFC in the commit message.

In D54356#1242220, @glebius wrote:

Have you tried chaining mbufs instead of having an array? Does that have negative cache effect?

I've only been able to test this on amd64, and I'm pretty bad at atomic acq/rel semantics. If somebody could review that, I'd appreciate it.

In D54275#1240636, @jhb wrote:

Maybe to make it clearer we can change the struct to use a union of next_seqno and initial_seqno which won't change the ABI but will let us document it in the header and be more clear about the intent?

added union for next_seqno / initial offload seqno to provide a better description & preserve ABI, as suggested by @jhb

• realized that so_unsplice can be called with an so2 that's already been recycled when its called via so_splice(), since we don't hold a reference. So ensure we null out sp_dest and deal with a NULL so2 in so_unsplice

Remove changes to the so_unsplice() path on SPLICE_INIT splices.. @markj correctly pointed out that codepath is not a problem.

In D54053#1235030, @glebius wrote:

My understanding. First, qsort() itself never passes NULL pointer. Second, could a map[] entry within p->pm_count be NULL or not? The new code assumes it can't be. Then we also have a case with lacp_port that has NULL lp_ifp, which is covered.

Remove more defensive debug code

update based on Gleb's feedback