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

[Patrick McHardy <kaber@trash.net>]

Ariane Keller wrote:
> Patrick McHardy wrote:
>>
>> 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.


That sounds like it would also be possible using rtnetlink. You could
send out a notification whenever you switch the active buffer and have
userspace listen to these and replace the inactive one.