|To:||Robert Olsson <Robert.Olsson@xxxxxxxxxxx>, netdev@xxxxxxxxxxx|
|Subject:||Re: RFC: NAPI packet weighting patch|
|From:||Rick Jones <rick.jones2@xxxxxx>|
|Date:||Tue, 07 Jun 2005 16:19:46 -0700|
|Cc:||Martin Josefsson <gandalf@xxxxxxxxxxxxxx>, jamal <hadi@xxxxxxxxxx>, Stephen Hemminger <shemminger@xxxxxxxx>, Mitch Williams <mitch.a.williams@xxxxxxxxx>, "Ronciak, John" <john.ronciak@xxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, mchan@xxxxxxxxxxxx, buytenh@xxxxxxxxxxxxxx, jdmason@xxxxxxxxxx, "Venkatesan, Ganesh" <ganesh.venkatesan@xxxxxxxxx>, "Brandeburg, Jesse" <jesse.brandeburg@xxxxxxxxx>|
|References:||<468F3FDA28AA87429AD807992E22D07E0450C00B@orsmsx408> <Pine.CYG.firstname.lastname@example.org> <42A5284C.email@example.com> <firstname.lastname@example.org> <Pine.LNX.email@example.com> <firstname.lastname@example.org> <Pine.LNX.email@example.com> <firstname.lastname@example.org>|
|User-agent:||Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304|
If one wants to see the effect of different buffer replenishment strategies, I suppose that some netperf tests could indeed be used. It would be desirable to look at service demand moreso than throughput (assuming the throughput is link-bound). TCP_STREAM and/or TCP_MAERTS. I'm not sure the extent to which it would be visible to a TCP_RR test.
Differences in service demand could also be used to measure effects of irq migration, pinning IRQs and/or processes to specific CPUs and the like. The linux processor affinity stuff in netperf could use a little help though - it is easily confused as to when to use a two argument vs three argument sched_setaffinity call. I suspect one may also see differences in TCP_RR transaction rates.
I suspect some high number of confidence interval iterations might be required.
i'd trim individual names from the dist list, but am not 100% sure who is on netdev...
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||[ANNOUNCE] iproute2-ss050607, Stephen Hemminger|
|Next by Date:||Re: RFC: NAPI packet weighting patch, Jesse Brandeburg|
|Previous by Thread:||Re: RFC: NAPI packet weighting patch, Robert Olsson|
|Next by Thread:||Re: RFC: NAPI packet weighting patch, David S. Miller|
|Indexes:||[Date] [Thread] [Top] [All Lists]|