I'm actually leaning towards macsec now. I'm at 6TB transferred in a double hop, no macsec over the bridge setup without triggering the fault. I'm going to let it continue to churn and setup a second testbed that JUST uses macsec without traffic control bridging to see if I can trip the issue there. That should determine if it's macsec itself, or an interaction between macsec and traffic control.
Joshua Coombs GWI office 207-494-2140 www.gwi.net On Wed, Oct 10, 2018 at 12:39 PM Cong Wang <xiyou.wangc...@gmail.com> wrote: > > On Wed, Oct 10, 2018 at 8:54 AM Josh Coombs <jcoo...@staff.gwi.net> wrote: > > > > 2.3 billion 1 byte packets failed to re-create the bug. To try and > > simplify the setup I removed macsec from the equation, using a single > > host in the middle as the bridge. Interestingly, rather than 1.3Gbits > > a second in both directions, it ran around 8Mbits a second. Switching > > the filter from u32 to matchall didn't change the performance. Going > > back to the four machine test bed, again removing macsec and just > > bridging through radically decreased the throughput to around 8Mbits. > > Flip on macsec for the bridge and 1.3Gbits? > > This is a great narrow down! We can rule out macsec for guilty. > > Can you share a minimum reproducer for this problem? If so I can take > a look.
