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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html