All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karl Hiramoto <karl@hiramoto.org>
To: David Miller <davem@davemloft.net>
Cc: philipp_subx@redfish-solutions.com, 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: Tue, 15 Sep 2009 15:44:53 +0200	[thread overview]
Message-ID: <4AAF9A55.8030207@hiramoto.org> (raw)
In-Reply-To: <20090911.114848.177667600.davem@davemloft.net>

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.

--
Karl

  reply	other threads:[~2009-09-15 13:44 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 [this message]
2009-09-15 14:57               ` Karl Hiramoto
2009-09-16 18:04                 ` Philip A. Prindeville
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=4AAF9A55.8030207@hiramoto.org \
    --to=karl@hiramoto.org \
    --cc=davem@davemloft.net \
    --cc=linux-atm-general@lists.sourceforge.net \
    --cc=netdev@vger.kernel.org \
    --cc=philipp_subx@redfish-solutions.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.