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? - 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
