[ten64 branch] Dataflow stops with multiple port traffic #17
Labels
bug
Something isn't working
Comments
|
@mcbridematt Same as #8 (comment) |
|
Excellent! I've tested with four ports active (GENERIC-NODEBUG) and it has gone 24 hours without issues. I'll move my 'production' FreeBSD machine to this version and see how it goes. |
I hope I'll still have a chance to commit those changes till 14.0. Thanks for testing and help! |
dsalychev
pushed a commit
that referenced
this issue
Sep 9, 2023
netlink(4) calls back into the driver during detach and it attempts to start an internal synchronized op recursively, causing an interruptible hang. Fix it by failing the ioctl if the VI has been marked as DOOMED by cxgbe_detach. Here's the stack for the hang for reference. #6 begin_synchronized_op #7 cxgbe_media_status #8 ifmedia_ioctl #9 cxgbe_ioctl #10 if_ioctl #11 get_operstate_ether #12 get_operstate #13 dump_iface #14 rtnl_handle_ifevent #15 rtnl_handle_ifnet_event #16 rt_ifmsg #17 if_unroute #18 if_down #19 if_detach_internal #20 if_detach #21 ether_ifdetach #22 cxgbe_vi_detach #23 cxgbe_detach #24 DEVICE_DETACH MFC after: 3 days Sponsored by: Chelsio Communications
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Commit: 5f6b8b3
In my test suite, I run iperf3 through the FreeBSD host functioning as a router
For example:
iperf3 server <-> dpniX (FreeBSD) dpniX+1 <-> iperf3 client
The test system is another Ten64 running Linux which runs each iperf3 instance in a container with one of the ethX ports transferred into it.
So dpni0 on FreeBSD -> eth0 on test system, dpni1<->eth1, dpni2<->eth2 etc.
(I'll publish the scripts another time, they need a bit of cleanup)
dpni6 is the interface to my LAN for management
Server 1 is attached to dpni0 on 192.168.13.2
Client 1 is on dpni2, gets an IP via DHCP and initiates an
iperf3 -R -c 192.168.13.2Server 2 on 192.168.15.2, Client 2 on 192.168.16.X so on.
For this initial test, I will run just one flow.
On this branch, the dataflow completely stops almost immediately:
In this case, dpni1 won't receive any traffic to the iperf3 server (192.168.13.2), but will receive other frames:
vmstat:
I do a few more vmstats:
its0,140: dpaa2_io0counter has not changed, is it stuck?dpaa2 niX counters:
The text was updated successfully, but these errors were encountered: