Andy [[email protected]] wrote: > > I appreciate that you may be frustrated by the existence of bad advice > on the internet. And as someone who is continually learning and only > wants to do things right, could you instead of saying that he's an > idiot who knows nothing, please provide some constructive examples of > what sort of things cal**** have got wrong so we can all learn? > I cannot see anything that stands out as bad advice but I appreciate > their must be otherwise you wouldn't say that. >
The buffer cache, UDP and TCP are all relative to applications that run on your box. They have absolutely no effect on forwarded traffic. kern.bufcachepercent=75 net.inet.udp.recvspace=131072 net.inet.udp.sendspace=131072 net.inet.tcp.mssdflt=1460 net.inet.tcp.rfc3390=1 This is the only setting that could actually help: net.inet.ip.ifq.maxlen=1536 (The default queue size can be too small in a high pps situation.) > I was asking about the ToE offloading etc in the hope that it might > help a little bit to bring our interrupt CPU utilisation down, without > better knowledge of the OBSD net stack internals. I changed the network > card from an old legacy interrupt style card to a new Intel ET2 which > uses the MSI (message signalled interrupts) style, but this made no > improvement to the maximum throughput. > I'd bet that all your NICs support MSI anyways. The advantage of MSI in OpenBSD is that you avoid using shared interrupts on i386/amd64. ToE offloading isn't supported by OpenBSD, and even if it was, it would not help you. You are forwarding packets, the TCP sessions are dealt with by the endpoints, not the packet forwarder.... ToE is mainly useful for iscsi. > Regarding the missed step, I don't know which diagnostics/stats to > provide here in the hope of some help. What would be most useful? > Is there a way of seeing what the interrupts are doing in more detail? > systat shows I'm currently running on average 24k interrupts overall > for 85% interrupt utilisation (~500Mbit). > 'systat vm 1' can show you which driver is taking the interrupts, but we already likely know that it's your NIC creating these interrupts
