From: Michal Soltys <soltys@ziu.info>
To: Linux Netdev List <netdev@vger.kernel.org>
Subject: Question - size tables implementation
Date: Thu, 04 Dec 2008 14:55:38 +0100 [thread overview]
Message-ID: <4937E15A.9090909@ziu.info> (raw)
In-Reply-To: <492F2A9B.2050903@ziu.info>
Hi
This is a followup question, continuing from:
http://marc.info/?l=linux-netdev&m=122782976032316&w=2
Well, at least this is what I'm seeing from looking at the code. Perhaps
I missed something.
Assuming I didn't - an example of a flow in a simple example (let's say
- hypothetical "outer" as a root qdisc, and "inner" as a leaf qdisc -
both using different size tables):
1) qdisc_enqueue_root() will set pkt_len in cb area to skb->len, call
qdisc_enqueue(), then
2) qdisc_calculate_pkt_len() will set pkt_len in cb area using "outer"'s
size table, and
3) outer_enqueue() will be will be called. This one will classify the
packet and
4) qdisc_enqueue() it to the "inner" qdisc, but that function will
qdisc_calculate_pkt_len() overwriting pkt_len in cb area using "inner"'s
size table
Later, whenever the time comes to e.g. dequeue or peek at the packet,
"outer" will see packet size set in (4) whenever it calls qdisc_pkt_len().
For now, as far as I can see, the stab functionality is ready to be
used, but no scheduler actually uses it - so the whole chain ends at
setting ((struct qdisc_skb_cb*)skb->cb)->pkt_len during
qdisc_enqueue_root() to skb->len.
If I was to add atm adaptation to HFSC using size tables (as suggested
by Patrick), I'd like to know which direction to choose:
1) be prepared for it (e.g. save pkt_len, rerun
qdisc_calculate_pkt_len() every time adjusted length is needed, restore
the previous pkt_len afterwards) - but it's ugly and bloaty, and causes
plenty of unnecessary calls to the calculate function.
2) change size table implementation, e.g.
- add depth field in struct Qdisc {} - 0 for root, and parent's
sch->depth+1 for any deeper qdisc, during qdisc creation
- make qdisc_calculate_pkt_len() and qdisc_pkt_len() use that as an
index, so instead of
struct qdisc_skb_cb {
unsigned int pkt_len;
char data[];
};
we would have something like:
struct qdisc_skb_cb {
unsigned int pkt_len[QDISC_MAX_DEPTH];
char data[];
};
static inline unsigned int qdisc_pkt_len(struct sk_buff *skb, struct
Qdisc *sch)
{
return qdisc_skb_cb(skb)->pkt_len[sch->depth];
}
etc.
3) Ignore ? Aka assume only outer (or non-work conserving) qdisc may use
size tables, but that's just wrong...
prev parent reply other threads:[~2008-12-04 13:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <49292F54.4020803@ziu.info>
2008-11-23 14:05 ` Question about HFSC atm+man patches Patrick McHardy
2008-11-24 13:56 ` Michal Soltys
2008-11-24 14:11 ` Patrick McHardy
2008-11-24 23:21 ` Michal Soltys
2008-11-26 22:54 ` Michal Soltys
2008-11-27 10:48 ` Patrick McHardy
2008-11-27 23:17 ` Michal Soltys
2008-12-04 13:55 ` Michal Soltys [this message]
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=4937E15A.9090909@ziu.info \
--to=soltys@ziu.info \
--cc=netdev@vger.kernel.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).