[Click] userlevel performance

[Roman Chertov]

On Wed, 17 Nov 2010 08:24:37 -0800 Eddie Kohler <kohler at cs.ucla.edu> wrote

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

I believe it is this patch. 
https://github.com/kohler/click/commit/123c9b9b3fe55d5c563a8175ae0b9108c0e78b99
Roman

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