Date:	Mon, 5 Mar 2012 23:09:21 -0500
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	Dave Taht <dave.taht@...il.com>
CC:	<therbert@...gle.com>, <davem@...emloft.net>,
	<eric.dumazet@...il.com>, <netdev@...r.kernel.org>
Subject: Re: [PATCH] net: make CONFIG_BQL actually end user configurable

[Re: [PATCH] net: make CONFIG_BQL actually end user configurable] On 05/03/2012 (Mon 19:45) Dave Taht wrote:

> 
> 
> On Mon, Mar 5, 2012 at 7:38 PM, Paul Gortmaker <paul.gortmaker@...driver.com>
> wrote:
> 
>     Without the defining string or help text, LKC won't ever bother
>     to ask the end user for a setting for CONFIG_BQL -- you could
>     delete it from your .config and run make oldconfig and not a
>     thing would change -- it would still be silently re-enabled.
> 
> 
> 
> My specific problems with BQL as currently implemented are:
> 
> 1) There is no way to tell if a driver has it actually enabled or not
> at run time.

In a similar vein, I was interested in a (quick) way to tell if a
driver has it actually enabled *correctly*.  I'd coded up the basic
changes for a common PPC NIC, but I was then left wondering what I
could use as a quick high-water-mark to see if I'd really managed
to implement it correctly via some level of real run-time testing.

If we want to get driver authors involved in adding support to their
favourite hardware, some description of a basic sanity test would
probably be a worthwhile description to have.

Paul.
--

> 
> 2) Down below 100Mbit (the range that I care about) the controller
> can automatically allocate more ram than I would like for the outstanding
> data. I can (and do) easily control this by overriding the BQL default
> to something that makes things behave closer to what a ns2 model
> would predict (about 3k seems optimal) without affecting throughput.
> 
> whether or not this is a problem in the real world is yet to be seen.
>  
> 
>     While most people will have no reason to turn this off, the
>     ability to do so can be useful for testing BQL support additions
>     on previously BQL-unaware drivers and similar.
> 
>     The kconfig help text is largely taken from the original RFC
>     patchset 0/N header sent to netdev@...r.kernel.org in fall 2011.
> 
>     Signed-off-by: Paul Gortmaker <paul.gortmaker@...driver.com>
>     ---
> 
>     [Apologies if this was explicitly blocked for a reason; I couldn't
>      find a reason after searching netdev or threads at bufferbloat.net ]
> 
>     diff --git a/net/Kconfig b/net/Kconfig
>     index e07272d..fd1d815 100644
>     --- a/net/Kconfig
>     +++ b/net/Kconfig
>     @@ -241,10 +241,15 @@ config NETPRIO_CGROUP
>              a per-interface basis
> 
>      config BQL
>     -       boolean
>     +       boolean "Byte Queue Limits"
>            depends on SYSFS
>            select DQL
>            default y
>     +       ---help---
>     +         Byte queue limits are a mechanism to limit the size of the
>     transmit
>     +         hardware queue on a NIC by a number of bytes. The goal of these
>     byte
>     +         queue limits is to reduce latency caused by excessive queuing in
>     +         hardware without sacrificing throughput.
> 
>      config HAVE_BPF_JIT
>            bool
>     --
>     1.7.9.1
> 
>     --
>     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
> 
> 
> 
> 
> --
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://www.bufferbloat.net
--
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

Powered by blists - more mailing lists