bb53d84843
Client drivers may use either legacy flags, for example, EFX_RX_HASH_TCPIPV4, or generalised flags, for example, EFX_RX_HASH(IPV4_TCP, 4TUPLE), to configure RSS hash. The libefx is able to recognise what scheme is used. Legacy flags may be consumed directly by a chip-specific handler to configure the NIC, that is, on EF10, these flags can be used to fill in legacy RSS mode field in MCDI request. Generalised flags can also be directly used in EF10-specific handler as they are fully compatible with additional fields of the same MCDI request. Legacy flags undergo conversion to generalised flags before they are consumed by a chip-specific handler. This conversion is used to make sure that chip-specific handlers expect only generalised flags in the input for the sake of clarity of the code. Depending on firmware capabilities, a chip-specififc handler either supplies the input to the NIC directly, for example, EFX_RX_HASH(IPV4_TCP, 4TUPLE) flag will enable 4 bits in RSS_CONTEXT_SET_FLAGS_IN_TCP_IPV4_RSS_MODE field on EF10, or takes the opportunity to translate the input to enable bits which don't map to the generic flag, like setting RSS_CONTEXT_SET_FLAGS_IN_TOEPLITZ_TCPV4_EN on EF10 when the firmware claims no support for additional modes. However, this approach has introduced a severe problem which can be reproduced with ultra-low-latency firmware variant. In order to enable IP hash, EF10-specific handler requires the user to request 2-tuple hash for IP-other, TCP and UDP traffic classes, unconditionally. In example, IPv4 hash can be enabled using the following input: EFX_RX_HASH(IPV4_TCP, 2TUPLE) | EFX_RX_HASH(IPV4_UDP, 2TUPLE) | EFX_RX_HASH(IPV4, 2TUPLE). At the same time, on ultra-low-latency firmware, the common code will never report support for any UDP tuple to the client driver. That is, in the same example, the driver will use EFX_RX_HASH(IPV4_TCP, 2TUPLE) | EFX_RX_HASH(IPV4, 2TUPLE). This input will not be recognised by EF10-specific handler, and RSS_CONTEXT_SET_FLAGS_IN_TOEPLITZ_IPV4_EN bit will not be set in the MCDI request. In order to solve the problem, the patch removes conversion code from chip-specific handlers and adds appropriate code to convert EFX_RX_HASH() flags to their legacy counterparts to the common scale mode set function. If the firmware does not support additional modes, the function will convert generalised flags to legacy flags correctly without any demand for UDP flags and pass the result to a chip-specific handler. Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com> |
||
|---|---|---|
| app | ||
| buildtools | ||
| config | ||
| devtools | ||
| doc | ||
| drivers | ||
| examples | ||
| kernel | ||
| lib | ||
| license | ||
| mk | ||
| pkg | ||
| test | ||
| usertools | ||
| .gitattributes | ||
| .gitignore | ||
| GNUmakefile | ||
| MAINTAINERS | ||
| Makefile | ||
| meson_options.txt | ||
| meson.build | ||
| README | ||
DPDK is a set of libraries and drivers for fast packet processing. It supports many processor architectures and both FreeBSD and Linux. The DPDK uses the Open Source BSD-3-Clause license for the core libraries and drivers. The kernel components are GPL-2.0 licensed. Please check the doc directory for release notes, API documentation, and sample application information. For questions and usage discussions, subscribe to: users@dpdk.org Report bugs and issues to the development mailing list: dev@dpdk.org