On Sun, 13 Apr 2008, Andy Furniss wrote:

quoted text
> Jesper Dangaard Brouer wrote:
>
>>  + The align to ATM cells is used for determining the (ATM) SAR
>>  + alignment overhead at the ATM layer. (SAR = Segmentation And
>>  + Reassembly).  This is for example needed when scheduling packet on an
>>  + ADSL connection.  Note that the extra ATM-AAL overhead is _not_
>>  + included in this calculation. This overhead is added in the kernel
>>  + before doing the rate table lookup, as this gives better precision
>>  + (as the table will always be aligned for 48 bytes).
>
> I see overhead is unsigned short. For me using pppoa/vc mux my overhead is IP 
> + 10. I am shaping on eth so skb->len is IP+14 hence I need a negative 
> overhead.

I'm not completely sure I understand how you end up with a negative 
overhead.  But I guess what you are saying, is that you need to remove the 
MAC header from the equation is it has already been added to skb->len (as 
you are doing routed and not bridged AAL5 encap).

That makes a good point for a _seperate_ patch (by you ;-)) where we 
change the overhead to be signed.  Or else you can do a userspace TC patch 
that abuse the cell_align, as you mentioned below, to express a negative 
overhead. (I'm trying to say, lets not mix these things... please!)


quoted text
> Recently built a 2.6.25-rc7 and noticed the cell_align has been added and the 
> tables jigged.

Yes, the tables has been aligned to 2^n and avoids underestimation. 
Thus, with upto 2^4 (16) the table aligns to 48 bytes (ATM cell payload 
size), standard TC uses 2^3. (If I remember correctly you, did comment on 
the patch so you must have read it ;-)).


quoted text
> I am (ab)using this at -5 now. Handy that I only need to patch TC rather 
> than kernel and I guess I could use other TCs if I needed to shape other 
> not atm ifs.

Yes, its nice that we have added this kind of flexibility to the kernel...


quoted text
> Russel Stuart's patches handled this case IIRC, has it been lost or have I 
> missed something (as usual)?

I don't think so, but I'm not sure about that... I think it was way too 
complex, which will make it difficult to maintain in the future.

Cheers,
   Jesper Brouer

ps. I'm currently on a roadtrip down the west-coast of USA, so I only have 
periodic wifi coverage at different campgrounds...

--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html