[Click] Userlevel performance issues

[Roman Chertov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Ross wrote:
> That's an interesting idea.  I didn't know this element existed.  How
> "experimental" is this element?  Also, when the documentation says 

It works fine if you don't do a lot of click-uninstall while the device
is open and packets are being written too.  On my machine you can easily
support at least 200Kpps on a Gig link with _every_ packet being written
to disc first.  I also use the ToUserDevice which does the reverse of
FromUserDevice.  I think I ironed out most of the bugs from the elements
over the past few months so they should be pretty stable to play around
with.  Let me know if you want an example config script.

> 
> "The FromUserDevice element expects that complete IP packets are written
> into the device."
> 
> Does that mean it is expecting packets without an Ethernet header?

Yeah it expects them to start with an IP header.  You can then add an
Ethernet header later on.  For, instance you can make a route table
based on the src IP and then add a correct Eth header.  Alternatively,
you can modify it to allow packets that start with an Eth header.

Roman

> 
> 
> Robert Ross
> DSCI Inc.
> Office: 732.542.3113 x173
> Home: 609.702.8114
> Cell: 609.509.5139
> Fax: 253.550.6198
> 
> -----Original Message-----
> From: Roman Chertov [mailto:rchertov at purdue.edu] 
> Sent: Friday, January 25, 2008 10:49 AM
> To: Robert Ross
> Cc: click at pdos.csail.mit.edu
> Subject: Re: [Click] Userlevel performance issues
> 
> Ross,
> 
> http://www.read.cs.ucla.edu/click/elements/fromuserdevice
> You might want to look into FromUserDevice element.  It runs in kernel
> level Click and then you can have a user level program just write raw
> packets into the element via /dev/touserX.
> 
> Roman
> 
> Robert Ross wrote:
>> We've been attempting to use userlevel Click here to perform some 
>> traffic loading and analysis of specific network conditions and 
>> behaviors.  The key important elements used are:
> 
>> *	
>> 	FromDump() for injecting packets
>> *	
>> 	Socket() for injecting packets
>> *	
>> 	FromHost() for injecting packets
>> *	
>> 	To Device for sending packets
>> *	
>> 	LinkUnqueue for link emulation
> 
>> We also have the obvious need for queues and several other elements 
>> which are not as critical to this discussion.  The problem came up 
>> when we started examining element handler values duing
> experimentation:
>> *	We first found that when UserLevel Click started pulling from a
>> PCAP file, the performance of the ToDevice() appeared to drop sharply.
>> What I mean by this is that the ToDevice() pull handler reported 
>> values in the range of 200 packets/second once the PCAP file started
> reading.
>> This resulted in the outbound queue just prior to the ToDevice() 
>> filling up and eventually overflowing because the packet rate in the 
>> PCAP file is far more than 200 packets/second.
>> *	We then tried using a Socket element to inject the packets
>> remotely rather than using the FromDump element.  We found that, for 
>> some reason, the LinkUnqueue element appears to affect the Socket's 
>> ability to pull packets quickly on the server side of the socket 
>> connection.  If the LinkUnqueue element has a high enough bandwidth 
>> parameter, then the socket itself has no problem keeping up with the 
>> injected load and the traffic profile looks as expected.  This is also
> 
>> true if you remove the LinkUnqueue element completely.  However, with 
>> the LinkUnqueue element specified as "512Kbps" the upstream Socket 
>> appears to slow itself down and only except packets from the client at
> 
>> a fraction of what it is obviously capable.
>> *	We then tried using TCPReplay to inject the packets into the
>> Click configuration FromHost.  The behavior here was exactly the same 
>> as the Socket element.  TCPReplay was only able to inject packets into
> 
>> the fake device at a fraction of what should be possible (around 200 
>> packets/second), the problem having some unknown relationship to the 
>> LinkUnqueue element.  If LinkUnqueue is removed, TCPReplay packets are
> 
>> pumped at the desired rate.
> 
>> So, having tried (and failed) multiple ways to inject traffic at a 
>> high speed, I have two ultimate questions:
> 
>> 1.	Why does reading from a PCAP file cause a drastic performance
>> hit on ToDevice pull processing?  How can this be resolved?  FromDump 
>> doesn't work at kernellevel and multi-threading doesn't work at 
>> userlevel.
>> 2.	Why does the LinkUnqueue element impact behavior of the upstream
>> Socket and FromHost elements?  Is there any way to stop this from 
>> happening and let the Socket and/or FromHost run as fast as possible?
> 
> 
>> Thanks,
>> Robert A. Ross
>> DSCI Inc.
>> 609-509-5139
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHmgs0T8ksiSCF2AYRAsaYAJ4ur5owbwwC3sGr8aC54T0Y6JaeEgCgj039
5VUyvT/ZpDko3NK6YuWm61s=
=kMTi
-----END PGP SIGNATURE-----