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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
