On Fri, 2006-06-23 at 17:21 +0200, Patrick McHardy wrote:
> Not really. The randomization doesn't happen by default, but it doesn't
> influence this anyway. SFQ allows flows to send up to "quantum" bytes
> at a time before moving on to the next one. A flow that sends 75 * 20
> byte will in the eyes of SFQ use 1500bytes, on the (ethernet) wire it
> needs 4800bytes. A flow that sents 1500byte packets will only need
> 1504 bytes on the wire, but will be treated equally. So it does make
> a different for SFQ.
I hadn't even thought to check. My bad. The S in SFQ stands
for stochastic, so something that does without randomisation
the algorithm implemented couldn't really be called SFQ -
particularly as it weakens the algorithm considerably. I
hope that most users do specify a perturb.
Your 20 byte example is hardly realistic. skb->len includes
the 14 byte ethernet header, so there is a total of 6 data
bytes in a 20 byte packet. The IP header alone is 20 bytes.
TCP as implemented on Linux adds another 32 bytes (20 + the
rtt option). In other words I agree with Jamal's comments
elsewhere - optimising for MPU sized packets doesn't seem
like a win.
> Not a problem as long as the new stuff doesn't break anything existing.
> My patch introduces a TCA_STAB (for size table), similar to the _RTAB
> attributes. Old iproute with new kernel and new iproute with old kernel
> both work fine.
OK, good.
> Its not about cleanup, its about providing the same capabilities
> to all qdiscs instead of just a few selected ones and generalizing
> it so it is also usable for non-ATM overhead calculations.
Perhaps I chose my words poorly.
My intent was to contrast the size and goals of the two
proposed patches. The ATM patch is a 37 line patch. It
includes some minor cleanups. From the pseudo code you
have posted what you are proposing is a more ambitious and
much larger patch that moves a chunk of user space code
into the kernel. I am a complete newbie when it comes to
getting code into the kernel, but that strikes me as
contentious. I would rather not have the ATM patch
depend on it.
By the by, here are a couple of observations:
1. The entries in the current rtab are already very closely
related to packet lengths. They are actually the packet
length multiplied by a constant that converts the units
from "bytes" to "jiffies". The constant is the same for
all entries in the table.
2. As such, the current rtab could already be used by SFQ
and any other qdisc that needs to know the packet length.
That SFQ doesn't do this is probably because it doesn't
effect its performance overly.
3. Be that as it may, the current RTAB isn't in the most
convenient form for SFQ, and I am guessing it is in a
very inconvenient form for HFSC. Adding a new version
that is identical except that it contains the raw packet
length would be a simple change. In that format it
could be used by all qdiscs. The users of the existing
rtab would have to do the multiplication that converts
the packet length to jiffies in the kernel. This means
the conceptually at least, should the gootput change
you need to change this one constant, not the entire
table.
4. Much as you seem to dislike having the rate / packet length
calculations in user space, having them there makes it easy
to add new technologies such as ATM. You just have to
change a user space tool - not the kernel.
5. We still did have to modify the kernel for ATM. That was
because of its rather unusual characteristics. However,
it you look at the size of modifications made to the kernel
verses the size made to the user space tool, (37 lines
versus 303 lines,) the bulk of the work was does in user
space.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
