Message-Id: <1169686529.5776.202.camel@ras.pc.brisbane.lube>
Date:	Thu, 25 Jan 2007 10:55:29 +1000
From:	Russell Stuart <russell-tcatm@...art.id.au>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	hadi@...erus.ca, netdev@...r.kernel.org,
	Jesper Dangaard Brouer <hawk@...u.dk>
Subject: Re: [PATCH REPOST 1/2] NET: Accurate packet scheduling for
	ATM/ADSL (kernel)

On Thu, 2007-01-25 at 01:06 +0100, Patrick McHardy wrote:
> Of course he has to, just like your "atm" parameter. In case
> of stabs it would be something like "stab atm".

The difference being with "atm" he is telling the kernel
he has an ATM line, but with STAB he is telling the 
kernel how it should internally calculate packet lengths
and transmission times.  Why should he care how the
kernel does it?  Surely this should be hidden.  As it
is now, BTW.

> > I was a little too brief.
> > 
> > The comment stems from the observation that in all
> > current implementations:
> > 
> >    const A_CONSTANT;
> >    for (i = 0; i < 256; i += 1)
> >      assert(RTAB[i] == STAB[i] * A_CONSTANT);
> > 
> > Ergo, if in addition to implementing STAB as you
> > plan to, A_CONSTANT was shipped to the kernel then
> > RTAB could be replaced.
> 
> At least look at the patch I sent. STAB mapping is _not_ a
> multiplication by a constant (which wouldn't be able to
> express minimum packet size or padding to multiples of cell
> sizes).

You have read this the wrong way.  Firstly I did look
at the patch you posted - and commented on it in some
detail.  Admittedly it was a while ago.  The details
are fuzzy now, but I am pretty sure I know what you
want achieve and how you plan to go about it.

Secondly, I am not saying STAB is a multiplication by
a constant - any more than RTAB is multiplication by
a constant.  I am fully aware that STAB can take into
account MPU's, cell padding, additional protocol 
overhead and whatnot - just like RTAB does now.

What I am saying is that on or about is summed up in
the tc_calc_xmittime() function in tc_core.c.  It is
a grand total of 1 line long:

  return tc_core_usec2tick(1000000*((double)size/rate));

Later on in the code, we have this assignment:

  rtab[i] = tc_calc_xmittime(bps, sz);

Which can be re-written:

  rtab[i] = tc_core_usec2tick(1000000*((double)size/rate));

If STAB was introduced and was kept to a fixed 256
elements (I am not suggesting it should be), the 
core change would be to change the line above to 
read:

  stab[i] = size;
  rtab[i] = tc_core_usec2tick(1000000*((double)stab[i]/rate));

Thus my assertion that:

  RTAB[i] = STAB[i] * A_CONSTANT

is literally true.  A_CONSTANT is currently always
1000000 / rate * HZ.

All I am saying is that in the kernel, wherever we
have a reference to rtab[i] now, after your stab is
introduced that reference could be replaced by
stab[i] * A_CONSTANT, provided A_CONSTANT was sent
with stab by tc.

Doing this would have several advantages:

  a.  Uses less space than having both RTAB and STAB.

  b.  Provides the framework to allow the kernel to
      overcomes my problem with HZ being too slow
      for ATM links > 2M bips/sec.

  c.  Puts an end to my whinging about compatibility
      problems above.  We can just send the old RTAB.
      It will be ignored by kernels that use STAB.

Are you objecting to this because I hadn't spelt it
out clearly, or is there something deeper I am 
missing?  It doesn't seem like a radical proposal to
me.

-
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