[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+FuTSdFbCuUy5YJOjST54qZpnrxJGdQD5M8y3nsw453L+o62g@mail.gmail.com>
Date: Fri, 19 Aug 2011 15:50:55 -0400
From: Will de Bruijn <willemb@...gle.com>
To: Ben Hutchings <bhutchings@...arflare.com>
Cc: Rick Jones <rick.jones2@...com>, Tom Herbert <therbert@...gle.com>,
rdunlap@...otime.net, linux-doc@...r.kernel.org,
davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH] net: add Documentation/networking/scaling.txt
> As I'm sure you're aware, there is often a trade-off between throughput
> and latency. It might be useful to provide some guidelines for
> optimising each of the above.
The suggested configuration section on RSS already gives some vague
heuristics. In general, I hesitate to write down best guesses, and I
lack the hard experimental data that would make such advise more
sound.
> The default affinity for most IRQs is all-CPUs. At least on x86, that
> really means CPU 0 only, so far as I can see.
Yes, I believe so, but since the specified behavior is all-CPUs and
other architectures are free to implement this differently, I prefer
to leave the weaker statement. Also, even on x86 there is the
possibility of migration, so starting on CPU0 is not equivalent to
having the affinity set to that CPU.
>> Requires that ntuple filtering be enabled?
> [...]
>
> As a matter of fact, n-tuple filtering is enabled by default where
> available. So it might actually make more sense to say that RFS
> acceleration can be *disabled* by disabling n-tuple filtering using
> ethtool.
I didn't know (or check, clearly). I'll clarify that in a next
revision. Since the text is still factually correct and I don't want
to spam the list with frequent minor changes, I'll batch them.
Thanks, Ben.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists