On Thu, Jul 31, 2008 at 05:49:19PM +0300, Jussi Kivilinna wrote:

Quoting "Jarek Poplawski" [off-list ref]:

quoted

On Thu, Jul 31, 2008 at 12:04:57PM +0300, Jussi Kivilinna wrote:

quoted

Quoting "Jarek Poplawski" [off-list ref]:

quoted

On 30-07-2008 20:55, Jussi Kivilinna wrote:

quoted

Pass packet length to caller through pointer so that length is
available to caller even if inner qdisc frees skb.

...

quoted

quoted

As I've written before, IMHO using an skb after enqueuing should be
avoided unless we refcounted it or the returned code is clear enough,
so the idea of this patch could be right to me. But, I guess, you are
changing here the way it's done: the size is calculated before the
current enqueing instead of after the last one.

Doh, you're right. qdisc->enqueue should pass packet length too.

quoted

BTW, since I don't really get this "stab" idea enough, I wonder how
it is expected to be used: with a top qdisc, a leaf one or some
summing?

With top and/or leaf qdisc, inner stab overrides upper.

Probably this could be called a bit ugly, but another way could be
simply updating these .bstas.bytes in ->dequeue() with a difference
between calculated and skb->len?

That would work, but HFSC uses packet length in enqueue for something  
else too:
	if (cl->qdisc->q.qlen == 1)
		set_active(cl, qdisc_pkt_len(skb));

Could this bit be moved to dequeue?

I think, Patrick should look at this.

On the other hand, it seems reading such an skb after enqueuing with
NET_XMIT_SUCCESS could be quite safe after a patch I'm currently
working on, because there will be no more overloading in case of
TC_ACT_STOLEN etc. More problematic would be keeping stats exactly
after NET_XMIT_CN, but it's usually skipped now. So maybe it would be
better to wait with these changes a bit?

Jarek P.