iflib-if_em tests with HEAD and lagg panic [Was: Re: svn commit: r333338 - in stable/11/sys: dev/bnxt kern net sys]

[Harry Schmalzbauer]

Am 11.05.2018 um 19:24 schrieb Harry Schmalzbauer:
> Bezüglich Stephen Hurd's Nachricht vom 10.05.2018 21:55 (localtime):
>> Ok, the review is updated with the EBR.  If you can update your tree to
>> r333466 or newer, apply the patch and retest, that would be great.  It
>> seems to be working here.
> I took out the sys/net/if.c, sys/net/if_var.h and sys/conf/kmod.mk
> hunks, since these were commited in r333469.
>
> Happy to confirm that there are no more LORs occuring when
> creating/using if_lagg(4), neither with the hartwell/clarkville sisters,
> nor with kawela twins.
> Tested with r333486 and latest https://reviews.freebsd.org/D15355 as of
> this writing.
> Brief balancing/failover tests also inidcate excellent condition for
> those 3 iflib-NICs.
> Only did very simple workloads (with IPv6 NFSv4), but so far nothing
> uncommon in any area.
> Also, I cannot reproduce the link status failure when removing the TP
> connection of the i217 NIC (will update the separate thread).

I'd like to report additional nits with i217:

While trying to track down strange symptoms (IPSec transport mode seems 
broken, virtualbox bridge might possibly also be broken), I saw that 
disabling some offload features doesn't work.
ifconfig(8) doesn't report a failure, but I can't disable VLAN_HWCSUM 
and disablying rxcsum6 enables rxcsum4, while disabling rxcsum 
re-enables rxcsum6.

Is it possible at all that iflib affects IPsec transport mode?

Thanks,

-harry