public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Cc: Albert Cahalan <acahalan@gmail.com>,
	Mikael Abrahamsson <swmike@swm.pp.se>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	netdev@vger.kernel.org
Subject: Re: txqueuelen has wrong units; should be time
Date: Sun, 27 Feb 2011 21:07:53 +0100	[thread overview]
Message-ID: <1298837273.8726.128.camel@edumazet-laptop> (raw)
In-Reply-To: <20110227125540.40754c5y78j9u2m8@hayate.sektori.org>

Le dimanche 27 février 2011 à 12:55 +0200, Jussi Kivilinna a écrit :
> Quoting Albert Cahalan <acahalan@gmail.com>:
> 
> > On Sun, Feb 27, 2011 at 2:54 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >> Le dimanche 27 février 2011 à 08:02 +0100, Mikael Abrahamsson a écrit :
> >>> On Sun, 27 Feb 2011, Albert Cahalan wrote:
> >>>
> >>> > Nanoseconds seems fine; it's unlikely you'd ever want
> >>> > more than 4.2 seconds (32-bit unsigned) of queue.
> > ...
> >> Problem is some machines have slow High Resolution timing services.
> >>
> >> _If_ we have a time limit, it will probably use the low resolution (aka
> >> jiffies), unless high resolution services are cheap.
> >
> > As long as that is totally internal to the kernel and never
> > getting exposed by some API for setting the amount, sure.
> >
> >> I was thinking not having an absolute hard limit, but an EWMA based one.
> >
> > The whole point is to prevent stale packets, especially to prevent
> > them from messing with TCP, so I really don't think so. I suppose
> > you do get this to some extent via early drop.
> 
> I made simple hack on sch_fifo with per packet time limits  
> (attachment) this weekend and have been doing limited testing on  
> wireless link. I think hardlimit is fine, it's simple and does  
> somewhat same as what packet(-hard)limited buffer does, drops packets  
> when buffer is 'full'. My hack checks for timed out packets on  
> enqueue, might be wrong approach (on other hand might allow some more  
> burstiness).
> 


Qdisc should return to caller a good indication packet is queued or
dropped at enqueue() time... not later (aka : never)

Accepting a packet at t0, and dropping it later at t0+limit without
giving any indication to caller is a problem.

This is why I suggested using an EWMA plus a probabilist drop or
congestion indication (NET_XMIT_CN) to caller at enqueue() time.

The absolute time limit you are trying to implement should be checked at
dequeue time, to cope with enqueue bursts or pauses on wire.

  reply	other threads:[~2011-02-27 20:07 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-27  5:44 txqueuelen has wrong units; should be time Albert Cahalan
2011-02-27  7:02 ` Mikael Abrahamsson
2011-02-27  7:54   ` Eric Dumazet
2011-02-27  8:27     ` Albert Cahalan
2011-02-27 10:55       ` Jussi Kivilinna
2011-02-27 20:07         ` Eric Dumazet [this message]
2011-02-27 21:32           ` Jussi Kivilinna
2011-02-28 11:43           ` Jussi Kivilinna
2011-02-28 13:10             ` Eric Dumazet
2011-02-28 18:31               ` Jussi Kivilinna
2011-02-28 16:11           ` John W. Linville
2011-02-28 16:48             ` Eric Dumazet
2011-02-28 16:55               ` John W. Linville
2011-02-28 17:18                 ` Eric Dumazet
2011-02-28 21:45                 ` John Heffner
2011-03-01  4:11                   ` Albert Cahalan
2011-03-01  4:18                     ` David Miller
2011-03-01  6:54                       ` Albert Cahalan
2011-03-01  7:25                         ` David Miller
2011-03-01  7:26                         ` Eric Dumazet
2011-03-01 19:37                           ` Albert Cahalan
2011-03-01 20:14                             ` Eric Dumazet
2011-03-01 20:16                               ` Eric Dumazet
2011-03-02  3:10                           ` Mikael Abrahamsson
2011-03-02 20:25                             ` Chris Friesen
2011-03-01  5:01                     ` Eric Dumazet
2011-03-01  5:36                       ` Eric Dumazet
2011-02-27 23:33         ` Albert Cahalan
2011-02-28 11:23           ` Jussi Kivilinna
2011-03-02 21:54             ` [RFC LOL OMG] pfifo_lat: qdisc that limits dequeueing based on estimated link latency John W. Linville
2011-03-02 22:08               ` John W. Linville
2011-03-03 12:51               ` Eric Dumazet
2011-02-28 15:38           ` txqueuelen has wrong units; should be time Hagen Paul Pfeifer
2011-02-28 16:37             ` Albert Cahalan
2011-02-28 17:45               ` John W. Linville
2011-02-28 17:20             ` Bill Sommerfeld
2011-02-28 21:51               ` John Heffner
2011-03-01  0:46                 ` Mikael Abrahamsson
2011-03-02  6:25                   ` Stephen Hemminger
2011-03-02  6:41                     ` Mikael Abrahamsson
2011-03-02  7:07                       ` Stephen Hemminger
2011-03-02 16:41                         ` Mikael Abrahamsson
2011-03-02 16:50                           ` Eric Dumazet

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=1298837273.8726.128.camel@edumazet-laptop \
    --to=eric.dumazet@gmail.com \
    --cc=acahalan@gmail.com \
    --cc=jussi.kivilinna@mbnet.fi \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=swmike@swm.pp.se \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox