On Wed, Feb 3, 2016 at 9:31 AM, Sowmini Varadhan <sowmini.varad...@oracle.com> wrote: > On (02/03/16 09:07), Tom Herbert wrote: >> > Kernel unaligned access at TPC[9150dc] ipv4_neigh_lookup+0x38/0x170 >> >> Sowmini, >> >> This doesn't look like a hard crash to me. Instead of trying to fix >> all the alignment issues for Sparc, can we just take the trap, fix up >> the load, and continue without any further fuss? Performance might >> suffer, but it doesn't seem like the bad alignments are happening in >> critical paths. >> > > None of these things is a hard crash, but they are > > (a) quite noisy
Try disabling the crash dump. That will improve performance. > (b) I'm able to generate alignment falls merely by configuring > tunnels, and it gets worse when I disable RSS and use RFS/RPS > instead. So "critical path" might need some definition. But as we said it's only for tunnels that specifically encapsulate an ethernet header with aligning it. Many other encapsulations (e.g. IPIP, GUE, EtherIP,IP/GRE) should be fine. We could take this to IETF and point out that alignment is still relevant in protocol development. We can't fix this for GRE or VXLAN at this point, but maybe there's still hope for VXLAN-GPE or Geneve... > (c) a perf risk for other platforms as well, even when they dont > complain noisily about it. > Right, but there is a big difference between a performance degradation and a hard failure. It would at least be nice to know what the performance hit actually is, if it's acceptable then this would be a far simpler and much less invasive fix than the alternatives. Thanks, Tom > --Sowmini
