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.
next prev 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 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.