From: Patrick McHardy <kaber@trash.net>
To: Russell Stuart <russell@stuart.id.au>
Cc: hadi@cyberus.ca, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Stephen Hemminger <shemminger@osdl.org>,
netdev@vger.kernel.org, Jesper Dangaard Brouer <hawk@diku.dk>
Subject: Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
Date: Fri, 07 Jul 2006 10:00:23 +0200 [thread overview]
Message-ID: <44AE1497.6010904@trash.net> (raw)
In-Reply-To: <1152146376.4215.59.camel@ras.pc.brisbane.lube>
Russell Stuart wrote:
> Unfortunately you do things in the wrong order for ATM.
> See: http://mailman.ds9a.nl/pipermail/lartc/2006q1/018314.html
> for an overview of the problem, and then the attached email for
> a detailed description of how the current patch addresses it.
> It is a trivial fix.
Actually that was the part I didn't understand, you keep talking
(also in that comment in tc_core.c) about an "unknown overhead".
What is that and why would it be unknown? The mail you attached
is quite long, is there an simple example that shows what you
mean?
> As I said earlier, RTAB and STAB contain the same numbers,
> just scaled differently. The ATM patch stuffed around with
> RTAB. With your patch in place it will have to do the same
> exactly the same thing with STAB - because RTAB and STAB
> carry the same data. So to me the two patches seem
> orthogonal.
Yes. As I said in the beginning of this thread, we could still
do the RTAB thing for qdiscs that support it. But since the
visible size should be the same for all qdiscs (including child
ones) we need to do the initial calculation anyway, so I don't
see any purpose in still adjusting the rate tables and using
skb->len instead of using the adjusted size.
> One observation is the size optimisation you applied to STAB,
> making it variable length, could also be applied to RTAB.
> In fact it should be. Then they would be identical, apart
> from the scaling. Even the lookup operation (performed in
> qdisc_init_len in your patch) would be identical.
We can do that. I'm not attached to the size tables :)
> However, now you lot have made me go away and think, I have
> another idea on how to attack this. Perhaps it will be
> more palatable to you. It would replace RTAB and STAB with
> a 28 byte structure for most protocol stacks - well all I can
> think of off the top of my head, anyway. RTAB would have to
> remain for backwards compatibility, of course.
Can you describe in more detail?
next prev parent reply other threads:[~2006-07-07 8:00 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-14 9:40 [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL Jesper Dangaard Brouer
2006-06-14 12:06 ` jamal
2006-06-14 12:55 ` Jesper Dangaard Brouer
2006-06-15 12:57 ` jamal
2006-06-15 13:16 ` jamal
2006-06-20 1:04 ` Patrick McHardy
2006-06-20 14:59 ` jamal
2006-06-20 15:16 ` Patrick McHardy
2006-06-21 12:21 ` Krzysztof Matusik
2006-06-21 12:54 ` Patrick McHardy
2006-06-21 14:33 ` Krzysztof Matusik
2006-06-14 15:32 ` Andy Furniss
2006-06-20 0:54 ` Patrick McHardy
2006-06-20 14:56 ` jamal
2006-06-20 15:09 ` Patrick McHardy
2006-06-22 18:41 ` jamal
2006-06-23 14:32 ` Patrick McHardy
2006-06-24 14:39 ` jamal
2006-06-26 11:21 ` Patrick McHardy
2006-06-27 13:01 ` jamal
2006-07-02 4:23 ` Patrick McHardy
2006-07-02 13:59 ` jamal
[not found] ` <1150287983.3246.27.camel@ras.pc.brisbane.lube>
[not found] ` <1150292693.5197.1.camel@jzny2>
[not found] ` <1150843471.17455.2.camel@ras.pc.brisbane.lube>
[not found] ` <15653CE98281AD4FBD7F70BCEE3666E53CD54A@comxexch01.comx.local>
[not found] ` <1151000966.5392.34.camel@jzny2>
2006-06-23 12:37 ` Russell Stuart
2006-06-23 15:21 ` Patrick McHardy
2006-06-26 0:45 ` Russell Stuart
2006-06-26 11:10 ` Patrick McHardy
2006-06-27 6:19 ` Russell Stuart
2006-06-27 17:18 ` Patrick McHardy
2006-07-04 13:29 ` Patrick McHardy
2006-07-04 19:29 ` jamal
2006-07-04 23:53 ` Patrick McHardy
2006-07-06 0:39 ` Russell Stuart
2006-07-07 8:00 ` Patrick McHardy [this message]
2006-07-10 8:44 ` Russell Stuart
2006-06-24 14:13 ` jamal
2006-06-26 4:23 ` Russell Stuart
2006-07-18 2:06 ` Russell Stuart
2006-07-18 13:35 ` jamal
2006-07-18 21:46 ` Andy Furniss
2006-07-19 1:02 ` Russell Stuart
2006-07-19 14:42 ` Andy Furniss
2006-07-19 14:54 ` Patrick McHardy
2006-07-19 20:26 ` [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL (RTAB BUG) Jesper Dangaard Brouer
2006-07-19 21:00 ` Alexey Kuznetsov
2006-07-20 5:47 ` Russell Stuart
2006-07-20 23:49 ` Alexey Kuznetsov
2006-07-19 14:50 ` [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL Patrick McHardy
2006-07-20 4:56 ` Russell Stuart
2006-07-30 23:06 ` Russell Stuart
2006-08-08 22:01 ` Russell Stuart
2006-08-09 11:33 ` jamal
2006-09-04 10:37 ` Russell Stuart
2006-06-14 14:27 ` Phillip Susi
2006-06-14 15:08 ` Jesper Dangaard Brouer
2006-06-20 5:35 ` Chris Wedgwood
2006-06-20 7:33 ` Jesper Dangaard Brouer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44AE1497.6010904@trash.net \
--to=kaber@trash.net \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hadi@cyberus.ca \
--cc=hawk@diku.dk \
--cc=netdev@vger.kernel.org \
--cc=russell@stuart.id.au \
--cc=shemminger@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).