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
| ||
|
Message-Id: <20101027005143.bfa8fbfd.billfink@mindspring.com> Date: Wed, 27 Oct 2010 00:51:43 -0400 From: Bill Fink <billfink@...dspring.com> To: Jarek Poplawski <jarkao2@...il.com> Cc: Eric Dumazet <eric.dumazet@...il.com>, Rick Jones <rick.jones2@...com>, Steven Brudenell <steven.brudenell@...il.com>, netdev@...r.kernel.org Subject: Re: tbf/htb qdisc limitations On Wed, 20 Oct 2010, Jarek Poplawski wrote: > On Tue, Oct 19, 2010 at 03:37:24AM -0400, Bill Fink wrote: > > On Sun, 17 Oct 2010, Jarek Poplawski wrote: > > > > > On Sat, Oct 16, 2010 at 09:24:34PM -0400, Bill Fink wrote: > > > > On Sat, 16 Oct 2010, Jarek Poplawski wrote: > > > ... > > > > > http://code.google.com/p/pspacer/wiki/HTBon10GbE > > > > > > > > > > If it doesn't help reconsider hfsc. > > > > > > > > Thanks for the link. From his results, it appears you can > > > > get better accuracy by keeping TSO/GSO enabled and upping > > > > the tc mtu parameter to 64000. I will have to try that out. > > > > > > Sure, but you have to remember that scheduler doesn't know real packet > > > sizes and rate tables are less accurate especially for smaller packets, > > > so it depends on conditions. > > > > On my testing on the real data path, TSO/GSO enabled did seem > > to give more accurate results for a single stream. But when > > I tried multiple 10-GigE paths simultaneously, each with a > > single stream across it, non-TSO/GSO seemed to fare better > > overall. > > Btw, if you find time I would be interested in checking an opposite > concept of lower than real mtu (256) to use rate tables different way > (other tbf parameters without change). The patch below is needed for > this to work. Sorry. I'm totally swamped at work currently and won't be able to investigate that. -Bill > diff --git a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c > index 641a30d..9ac3460 100644 > --- a/net/sched/sch_tbf.c > +++ b/net/sched/sch_tbf.c > @@ -123,9 +123,6 @@ static int tbf_enqueue(struct sk_buff *skb, struct Qdisc* sch) > struct tbf_sched_data *q = qdisc_priv(sch); > int ret; > > - if (qdisc_pkt_len(skb) > q->max_size) > - return qdisc_reshape_fail(skb, sch); > - > ret = qdisc_enqueue(skb, q->qdisc); > if (ret != NET_XMIT_SUCCESS) { > if (net_xmit_drop_count(ret)) -- 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