netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
To: "Erdt, Ralph" <ralph.erdt@fkie.fraunhofer.de>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
	Rick Jones <rick.jones2@hp.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: AW: AW: RFC: replace packets already in queue
Date: Mon, 02 Jul 2012 22:32:23 +0200	[thread overview]
Message-ID: <4FF20557.4090501@gmail.com> (raw)
In-Reply-To: <FB112703C4930F4ABEBB5B763F96491139379643@MAILSERV2A.lorien.fkie.fgan.de>

Le 02/07/2012 10:38, Erdt, Ralph a écrit :
>>> Even if the wireless queue is a problem (because of our setup, this
>> is
>>> not a problem), the network stack queue (*) is the biggest queue, and
>>> a good point to optimize.
>>
>> Hmm, I am not convinced you have no queues on wireless.
>>
>> Please describe how you managed this.
>>
>> In fact this is the biggest problem with wireless : mac82011 framework
>> aggressively pull packets from Linux packet qdisc in order to perform
>> packet aggregation.
>
> I did not talking about W-LAN (802.11). I'm talking about an property technology which is able to
> send over KILOMETERs (WLAN<  100m) but with VERY low bandwidth: 9600 bit (no Mega, Giga or Kilo!)
> (W-LAN: slowest: 1Mbit). The devices is loosely connected to our boxes: No linux driver but a
> program which create an virtual network device. This just sends one packet to the devices and
> then waits for the acknowledgement that the packet was sent. THEN the next packet will be send.
> There is no further queue, because the wireless is so lame, that there is no need for that! (BTW:
> the qdisc and the connector are distinct problems/programs. There is no dependency.)

If I were you, I would use a tun/tap interface and manage a private packet queue in userspace. This 
way, you wouldn't have to manage the overhead of porting your kernel code to every new kernel versions.

	Nicolas.

  parent reply	other threads:[~2012-07-02 20:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-28 13:18 RFC: replace packets already in queue Erdt, Ralph
2012-06-28 16:24 ` Rick Jones
2012-06-29  8:46   ` AW: " Erdt, Ralph
2012-06-29  9:06     ` Eric Dumazet
2012-07-02  7:02       ` Erdt, Ralph
2012-07-02  7:31         ` Eric Dumazet
2012-07-02  8:38           ` AW: " Erdt, Ralph
2012-07-02 17:25             ` Rick Jones
2012-07-02 20:32             ` Nicolas de Pesloüan [this message]
2012-07-02 21:56               ` Eric Dumazet
2012-07-03  7:29                 ` AW: " Erdt, Ralph
2012-07-03 10:02                   ` RFC: (now non Base64) " Erdt, Ralph
2012-07-04 20:32                     ` Nicolas de Pesloüan
2012-07-18 14:50                       ` AW: " Erdt, Ralph

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=4FF20557.4090501@gmail.com \
    --to=nicolas.2p.debian@gmail.com \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=ralph.erdt@fkie.fraunhofer.de \
    --cc=rick.jones2@hp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).