netdev - AW: RFC: replace packets already in queue

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]

Date:	Mon, 2 Jul 2012 07:02:08 +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: RFC: replace packets already in queue

Hello Eric Dumazet,

sorry for the late answer, but sometimes it's not easy here...

> Problem is : with wireless, chances are high that the old packet is not
> waiting in qdisc, but in wireless queues.

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. And its impossible doing things 100%. We are happy to get 99%. This is a great improvement compared to the previous situation.

(* When I'm getting the picture in http://lartc.org/howto/lartc.qdisc.terminology.html correct, the qdisc is the outgoing queue and the last queue of the kernel. After this queue, there are only the hardware queues.)

> Anyway, adding a maxdelay to codel / fq_codel is really easy : This
> would drop packet if its sejourn time is above a given limit.

Just dropping when to old is not our goal. In fact we are avoiding blind dropping! With our replace we make sure that a packet of one class will go over the air when this packet is in line. But the information was replaced during the stay in the queue, so that the newest information got sent.

> If you want I can cook this patch.

Thank for you offer/support. But as described above, this is not a solution for us (we discussed this again in our group).  

Greetings
Ralph Erdt