netdev - Re: [PATCH] sch_htb: ix the deficit overflows

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

Message-ID: <4B164A80.2000709@cdi.cz>
Date:	Wed, 02 Dec 2009 12:07:44 +0100
From:	Martin Devera <martin.devera@....cz>
To:	Jarek Poplawski <jarkao2@...il.com>
CC:	David Miller <davem@...emloft.net>, xiaosuo@...il.com,
	hadi@...erus.ca, netdev@...r.kernel.org
Subject: Re: [PATCH] sch_htb: ix the deficit overflows

Jarek Poplawski wrote:
>>
>> Because we toss large SKBs all over the strack quite freely,
>> protections like those suggested by Changli make perfect sense.
>>
>> We really don't have an MTU for packets within our stack any more.
>> The code, by default, need to be able to handle anything.
> 
> Alas, an MTU is still a crucial parameter for some schedulers. Anyway,
> I hope Changli wasn't mislead to treat my private opinions in this or
> any other thread as decisive. Otherwise, I'm sorry.

It seems that the new code is not slower when quantums are larger
than MTU's. Only when it is not the case, the new code introduces
loop which will iteratively increase deficit[x] until some packet
fits.
This can slow dequeue down. I'm not sure how much - but imagine
working setup with small quantums which works just now (only
sharing ratios are wrong).
After installing new kernel with the change the load could go
up and router could start  dropping packets.

While I don't believe the load will change so much, Changli
should measure this one IMHO.

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