All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Philip A. Prindeville" <philipp_subx@redfish-solutions.com>
To: Karl Hiramoto <karl@hiramoto.org>
Cc: David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, linux-atm-general@lists.sourceforge.net
Subject: Re: [Linux-ATM-General] [PATCH] atm/br2684: netif_stop_queue() when atm device busy and netif_wake_queue() when we can send packets again.
Date: Wed, 16 Sep 2009 11:04:49 -0700	[thread overview]
Message-ID: <4AB128C1.6010303@redfish-solutions.com> (raw)
In-Reply-To: <4AAFAB60.4080302@hiramoto.org>

On 09/15/2009 07:57 AM, Karl Hiramoto wrote:
> Karl Hiramoto wrote:
>   
>> David Miller wrote:
>>   
>>     
>>> From: Karl Hiramoto <karl@hiramoto.org>
>>> Date: Thu, 10 Sep 2009 23:30:44 +0200
>>>
>>>   
>>>     
>>>       
>>>> I'm not really sure if or how many packets to upper layers buffer.
>>>>     
>>>>       
>>>>         
>>> This is determined by ->tx_queue_len, so whatever value is being
>>> set for ATM network devices is what the core will use for backlog
>>> limiting while the device's TX queue is stopped.
>>>     
>>>       
>> I tried varying tx_queue_len by 10, 100,  and 1000x, but it didn't seem 
>> to help much.  Whenever the atm dev called netif_wake_queue() it seems 
>> like the driver still starves for packets  and still takes time to get 
>> going again.
>>
>>
>> It seem like when the driver calls netif_wake_queue() it's TX hardware 
>> queue is nearly full, but it has space to accept new packets.  The TX 
>> hardware queue has time to empty, devices starves for packets(goes 
>> idle), then finally a packet comes in from the upper networking 
>> layers.   I'm not really sure at the moment where the problem lies to my 
>> maximum throughput dropping.
>>
>> I did try changing sk_sndbuf to 256K but that didn't seem to help either.
>>
>> --
>>     
> Actually i think i spoke too soon,  tuning TCP parameters, txqueuelen on 
> all machines the server, router and client it seems my performance came 
> back.
>
> --
> Karl
>   

So what size are you currently using?

Out-of-the-box build, 2.6.27.29 seems to set it to 1000.

-Philip


  reply	other threads:[~2009-09-16 18:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-28 10:38 [PATCH] br2684 testing needed for packet loss and performance Karl Hiramoto
2009-08-28 12:25 ` [Linux-ATM-General] " Chas Williams (CONTRACTOR)
2009-08-29 10:24   ` Karl Hiramoto
2009-08-29 11:24     ` [PATCH] atm/br2684: netif_stop_queue() when atm device busy and netif_wake_queue() when we can send packets again Karl Hiramoto
2009-08-31 14:29       ` Chas Williams (CONTRACTOR)
2009-09-03  6:27         ` David Miller
2009-09-03 13:44           ` Chas Williams (CONTRACTOR)
2009-09-10 19:49       ` [Linux-ATM-General] " Philip A. Prindeville
2009-09-10 21:30         ` Karl Hiramoto
2009-09-11 18:48           ` David Miller
2009-09-15 13:44             ` Karl Hiramoto
2009-09-15 14:57               ` Karl Hiramoto
2009-09-16 18:04                 ` Philip A. Prindeville [this message]
2009-09-11 19:56           ` Philip A. Prindeville

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=4AB128C1.6010303@redfish-solutions.com \
    --to=philipp_subx@redfish-solutions.com \
    --cc=davem@davemloft.net \
    --cc=karl@hiramoto.org \
    --cc=linux-atm-general@lists.sourceforge.net \
    --cc=netdev@vger.kernel.org \
    /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.