From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josh Coombs Subject: Re: Possible bug in traffic control? Date: Thu, 11 Oct 2018 10:05:34 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: netdev@vger.kernel.org To: xiyou.wangcong@gmail.com Return-path: Received: from mail-yb1-f176.google.com ([209.85.219.176]:41712 "EHLO mail-yb1-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727081AbeJKVdb (ORCPT ); Thu, 11 Oct 2018 17:33:31 -0400 Received: by mail-yb1-f176.google.com with SMTP id e16-v6so3639953ybk.8 for ; Thu, 11 Oct 2018 07:06:11 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: 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 wrote: > > On Wed, Oct 10, 2018 at 8:54 AM Josh Coombs 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.