netdev - Re: [PATCH] NET: Multiqueue network device support.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1182475614.30969.102.camel@debian.sh.intel.com>
Date:	Fri, 22 Jun 2007 09:26:54 +0800
From:	Zhu Yi <yi.zhu@...el.com>
To:	hadi@...erus.ca
Cc:	Patrick McHardy <kaber@...sh.net>,
	David Miller <davem@...emloft.net>,
	peter.p.waskiewicz.jr@...el.com, netdev@...r.kernel.org,
	jeff@...zik.org, auke-jan.h.kok@...el.com
Subject: Re: [PATCH] NET: Multiqueue network device support.

On Thu, 2007-06-21 at 11:39 -0400, jamal wrote:
> I gave you two opportunities to bail out of this discussion, i am gonna
> take that your rejection to that offer implies you my friend wants to
> get to the bottom of this i.e you are on a mission to find the truth.
> So lets continue this.

It sounds stupid I'm still trying to convince you why we need multiqueue
support in Qdisc when everybody else are already working on the code,
fixing bugs and preparing for merge. The only reason I keep the
conversation is that I think you _might_ have some really good points
that buried under everybody else's positive support for multiqueue. But
with the conversation goes on, it turns out not the truth. Let me snip
the nonsense part below and only focus on technical.

> > Besides, the lower THL you choose, the more CPU time is wasted in busy
> > loop for the only PL case; 
> 
> Your choice of THL and THH has nothing to do with what i am proposing.
> I am not proposing you even touch that. What numbers do you have today?

We don't have THL and THH in our driver. They are what you suggested.
The queue wakeup number is 1/4 of the ring size.

> What i am saying is you use _some_ value for opening up the driver; some
> enlightened drivers such as the tg3 (and the e1000 - for which i
> unashamedly take credit) do have such parametrization. This has already
> been proven to be valuable.
> 
> The timer fires only if a ring shuts down the interface. Where is the
> busy loop? If packets go out, there is no timer.

The busy loop happens in the period after the ring is shut down and
before it is opened again. During this period, the Qdisc will keep
dequeuing and requeuing PL packets in the Tx SoftIRQ, where the busy
loop happens.

> > the higher THL you choose, the slower the PH
> > packets will be sent out than expected (the driver doesn't fully utilize
> > the device function -- multiple rings, 
> 
> I dont think you understood: Whatever value you choose for THL and THH
> today, keep those. OTOH, the wake threshold is what i was refering to.

I don't even care about the threshold. Even you set it to 1, there is
still busy loop during the period before this first packet is sent out
in the air. But you cannot ignore this small time, because it could be
longer when the wireless medium is congested with high prio packets.

Thanks,
-yi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html