[Click] userlevel performance

[Eddie Kohler]

Hey Beyers,

On 10/29/10 5:02 PM, Beyers Cronje wrote:
> One last thing, the patch I just mailed to the list fixes an issue where
> "SNIFFER false" was not honored and you ended up in sniffer mode, which
> might affect performance.

I'm sorry, I am just trying to process my email, and I can't actually 
find this patch anywhere!  Has it been applied?

Eddie


>
> Beyers
>
>
>
> On Fri, Oct 29, 2010 at 1:37 AM, Roman Chertov<rchertov at cs.ucsb.edu>  wrote:
>
>> On Thu, 28 Oct 2010 13:58:50 -0700 Cliff Frey<cliff at meraki.com>  wrote
>>
>>> I don't have a setup that I can easily/quickly use to test.  All the
>> same,
>>> I'm curious what the interface statistics do during this time on both of
>> the
>>> interfaces (i.e. any errors?  how many packets transmitted/received)
>>
>> [local]# click test2.click -h ctr1.count -h ctr2.count -h fd.count -h
>> fd.kernel_drops
>> ctr1.count:
>> 100000
>>
>> ctr2.count:
>> 4503
>>
>> fd.count:
>> 0
>>
>> fd.kernel_drops:
>> ??
>>
>> ?? means that the number of kernel drops is unknown.
>>
>> [local]# ethtool -S eth2
>> NIC statistics:
>>      rx_packets: 9
>>      tx_packets: 100011
>>      rx_bytes: 2749
>>      tx_bytes: 150401691
>>
>> [local]# ethtool -S eth3
>> NIC statistics:
>>      rx_packets: 100004
>>      tx_packets: 17
>>      rx_bytes: 150400641
>>      tx_bytes: 3429
>>
>> According to ethtool, all of the 100000 packets were sent and received w/o
>> issues (the extra packets are due to IPv6 when the interfaces came on).
>>
>> So it looks like that problem is somewhere between Linux and Click getting
>> the
>> packets to ToDevice.  I am curious what results Bejers will get.
>>
>> Roman
>>
>>>
>>> Also, I'm curious what was going on inside of ToDevice and FromDevice.
>>   The
>>> linuxmodule version of these elements have a bunch of counters (visible
>>> through the "calls" handler), it would be cool if the userlevel versions
>> had
>>> these things too (i.e. run_select_count, packets for both, write_errors,
>>> empty_pulls for ToDevice,  recvfrom_errors, recvfrom_eagains for
>> fromdevice)
>>>
>>> I doubt it, but you also might get different behavior if you add a Queue
>>> between the ratedsource and the todevice.
>>>
>>> Cliff
>>>
>>> On Thu, Oct 28, 2010 at 10:55 AM, Roman Chertov<rchertov at cs.ucsb.edu
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I was curious if anybody could try this test for me using userlevel
>> click.
>>>>   I am
>>>> running CentOS 5.5 2.6.18-194.17.1.el5, and I have two network cards
>>>> connected
>>>> with a single cable.  If I run the script below using userlevel click,
>>>> FromDevice(eth3) will receive very few packets and the majority would
>> end
>>>> up
>>>> dropped on input.
>>>>
>>>> src :: RatedSource(\<00>, LENGTH 1458, RATE 8000, LIMIT 100000)
>>>>     ->  UDPIPEncap(10.0.1.1, 6667, 20.0.0.2, 6667)
>>>>     ->  EtherEncap(0x0800, 00:30:48:F9:EA:7B, 00:17:cb:0d:f8:db)
>>>>     ->  ctr1 :: AverageCounter
>>>>     ->  ToDevice(eth2);
>>>>
>>>>
>>>> fd :: FromDevice(eth3, SNIFFER false, PROMISC true)
>>>>    ->  ctr2 :: AverageCounter
>>>>    ->  Discard;
>>>>
>>>> This script just requires ethX names to be changed; otherwise, it can
>> be
>>>> run as
>>>> is.
>>>>
>>>> [root]# click test2.click -h ctr1.count -h ctr2.count
>>>> ctr1.count:
>>>> 100000
>>>>
>>>> ctr2.count:
>>>> 4482
>>>>
>>>> Roman
>>>>
>>>>
>>>> _______________________________________________
>>>> click mailing list
>>>> click at amsterdam.lcs.mit.edu
>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>
>>
>>
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click