netdev - Re: [RFC PATCH net-next] qfq: handle the case that front slot is empty

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1351239007.6537.291.camel@edumazet-glaptop>
Date:	Fri, 26 Oct 2012 10:10:07 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Paolo Valente <paolo.valente@...more.it>
Cc:	Cong Wang <amwang@...hat.com>, netdev@...r.kernel.org,
	Stephen Hemminger <shemminger@...tta.com>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [RFC PATCH net-next] qfq: handle the case that front slot is
 empty

On Fri, 2012-10-26 at 09:51 +0200, Paolo Valente wrote:

> I think I will ask for your help soon, thanks.
> 
> The cause of the failure is TCP segment offloading, which lets qfq
> receive packets with a much larger size than the MTU of the device.
> In this respect, under qfq the default max packet size lmax for each
> class (2KB) is only slightly higher than the MTU. Violating the lmax
> constraint causes the corruption of the data structure that implements
> the bucket lists of the groups. In fact, the failure that you found is
> only one of the consequences of this corruption. I am sorry I did not
> discover it before, but, foolishly, I have run only UDP tests.
> 
> I am thinking about the best ways for addressing this issue.
> 
> BTW, I think that the behavior of all the other schedulers should be
> checked as well. For example, with segment offloading, drr must
> increment the deficit of a class for at most (64K/quantum) times,
> i.e., rounds, before it can serve the next packet of the class. The
> number of instructions per packet dequeue becomes therefore
> (64K/quantum) times higher than without segment offloading.
> 

OK, good to know you found the problem.

Normally, TSO is supported by other qdisc, maybe not optimally but
supported.

For example, one known problem with TSO is that skb->len is a
underestimation of real number of bytes sent on wire

If MSS is a bit small, TBF/HTB/CBQ can really overdrive links.

We probably should have a more precise estimation.


--
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