Hi, We would like your opinions on the following observations, regarding the 82599 Flow Director support.
Issue #1: Our reading of the 82599 data sheet leads us to believe that Flow Director can simultaneously handle *both* IPv4 and IPv6 filters, with separate filter rules, of course. Thus, at the bottom of ixgbe_fdir.c:fdir_set_input_mask_82599( ), we could remove the "if (!input_mask->set_ipv6_mask)" / "else" around the setting of FDIRSIP4M, FDIRDIP4M, and FDIRIP6M. (This would also eliminate the need for the set_ipv6_masks flag itself.) We performed limited testing on this change. We have successfully added both IPv4 and IPv6 signature filters, but so far have only exercised them with IPv4 traffic. One would think that the designers of this chip feature envisioned users filtering mixed traffic (both IPv4 and IPv6). Issue #2: Apparently, API rte_eth_dev_fdir_set_masks( ) expects IPv4 address and port masks in host-byte-order (little-endian), while rte_eth_dev_fdir_add_signature_filter( ) expects IPv4 addresses and ports in network-byte-order (big-endian). (Contrast the writing into IXGBE_FDIRSIP4M in ixgbe_fdir.c: fdir_set_input_mask_82599( ), versus ixgbe/ixgbe_82599.c: ixgbe_fdir_set_input_mask_82599( ). The former includes an extra IXGBE_NTOHL( ) on the mask's complement.) Not knowing this made it a bit tricky to get signature filters working properly. Perhaps it is too late to change the byte-ordering in the (set masks) API? Whether we change it or not, we probably should at least document these details, to avoid confusion. -- Regards, Robert
