netdev - Re: [PATCH 0/2] netem: trace enhancement

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, 03 Dec 2007 10:12:20 +0100
From:	Ariane Keller <ariane.keller@....ee.ethz.ch>
To:	Patrick McHardy <kaber@...sh.net>
CC:	Ariane Keller <ariane.keller@....ee.ethz.ch>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	netdev@...r.kernel.org, herbert@...dor.apana.org.au,
	Rainer Baumann <baumann@....ee.ethz.ch>
Subject: Re: [PATCH 0/2] netem: trace enhancement

Patrick McHardy wrote:
> Ariane Keller wrote:
>> Thanks for your comments!
>>
>> I'd like to better understand your dislike of the current 
>> implementation  of the data transfer from user space to kernel space.
>> Is it the fact that we use configfs?
>> I think, we had already a discussion about this (and we changed from 
>> procfs to configfs).
>> Or don't you like that we need a user space daemon which is 
>> responsible for feeding the data to the kernel module?
>> I think we do not have another option, since the trace file may be of 
>> arbitrary length.
>> Or anything else?
> 
> 
> I dislike using anything besides rtnetlink for qdisc configuration.
> The only way to transfer arbitary amounts of data over netlink would
> be to spread the data over multiple messages. But then again, you're
> using kmalloc and only seem to allocate 4k, so how large are these
> traces in practice?

For each packet to be processed there is 32bit of data, which encodes 
delay and drop, duplicate etc. The size of the actual trace file can 
therefore reach any length, depending on for how many packets the 
information is encoded (up to several GB).
Therefore we send the trace file in chunks of 4000bytes to the kernel. 
In order to have always a "packet-delay-value ready", we maintain two 
"delay queues" in the kernel (each of 4k). In a first step, both queues 
are filled, and the values are read from the first queue, if this queue 
is finished, we read values from the second queue and fill the first 
queue with new values from the trace file etc. Therefore we have a user 
space process running, which reads the values from the trace file, and 
sends them to the kernel.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html