Daniel, Can you try running your config with undoing this update? https://github.com/kohler/click/commit/d65bfe4054a23468c808e95df4ab6b4a5ef9d9a3 Change ret = dev_queue_xmit(skb1); to ret = dev->netdev_ops->ndo_start_xmit(skb1, dev);
This change will send the packet straight to the device driver. Roman On Wed, 5 Oct 2011 19:23:31 +0200, Daniel Borkmann wrote: > Hi Cliff, > > On Wed, Oct 5, 2011 at 7:15 PM, Cliff Frey <[email protected]> wrote: >> You could try adding BURST 10 or something to your FromDevice >> configuration >> and see if that makes a difference. >> You could also try changing tasks_per_iter (there is a top level >> handler, so >> you could add "Script(write tasks_per_iter 300)" to your config). >> I don't actually think that either of the above will make much >> difference... >> as I believe that the click task should currently try and send 128 >> packets >> each time it is scheduled (tasks_per_iter * BURST == 128 * 1 == >> 128). >> However, the BURST one is definitely worth trying. >> You could also try changing the "weight" on your ethernet driver, >> but that >> also should default to 64 or higher, so I don't understand how/why >> so few >> packets would be processed each time. >> If you run ifconfig after the test, are there any error counters >> that are >> very high? > > Thanks for the hints. > > No, there aren't any error values on the NIC driver. If I turn off > click (click-uninstall), then the packet rate rises up to approx 1,38 > Mio pps (receive and drop by the kernel) and the context switch rate > decreases to less than 1000 per sec. I tried the whole experiment > multiple times - each time the same as described. Is the click kernel > thread running in high-priority or RT mode? This could maybe explain > the starvation of the ksoftirqd. > > Thanks, > Daniel > >> Cliff >> On Wed, Oct 5, 2011 at 8:58 AM, Daniel Borkmann >> <[email protected]> >> wrote: >>> >>> On Wed, Oct 5, 2011 at 4:06 PM, Eddie Kohler <[email protected]> >>> wrote: >>> > I'm thinking probably we should do that automatically. >>> >>> Hmm, if someone wants to do debugging, then it might not work >>> (since >>> the syms are stripped), except you have a special target for debug, >>> for instance. >>> >>> What I recently noticed running Click in kernelspace: the number of >>> context switches per second is very high (... too high) on a high >>> packet rate. More details: >>> >>> I have two machines Intel Core 2 Quad Q6600 CPU, 4 GB RAM, Intel >>> 82566DC Ethernet Controller (e1000e driver). Both have Debian 6.0. >>> One >>> machine has a vanilla Linux 3.0 running pktgen with 64 Byte packets >>> (max. load), the other one is running Linux 2.6.38 with click in >>> kernelspace. Both are directly connected. The config is: >>> source::FromDevice(eth0); drop::SimpleIdle; source->drop. I was >>> measuring packets per second and the system's context switches per >>> second, both gathered from procfs. The result was that I reached >>> about >>> 460k pps while having a context switch rate of about 200k cs/sec >>> (!). >>> (The high rate explains the rather low pps rate.) Running >>> (multithreaded) click in userspace on top of Linux 3.0, I got about >>> 545k pps and less than 1000 cs/sec. >>> >>> Has anyone measured similar values? Could it be, that the click >>> kernel >>> thread is pushing away CPU time for the ksoftirqd doing NAPI >>> (sofirqs >>> for RX) on the e1000e? >>> >>> Thanks, >>> Daniel >>> >>> > >>> > Eddie >>> > >>> > On 10/5/11 9:32 AM, Daniel Borkmann wrote: >>> >> >>> >> Hi Sandeep, >>> >> >>> >> thanks for your reply! :-) >>> >> >>> >> Stripping the debug symbols out of the module like ... >>> >> >>> >> root@xyz:~# strip -g /usr/local/lib/click.ko >>> >> >>> >> ... worked for me; I already was on the latest Git repository. >>> >> >>> >> Thanks, >>> >> Daniel >>> >> >>> >> On Wed, Oct 5, 2011 at 3:14 PM, sandeep<[email protected]> >>> wrote: >>> >>> >>> >>> I also had the same problem but it disappeared after I updated >>> to the >>> >>> latest >>> >>> git repository. https://github.com/kohler/click/tarball/master >>> >>> >>> >>> Kind Regards, >>> >>> Sandeep, >>> >>> PhD Student, >>> >>> CTVR - Trinity College Dublin >>> >>> On Wed, Oct 5, 2011 at 1:36 PM, Daniel >>> >>> Borkmann<[email protected]> >>> >>> wrote: >>> >>>> >>> >>>> Hi list, >>> >>>> I managed to build the patchless Click kernel version under >>> 2.6.38, >>> >>>> but insmod fails with the following: >>> >>>> >>> >>>> root@pc-10089:~# click-install forw.click >>> >>>> insmod: error inserting '/usr/local/lib/click.ko': -1 Cannot >>> allocate >>> >>>> memory >>> >>>> click-install: '/sbin/insmod /usr/local/lib/click.ko' failed >>> >>>> >>> >>>> Any ideas? Did anyone have same issues? >>> >>>> >>> >>>> Thanks, >>> >>>> Daniel >>> >>>> _______________________________________________ >>> >>>> click mailing list >>> >>>> [email protected] >>> >>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>> >>> >>> >>> >>> >> >>> >> >>> >> >>> > >>> >>> >>> >>> -- >>> Web: http://gnumaniacs.org >>> >>> _______________________________________________ >>> click mailing list >>> [email protected] >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> >> _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
