[Click] performance experiment problems - low forwarding rates

[Giorgio Calarco]

----- Original Message ----- 
From: "Nikitas Liogkas" <nikitas at CS.UCLA.EDU>
To: "Giorgio Calarco" <gcalarco at deis.unibo.it>
Cc: <click at amsterdam.lcs.mit.edu>
Sent: Wednesday, May 19, 2004 9:23 AM
Subject: Re: [Click] performance experiment problems - low forwarding rates


> Thanks for the suggestions, we've tried FastUDPSource and now we can
> generate up to 400,000 pkts/sec, which seems reasonable.


yeah, it's a layer-2 packet generator, much faster,
just remember you don't have any arp querier in such
configuration (fastudpgen + todevice), thus choose the right destination MAC
address...


> Yet, that does not explain that we can only get ~240,000 pkts/sec for
> the Simple
> configuration; you say yourself that with similar hardware you were
> able to do
> ~360,000 pps for the IP router configuration which is substantially
> more
> complex than ours.
>
> The Simple configuration we are using just polls the device for
> incoming
> packets, stores them in a queue, and transmits them to the destination
> without any processing whatsoever. What we are seeing is that the
> queue overflows very quickly and a lot of packets get dropped.
>


I can't be sure, but it sounds like you are perhaps spending
too much CPU time "managing"  the NICs DMA descriptors...
this is probably due to the fact the you have only one CPU
and 4 interfaces to poll...

you could try to play a bit with the ScheduleInfo
element, to dedicate more CPU time to the pull thread (ToDevice) than
the push thread (PollDevice)
(as a result, you should see RX_FIFO errors appering, you
should then decide if it's better to loose packets on the
NIC or in the output queue.... i suggest the first option...)

but I can't say if the global throughput of your router
will get any benefit from this, probably there should be
a point of compromise, which maximizes your throughput
as a function of the ScheduleInfo configuration.
Well, let us know if so !


ciao
giorgio



> I'll try and figure out something useful using the /proc/net
> handlers...
>
> nikitas
>
>