All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarek Poplawski <jarkao2@gmail.com>
To: Alexander Duyck <alexander.h.duyck@intel.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH 00/14]: Killing qdisc->ops->requeue().
Date: Wed, 15 Oct 2008 06:45:22 +0000	[thread overview]
Message-ID: <20081015064522.GA4215@ff.dom.local> (raw)
In-Reply-To: <48F502FA.4040004@intel.com>

On Tue, Oct 14, 2008 at 01:37:14PM -0700, Alexander Duyck wrote:
> Jarek Poplawski wrote:
>> On Tue, Oct 14, 2008 at 09:41:30AM -0700, Alexander Duyck wrote:
>> ...
>>> I think if anything it seems like you guys actually found the cpu
>>> performance issue a while back in the fact that the dev_requeue_skb was
>>> calling __netif_schedule when requeuing on a stopped queue.  That is the
>>> one piece I would say needs to be changed so that you only call
>>> __netif_schedule if the skb is not going to a stopped queue.
>>
>> BTW, since one of the other "dreams" of killing requeuing failed, I
>> think this proposal is worth checking, but David was concerned about
>> some issues with buggy drivers after __netif_schedule() removing.
>>
>> Jarek P.
>
> I would say not to remove it.  Just add a check to verify that the queue  
> the packet is bound for is not stopped prior to calling it.  If the  
> queue is stopped it should be rescheduled by the wake_queue call when  
> the device has cleared the queue.

Sure, I meant "after __netif_schedule() call removing". Anyway, there
were a discussion on something like this:

http://marc.info/?l=linux-netdev&m=122197536025956&w=2

> Unfortunately I am currently working on other projects so I don't really  
>  have the time to create and test a patch for this.  Hopefully my input  
> has proven useful.

Without this __netif_schedule() call we should expect at least higher
cpu use here while packets are xmitted to a stopped queue compared to
older kernels or the current one (especially with multi qdisc/class/
filter configs), so first we should know this requeuing from the top is
really necessary, and I didn't see anything convincing about this yet.

Thanks,
Jarek P.

  reply	other threads:[~2008-10-15  6:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-14  9:52 [PATCH 00/14]: Killing qdisc->ops->requeue() Jarek Poplawski
2008-10-14 11:39 ` Patrick McHardy
2008-10-14 12:26   ` Jarek Poplawski
2008-10-14 12:32     ` Patrick McHardy
2008-10-14 17:56       ` Jarek Poplawski
2008-10-14 20:18         ` David Miller
2008-10-14 20:44         ` Patrick McHardy
2008-10-15  8:27           ` Jarek Poplawski
2008-10-15  9:45             ` Patrick McHardy
2008-10-14 16:41 ` Alexander Duyck
2008-10-14 18:37   ` Jarek Poplawski
2008-10-14 18:41     ` Jarek Poplawski
2008-10-14 19:15   ` Jarek Poplawski
2008-10-14 20:37     ` Alexander Duyck
2008-10-15  6:45       ` Jarek Poplawski [this message]
2008-10-15  7:19         ` Jarek Poplawski

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=20081015064522.GA4215@ff.dom.local \
    --to=jarkao2@gmail.com \
    --cc=alexander.h.duyck@intel.com \
    --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.