The other day I was running the stock fedora kernel on my ip
forwarding setup, to see what the performance was, and the performance
wasn't very good.
system is S5520HC dual socket 2.93GHz Xeon 5570 (Nehalem) with 3 quad
port 82580 adapters (12 ports). Traffic is bidirectional 64 byte
packets being forwarded and received on each port, basically port to
port routing. I am only using 12 flows currently.
The driver is igb, and I am using an affinity script that lines up
each pair of ports that are forwarding traffic into optimal
configurations for cache locality. I am also disabling
remote_node_defrag_ratio to stop cross node traffic.
With the fedora default kernel from F14 it appears that
CONFIG_NETFILTER=y means that I cannot unload all of netfilter even if
I stop iptables service.
perf showed netfilter being prominent, and removing it gives me much
higher throughput. Is there a reason CONFIG_NETFILTER=y ? Isn't it a
good thing to be able to disable netfilter if you want to?
Intel recomends to include those two patches in Fedora.
Emmanuel Grumbach (2):
iwlwifi: pcie: fix race in queue unmapping
iwlwifi: pcie: wake the queue if stopped when being unmapped
drivers/net/wireless/iwlwifi/pcie/tx.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
Hello kernel list,
as mentioned on the Frenoode IRC channel I would like to ask to have
some backported (from 3.10) patches to be included in the Fedora 19
These patches are needed to fully complete the server side part of
I am sorry coming late, but this work has been underway for very long
(patches originally against 3.9.0) and I did not realize it wasn't going
to end up in Fedora 19 kernel without proactive action until now.
The patches are quite self-contained and tested.
Bruce has kindly agree to backport them to 3.9.x (and we do not expect
major difficulties there) and Jeff has agreed to review the backport.
The list of upstream patches is the following:
030d794bf498 SUNRPC: Use gssproxy upcall for server RPCGSS
1d658336b05f SUNRPC: Add RPC based upcall mechanism for RPCGSS auth
400f26b542e8 SUNRPC: conditionally return endtime from
33d90ac0581c SUNRPC: allow disabling idle timeout
7073ea8799a8 SUNRPC: attempt AF_LOCAL connect on setup
d28fcc830c2e svcrpc: fix gss-proxy to respect user namespaces
6278b62aa8f9 SUNRPC: gssp_procedures can be static
9fd40c5a66be SUNRPC: Refactor gssx_dec_option_array() to kill
fb43f11c666a SUNRPC: fix decoding of optional gss-proxy xdr fields
625cdd78d119 svcauth_gss: fix error code in use_gss_proxy()
Please let me know if more information is needed, and what is the
deadline, should you accept the proposal to have this included.
Please keep me in CC as I am not subscribed to the list.
Simo Sorce * Red Hat, Inc * New York
Someone, do you know what is in deep "TCP Application Buffer"? I'll want
tuning my system but i'm reading on the web, that when i modify this
in particular, this:
tcp_app_win - INTEGER
Reserve max(window/2^tcp_app_win, mss) of window for application buffer.
Value 0 is special, it means that nothing is reserved.
But unfortunatly, i don't know what is "application buffer". Someone can
Thanks a lot in advance.
Here is a patch for the kernel.spec, which changes the version of kernel
flavor/variants to end in "-$flavor" instead of ".$flavor". This change makes it
easier to detect a flavor and a parser can separate it from the architecture.
With that change we can correct kernel-install (of systemd) to call
new-kernel-package with --package kernel-$flavor, because the $flavor can easily
be extracted from the version string.
Another solution would be to name the default kernel to have a flavor "default"
like SUSE does, but this does not look nice.
Another solution would be a hardcoded list of flavors in kernel-install.
The last solution would be to add a flavor argument to kernel-install, which has
no purpose other than to pass it through to new-kernel-package.