[{"id":1063,"web_url":"http://patchwork.ozlabs.org/comment/1063/","msgid":"<5f2db9d90809172356h9b31a87r516c389993814975@mail.gmail.com>","list_archive_url":null,"date":"2008-09-18T06:56:04","subject":"Re: [RFC PATCH] sched: only dequeue if packet can be queued to\n\thardware queue.","submitter":{"id":252,"url":"http://patchwork.ozlabs.org/api/people/252/","name":"Alexander Duyck","email":"alexander.duyck@gmail.com"},"content":"On Wed, Sep 17, 2008 at 11:43 PM, Alexander Duyck\n<alexander.h.duyck@intel.com> wrote:\n> This this patch is mangled I appologize, this is my first try sending\n> a patch directly to netdev.\n>\nAlready off to mangling things.  I got Dave's email wrong..  Sorry to\nall who reply and get a bad address warning, and I meant to say \"If\nthis patch is mangled..\".\n\nAnyway if anyone decides to reply please make note of the bad address.\n\nThanks,\n\nAlex","headers":{"Return-Path":"<netdev-owner@vger.kernel.org>","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.176.167])\n\tby ozlabs.org (Postfix) with ESMTP id 3EFD6DDE17\n\tfor <patchwork-incoming@ozlabs.org>;\n\tThu, 18 Sep 2008 16:56:14 +1000 (EST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752800AbYIRG4J (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tThu, 18 Sep 2008 02:56:09 -0400","(majordomo@vger.kernel.org) by vger.kernel.org id S1752081AbYIRG4I\n\t(ORCPT <rfc822; netdev-outgoing>); Thu, 18 Sep 2008 02:56:08 -0400","from mail-gx0-f16.google.com ([209.85.217.16]:40336 \"EHLO\n\tmail-gx0-f16.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751940AbYIRG4H (ORCPT\n\t<rfc822;netdev@vger.kernel.org>); Thu, 18 Sep 2008 02:56:07 -0400","by gxk9 with SMTP id 9so30862234gxk.13\n\tfor <netdev@vger.kernel.org>; Wed, 17 Sep 2008 23:56:04 -0700 (PDT)","by 10.151.156.12 with SMTP id i12mr681880ybo.217.1221720964490;\n\tWed, 17 Sep 2008 23:56:04 -0700 (PDT)","by 10.150.158.5 with HTTP; Wed, 17 Sep 2008 23:56:04 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\n\th=domainkey-signature:received:received:message-id:date:from:to\n\t:subject:cc:in-reply-to:mime-version:content-type\n\t:content-transfer-encoding:content-disposition:references;\n\tbh=a81PYkkdfMfiGaBWclgSM+laX6VF3dLWg/Ovt+MQ6f4=;\n\tb=r39L/iOjLN7dgJpFsXJ0W69I3nNLntg1xT3Xp0N82KTNXlEzhal9+XmCq8gXljJ0wo\n\tHZIlQAsfv6MoOOnOA8T2WqVHgGxvHoJj3yNlmC3WdmAZh5mFvWeaBqhIh+it4cQEKa0G\n\tuKBh+N7F+4NqtzfXyb48V5xZmnKFIQ3dSpy48=","DomainKey-Signature":"a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\n\th=message-id:date:from:to:subject:cc:in-reply-to:mime-version\n\t:content-type:content-transfer-encoding:content-disposition\n\t:references;\n\tb=hhOYoFDmbteSsWN2WVsWAB4NvxbR4/0u5TXr2HzMLHpwEdLpaBZx1erw0yr7tmZdB5\n\tH2i9D7K4SBHqVgAXN840bc5X1/2lQZs44tH0vB6GLHqoIsjHD/Oj1bh4KRzvPreyugy5\n\tyn1WxBp80jnsPMSJl09x/sse4EQlskt0rFXeQ=","Message-ID":"<5f2db9d90809172356h9b31a87r516c389993814975@mail.gmail.com>","Date":"Wed, 17 Sep 2008 23:56:04 -0700","From":"\"Alexander Duyck\" <alexander.duyck@gmail.com>","To":"\"Alexander Duyck\" <alexander.h.duyck@intel.com>","Subject":"Re: [RFC PATCH] sched: only dequeue if packet can be queued to\n\thardware queue.","Cc":"netdev@vger.kernel.org, jarkao2@gmail.com,\n\therbert@gondor.apana.org.au, davem@davemloft.net, kaber@trash.net","In-Reply-To":"<20080918063036.27934.91273.stgit@localhost.localdomain>","MIME-Version":"1.0","Content-Type":"text/plain; charset=ISO-8859-1","Content-Transfer-Encoding":"7bit","Content-Disposition":"inline","References":"<20080918063036.27934.91273.stgit@localhost.localdomain>","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<netdev.vger.kernel.org>","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1092,"web_url":"http://patchwork.ozlabs.org/comment/1092/","msgid":"<20080918.024655.22661052.davem@davemloft.net>","list_archive_url":null,"date":"2008-09-18T09:46:55","subject":"Re: [RFC PATCH] sched: only dequeue if packet can be queued to\n\thardware queue.","submitter":{"id":15,"url":"http://patchwork.ozlabs.org/api/people/15/","name":"David Miller","email":"davem@davemloft.net"},"content":"From: Alexander Duyck <alexander.h.duyck@intel.com>\nDate: Wed, 17 Sep 2008 23:43:02 -0700\n\n> diff --git a/net/sched/sch_atm.c b/net/sched/sch_atm.c\n> index 43d3725..91a40b2 100644\n> --- a/net/sched/sch_atm.c\n> +++ b/net/sched/sch_atm.c\n> @@ -516,12 +516,31 @@ static struct sk_buff *atm_tc_dequeue(struct Qdisc *sch)\n>  \n>  \tpr_debug(\"atm_tc_dequeue(sch %p,[qdisc %p])\\n\", sch, p);\n>  \ttasklet_schedule(&p->task);\n> -\tskb = p->link.q->dequeue(p->link.q);\n> +\tskb = p->link.q->ops->dequeue(p->link.q);\n>  \tif (skb)\n>  \t\tsch->q.qlen--;\n>  \treturn skb;\n>  }\n>  \n\nSo what is the difference between qdisc->dequeue and qdisc->ops->dequeue?\nThe same applies to ->enqueue.\n\nqdisc->{dequeue,enqueue} are given the value of ops->{dequeue,enqueue}\nat the time of qdisc creation.  I can only see two reasons for their\nexistence:\n\n1) We used to allow overriding ->enqueue and ->dequeue by certain\n   modules.  I see no such use like this in the current tree.\n\n2) For performance it's kept as a copy in the qdisc.\n\nEither way, changing ->ops->dequeue into ->dequeue doesn't seem to be\ncorrect, unless you have some explanation.\n\nThis is done in a few other places in your patch.","headers":{"Return-Path":"<netdev-owner@vger.kernel.org>","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.176.167])\n\tby ozlabs.org (Postfix) with ESMTP id 96607DDE11\n\tfor <patchwork-incoming@ozlabs.org>;\n\tThu, 18 Sep 2008 19:47:15 +1000 (EST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754864AbYIRJrK (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tThu, 18 Sep 2008 05:47:10 -0400","(majordomo@vger.kernel.org) by vger.kernel.org id S1754828AbYIRJrJ\n\t(ORCPT <rfc822; netdev-outgoing>); Thu, 18 Sep 2008 05:47:09 -0400","from 74-93-104-97-Washington.hfc.comcastbusiness.net\n\t([74.93.104.97]:32813\n\t\"EHLO sunset.davemloft.net\" rhost-flags-OK-FAIL-OK-OK)\n\tby vger.kernel.org with ESMTP id S1754743AbYIRJrH (ORCPT\n\t<rfc822;netdev@vger.kernel.org>); Thu, 18 Sep 2008 05:47:07 -0400","from localhost (localhost [127.0.0.1])\n\tby sunset.davemloft.net (Postfix) with ESMTP id C8F27C8C181;\n\tThu, 18 Sep 2008 02:46:55 -0700 (PDT)"],"Date":"Thu, 18 Sep 2008 02:46:55 -0700 (PDT)","Message-Id":"<20080918.024655.22661052.davem@davemloft.net>","To":"alexander.h.duyck@intel.com","Cc":"netdev@vger.kernel.org, jarkao2@gmail.com,\n\therbert@gondor.apana.org.au, kaber@trash.net","Subject":"Re: [RFC PATCH] sched: only dequeue if packet can be queued to\n\thardware queue.","From":"David Miller <davem@davemloft.net>","In-Reply-To":"<20080918063036.27934.91273.stgit@localhost.localdomain>","References":"<20080918063036.27934.91273.stgit@localhost.localdomain>","X-Mailer":"Mew version 6.1 on Emacs 22.1 / Mule 5.0 (SAKAKI)","Mime-Version":"1.0","Content-Type":"Text/Plain; charset=us-ascii","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<netdev.vger.kernel.org>","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1142,"web_url":"http://patchwork.ozlabs.org/comment/1142/","msgid":"<5f2db9d90809180751h2b62f9f2m1462ca65b2a612bf@mail.gmail.com>","list_archive_url":null,"date":"2008-09-18T14:51:13","subject":"Re: [RFC PATCH] sched: only dequeue if packet can be queued to\n\thardware queue.","submitter":{"id":252,"url":"http://patchwork.ozlabs.org/api/people/252/","name":"Alexander Duyck","email":"alexander.duyck@gmail.com"},"content":"On Thu, Sep 18, 2008 at 2:46 AM, David Miller <davem@davemloft.net> wrote:\n> So what is the difference between qdisc->dequeue and qdisc->ops->dequeue?\n> The same applies to ->enqueue.\n>\n> qdisc->{dequeue,enqueue} are given the value of ops->{dequeue,enqueue}\n> at the time of qdisc creation.  I can only see two reasons for their\n> existence:\n>\n> 1) We used to allow overriding ->enqueue and ->dequeue by certain\n>   modules.  I see no such use like this in the current tree.\n>\n> 2) For performance it's kept as a copy in the qdisc.\n>\n> Either way, changing ->ops->dequeue into ->dequeue doesn't seem to be\n> correct, unless you have some explanation.\n>\n> This is done in a few other places in your patch.\n\nI redefined qdisc->dequeue to be set to smart_dequeue in sch_generic.c:\n@@ -475,7 +491,7 @@ struct Qdisc *qdisc_alloc(struct netdev_queue *dev_queue,\n       skb_queue_head_init(&sch->q);\n       sch->ops = ops;\n       sch->enqueue = ops->enqueue;\n-       sch->dequeue = ops->dequeue;\n+       sch->dequeue = ops->smart_dequeue;\n       sch->dev_queue = dev_queue;\n       dev_hold(qdisc_dev(sch));\n       atomic_set(&sch->refcnt, 1);\n\nMost of the changes from qdisc->dequeue to qdisc->ops->dequeue are to have the\nstandard dequeue call use nothing but standard dequeue calls in it's\npath.  I needed\nto maintain qdisc->ops->dequeue because there are several functions throughout\nthe qdisc code that require the ability to dequeue a packet regardless\nof hw queue\nstate.\n\nThanks,\n\nAlex","headers":{"Return-Path":"<netdev-owner@vger.kernel.org>","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.176.167])\n\tby ozlabs.org (Postfix) with ESMTP id 553E7DDDFA\n\tfor <patchwork-incoming@ozlabs.org>;\n\tFri, 19 Sep 2008 00:51:21 +1000 (EST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754044AbYIROvP (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tThu, 18 Sep 2008 10:51:15 -0400","(majordomo@vger.kernel.org) by vger.kernel.org id S1753501AbYIROvP\n\t(ORCPT <rfc822; netdev-outgoing>); Thu, 18 Sep 2008 10:51:15 -0400","from yx-out-2324.google.com ([74.125.44.29]:25144 \"EHLO\n\tyx-out-2324.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1753066AbYIROvO (ORCPT\n\t<rfc822;netdev@vger.kernel.org>); Thu, 18 Sep 2008 10:51:14 -0400","by yx-out-2324.google.com with SMTP id 8so1062035yxm.1\n\tfor <netdev@vger.kernel.org>; Thu, 18 Sep 2008 07:51:13 -0700 (PDT)","by 10.151.141.8 with SMTP id t8mr1371074ybn.231.1221749473679;\n\tThu, 18 Sep 2008 07:51:13 -0700 (PDT)","by 10.150.158.5 with HTTP; Thu, 18 Sep 2008 07:51:13 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\n\th=domainkey-signature:received:received:message-id:date:from:to\n\t:subject:cc:in-reply-to:mime-version:content-type\n\t:content-transfer-encoding:content-disposition:references;\n\tbh=P4LatouatKlkKo42sGfZvFC3IlHO6h+t9OM5KKmY94Q=;\n\tb=XfIREsuTydb05n7oDQ8xDDi5FbdnkNXJNwAJfJyJWtCtN6Fgvj5acRU6fARSqcnYIq\n\tTTKWtNzSZ1eavRzjOfgRLLN2EB07t6rV35jT8hoK3MKs9aZfBAoFy+nRuHzvfTrpdum4\n\toke51wqE4eCmaAGDF608sWlxzFrdfH9BRIuBA=","DomainKey-Signature":"a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\n\th=message-id:date:from:to:subject:cc:in-reply-to:mime-version\n\t:content-type:content-transfer-encoding:content-disposition\n\t:references;\n\tb=Tc6I3eC2Nx+4IEbQr9QonUO+TQK1zsKiE4pnOWejd0fZoDHkdjifUMFnJhLDfVWCiv\n\twJ2U9TCSE3VUEsSk/GPO5Ta104Oi5xHOyB/mcLkoplM4kVkGJuleoG7/pczm7sV6esof\n\tUFcxkoNDPblu1KcG1Wdn848B44Ysmq78qd3a8=","Message-ID":"<5f2db9d90809180751h2b62f9f2m1462ca65b2a612bf@mail.gmail.com>","Date":"Thu, 18 Sep 2008 07:51:13 -0700","From":"\"Alexander Duyck\" <alexander.duyck@gmail.com>","To":"\"David Miller\" <davem@davemloft.net>","Subject":"Re: [RFC PATCH] sched: only dequeue if packet can be queued to\n\thardware queue.","Cc":"alexander.h.duyck@intel.com, netdev@vger.kernel.org,\n\tjarkao2@gmail.com, herbert@gondor.apana.org.au, kaber@trash.net","In-Reply-To":"<20080918.024655.22661052.davem@davemloft.net>","MIME-Version":"1.0","Content-Type":"text/plain; charset=ISO-8859-1","Content-Transfer-Encoding":"7bit","Content-Disposition":"inline","References":"<20080918063036.27934.91273.stgit@localhost.localdomain>\n\t<20080918.024655.22661052.davem@davemloft.net>","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<netdev.vger.kernel.org>","X-Mailing-List":"netdev@vger.kernel.org"}}]