lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <FB112703C4930F4ABEBB5B763F96491139379643@MAILSERV2A.lorien.fkie.fgan.de>
Date:	Mon, 2 Jul 2012 08:38:55 +0000
From:	"Erdt, Ralph" <ralph.erdt@...e.fraunhofer.de>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	Rick Jones <rick.jones2@...com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: AW: AW: RFC: replace packets already in queue

> > 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.)


> Most packets don't stay in qdisc but are sitting in wireless driver,
> unless you really flood it. If it happens, you already are in trouble.

We ARE in trouble... :-/


> So code your qdisc thing, but I am not sure you'll get much
> improvement.

It's implemented already (it's just a little source file), and it worked in the simulation. But I cannot test them on real devices ATM.

My question is: Should I do the work to create and release a kernel patch and make it perfect over the time, or is this just our internal code, which I can leave at the current state? I know our module won't be used widely (too special), but I'm sure, there are a few people out there, which would be thankful for this.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ