From: Patrick McHardy <kaber@trash.net>
To: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, jgarzik@pobox.com,
cramerj <cramerj@intel.com>,
"Kok, Auke-jan H" <auke-jan.h.kok@intel.com>,
"Leech, Christopher" <christopher.leech@intel.com>
Subject: Re: [PATCH] NET: [UPDATED] Multiqueue network device support implementation.
Date: Wed, 11 Apr 2007 07:47:26 +0200 [thread overview]
Message-ID: <461C766E.5030107@trash.net> (raw)
In-Reply-To: <D5C1322C3E673F459512FB59E0DDC329029E454C@orsmsx414.amr.corp.intel.com>
Waskiewicz Jr, Peter P wrote:
>>This leaks the device. You treat every single-queue device as
>>having a single subqueue. If it doesn't get too ugly it would
>>be nice to avoid this and only allocate the subqueue states
>>for real multiqueue devices.
>
>
> We went back and forth on this. The reason we allocate a queue in every
> case, even on single-queue devices, was to make the stack not have
> branching for multiqueue and non-multiqueue devices. If we don't have
> at least one queue on a device, then we can't have
> netif_subqueue_stopped() in the hotpath unless we check if a device is
> multiqueue before. The original patches I released had this branching,
> and I was asked to not do that.
OK, thanks for the explanation.
>>>+ skb->queue_mapping =
>>>+ q->prio2band[q->band2queue[band&TC_PRIO_MAX]];
>>
>>
>>Does this needs to be cleared at some point again? TC actions
>>might redirect or mirror packets to other (multiqueue) devices.
>
>
> If an skb is redirected to another device, the skb should be filtered
> through that device's qdisc, yes?
Yes, but the device might not have a queue or use something different
than prio, so the value would stay the same. I think you need to clear
it before enqueueing a packet or alternatively when redirecting in the
mirred action.
next prev parent reply other threads:[~2007-04-11 5:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-10 0:32 [PATCH] NET: [UPDATED] Multiqueue network device support implementation Peter P Waskiewicz Jr
2007-04-10 0:28 ` Patrick McHardy
2007-04-10 1:40 ` Waskiewicz Jr, Peter P
2007-04-10 9:04 ` Patrick McHardy
2007-04-11 16:52 ` Waskiewicz Jr, Peter P
2007-04-11 17:03 ` Patrick McHardy
2007-04-12 5:24 ` Zhu Yi
2007-04-10 9:48 ` Patrick McHardy
2007-04-10 16:27 ` Waskiewicz Jr, Peter P
2007-04-11 5:47 ` Patrick McHardy [this message]
2007-04-11 15:40 ` Waskiewicz Jr, Peter P
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=461C766E.5030107@trash.net \
--to=kaber@trash.net \
--cc=auke-jan.h.kok@intel.com \
--cc=christopher.leech@intel.com \
--cc=cramerj@intel.com \
--cc=davem@davemloft.net \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=peter.p.waskiewicz.jr@intel.com \
/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.