netdev - Re: tc drop stats different between bond and slave interfaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <1432657755.4060.268.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Tue, 26 May 2015 09:29:15 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	"jsullivan@...nsourcedevel.com" <jsullivan@...nsourcedevel.com>
Cc:	netdev@...r.kernel.org
Subject: Re: tc drop stats different between bond and slave interfaces

On Tue, 2015-05-26 at 03:41 -0400, jsullivan@...nsourcedevel.com wrote:
> 

> Hi, Eric.  All the traffic flowing through a single class is because
> of the testing we are doing.  It all falls into the bulk class and we
> are not generating any other traffic.  The remote side utilizes some
> of the other classes because of the ACK and ESP packets.
>  
> We do want to control shaping closely so I suppose we should place it
> on the bond.  We are using HFSC.  In doing that, are we creating a
> problem that we have left the default qdiscs on the physical
> interfaces? We could redirect those into the IFB interface like we do
> the bond interface but then wouldn't we shape twice? Should we put
> fq_codel on there like we put on the end of the IFB interface? Thanks 

Please do not send HTML messages to the list. netdev does not allow
this.

Leaving default qdisc on the slave is fine. It allows proper buffering
of bursts.

I see no gain using fq_codel twice in the path. It really matters where
the bottleneck is.




--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html