https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240944
--- Comment #24 from Adrian Chadd <[email protected]> --- Ok, this is where it stops being a driver thing and starts being a network stack thing. At least for e1000/igb/ixgbe LRO isn't a driver/hardware supported thing, it's "just" leaning on packet RSS/hashid mapping flows into queues and then net/netinet code (net/iflib.c, netinet/tcp_lro.c) is doing the batching and such. I never liked how it kind of was shoehorned on the side of the packet processing path to improve cache/hotpath behaviour for the TCP stack. I get it, but it's very specific to that. Can we verify that the initial issue in the task (the locking up, crash, etc) is fixed? I have plenty of e1000/igb/ixgbe hardware here - my downstairs gateway is using igb/em NICs in a bridge group! - and I'd like to create a separate task to reproduce and properly deep dive into where and why LRO is failing here and then run it by the network/transport stack folks so they can eyeball it. (I don't mind suggesting them hacks like "ip forwarding is enabled, no LRO" and "you can't add an interface to a bridge group if it has LRO enabled" as enforced workarounds, but I first want to just get everyone on the same page here.) Thanks! -- You are receiving this mail because: You are the assignee for the bug.
