All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarek Poplawski <jarkao2@gmail.com>
To: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Cc: David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, Patrick McHardy <kaber@trash.net>
Subject: Re: [PATCH] net-sched: add packet length pointer parameter for qdisc_enqueue
Date: Thu, 31 Jul 2008 17:40:56 +0200	[thread overview]
Message-ID: <20080731154055.GA2532@ami.dom.local> (raw)
In-Reply-To: <20080731174919.157875i4bpxod3wg@hayate.ip6>

On Thu, Jul 31, 2008 at 05:49:19PM +0300, Jussi Kivilinna wrote:
> Quoting "Jarek Poplawski" <jarkao2@gmail.com>:
>
>> On Thu, Jul 31, 2008 at 12:04:57PM +0300, Jussi Kivilinna wrote:
>>> Quoting "Jarek Poplawski" <jarkao2@gmail.com>:
>>>
>>>> On 30-07-2008 20:55, Jussi Kivilinna wrote:
>>>>> Pass packet length to caller through pointer so that length is
>>>>> available to caller even if inner qdisc frees skb.
>> ...
>>>> 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.
>>>
>>>>
>>>> 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.

      reply	other threads:[~2008-07-31 15:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-30 18:55 [PATCH] net-sched: add packet length pointer parameter for qdisc_enqueue Jussi Kivilinna
2008-07-31  2:11 ` Herbert Xu
2008-07-31  7:02 ` Jarek Poplawski
2008-07-31  9:04   ` Jussi Kivilinna
2008-07-31  9:36     ` Jarek Poplawski
2008-07-31 14:49       ` Jussi Kivilinna
2008-07-31 15:40         ` Jarek Poplawski [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080731154055.GA2532@ami.dom.local \
    --to=jarkao2@gmail.com \
    --cc=davem@davemloft.net \
    --cc=jussi.kivilinna@mbnet.fi \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.