| 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
| ||
|
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
Powered by blists - more mailing lists