On Thu, 6 Aug 2026 13:05:49 -0700 Mina Almasry wrote: > Yes the test fails, but it gets past the flow steering configuration problem. > > And in the code, the change looks correct to me. If flow_steer is > False, then we don't pass the -c arg to ncdevmem. ncdevmem is written > so that if -c is not set, 5-tuple flow steering is not possible (the > client side port is random), so it falls back to 3-tuple flow > steering, which doesn't work on GVE or any other driver that supports > only 5-tuple flow steering. > > run_rx (devmem.check_rx test case) doesn't have this problem because > it does `flow_steer=not hasattr(cfg, 'netns')`, but run_rx_hds has > this problem because it forgets to override flow_steer at all. This > patch fixes that. > > To be honest while looking at this there were a few weird things. Like > I'm not sure why the python arg is named `flow_steer` (it likely > should be 5_tuple_flow_steer), and why flow_steer setting is tied to > hasattr(cfg, 'netns'), it should be a proprety of the driver you're > runing on (unless all in-netns drivers will support 3-tuple flow > steering).
Could we clean this up and add explicit test cases for inserting specific rule types? We want the one-sided-tuple format at Meta, falling back silently would be a loss of signal.
