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
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
