netdev - Re: PPPoE performance regression

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] [day] [month] [year] [list]

Date:	Thu, 14 Jun 2012 11:35:29 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	Nathan Williams <nathan@...verse.com.au>,
	Karl Hiramoto <karl@...amoto.org>,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	John Crispin <blogic@...nwrt.org>,
	Benjamin LaHaise <bcrl@...ck.org>
Subject: Re: PPPoE performance regression

On Thu, 2012-06-14 at 16:18 +1000, Paul Mackerras wrote:
> Umm, how does ppp_output_wakeup() actually get called?

In fact I'm thinking of eliminating ppp_output_wakeup() in the general
case.

The idea (and it is *just* an idea so far) is to introduce
ppp_sent_queue(), ppp_completed_queue() and ppp_reset_queue()¹ functions
which take a ppp_chan and map onto the corresponding netdev_* functions
for BQL.

Having done that, we should be able to trigger the wakeup automatically
from the ppp_completed_queue() function, and there's no need for channel
drivers to call ppp_output_wakeup() directly. Not only do we get proper
holistic queue length management, we also move the flow control into PPP
and get rid of the horrid dependency on internal PPP locking that's
documented in commit 9d02daf75², and which we'd have to address on the
PPPoX side too.

And the overhead that Ben is concerned about should be fairly minimal.

-- 
dwmw2

¹ For ppp_reset_queue in the mlppp case it gets moderately non-trivial.
² Look for 'downl'. Ick.

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (6171 bytes)