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]

Message-ID: <20071204154535.4eu35nfe9wks8kgg@email.ee.ethz.ch>
Date:	Tue, 04 Dec 2007 15:45:35 +0100
From:	Ariane Keller <ariane.keller@....ee.ethz.ch>
To:	Ben Greear <greearb@...delatech.com>,
	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

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

I guess using rtnetlink is possible. However I'm not sure about how to 
implement it:
The first thought was to use RTM_NEWQDISC to send the data to the 
netem_change() function (similar to tc_qdisc_modify() ). But with this 
we would need the tcm_handle, tcm_parent arguments etc. which are not 
known in q_netem.c
Therefore we would have to change the parse_qopt() function prototype 
in order to pass the whole "req" and not only the nlmsghdr.

The second possibility would be to add a new message type, e.g 
RTM_NETEMDATA. This type would be registered in the netem kernel module 
with a callback function netem_recv_data(). If this function receives 
some data it searches for the correct flow, and saves the data in the 
corresponding buffer.

However, I'm not convinced of any of these options. Do you have an 
alternative suggestion?

> Also, I think you will need a larger cache than 4-8k if you are 
> running higher speeds (100,000 pps, etc),
> as you probably can't rely on user-space responding reliably every 
> 10ms (or even less time for faster
> speeds.)

Increasing the cache size to say 32k for each buffer would be no problem.
Is this enough?

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