On Thu, Aug 24, 2023 at 2:24 PM Ilya Maximets <[email protected]> wrote: > On 8/22/23 12:26, Eelco Chaudron wrote: > > On 22 Aug 2023, at 11:28, David Marchand wrote: > > > >> Following support of L3 and L4 checksum offloading, some bugs have been > >> raised in different DPDK drivers. > > > > So to clarify this a bit more we see issues with OVS 3.2 and the i40e vf > > driver and net/tap driver.
The first issue is in the net/iavf DPDK driver, so I expect it affects both Intel 700 series (i40e) and 800 series (ice) VF devices. > > > > Mike can you take a look at this patch? Also, Ilya what do you feel would > > be the right approach to move this forward for OVS3.2? > > The release cycle for DPDK stable releases is very unfortunate. Well, it's unfortunate OVS did not see it sooner. It is hard for me to ask and get (freshly cooked) DPDK fixes in the (about to be released) 22.11.3 version. > IIUC, we will see the driver fixes only somewhere in December, right? It depends on the validation task, but usually yes, we have new LTS releases at the end of December. > > Under these circumstances, I think, it's OK to introduce a knob, > so users can disable offloading. > > Hwoever, > > a) I'd suggest we do not provide a fine grained control over this > and go with a simple on/off switch. We may introduce even more > issues if we allow users to selectively enable/disable particular > parts, as these parts may technically depend on each other and > there is an even higher chance for driver bugs. Just to draw a parallel, offloads can be controlled with ethtool for a kernel netdev. My proposal had in mind that bugs can get introduced in drivers and being able to on/off some offload for troubleshooting is handy. > > b) IIUC, the only problematic driver we know of today is net/tap. > Disabling offloads will not help net/iavf driver, we'll have to > clear flags for it with the other patch anyway. > So, as an alternative, we can check the driver name and disable > offloads for net/tap specifically, until the new DPDK stable > release is out. > > I'm more in favor of b), because it provides a working experience > out of the box for the net/tap. But we could have both. b) has the advantage of being backportable in 3.2 with a risk focused on net/tap. I am fine with the b) approach. > > Thoughts? > > > > > Cheers, > > > > Eelco > > > >> When faced with such bugs, a OVS user can't do anything but wait for a > >> DPDK fix (which can take some time to make it to the LTS releases). > >> > >> Make it possible for the user to disable some Tx offloads. > >> > >> Link: > >> https://patchwork.dpdk.org/project/dpdk/patch/[email protected]/ > >> Link: > >> https://patchwork.dpdk.org/project/dpdk/patch/[email protected]/ > >> Signed-off-by: David Marchand <[email protected]> > >> --- > >> lib/netdev-provider.h | 5 ++- > >> lib/netdev.c | 72 +++++++++++++++++++++++++++++++++++++------ > >> tests/dpif-netdev.at | 10 ++++++ > >> 3 files changed, 76 insertions(+), 11 deletions(-) > >> > >> diff --git a/lib/netdev-provider.h b/lib/netdev-provider.h > >> index a7393c7cec..32a760d826 100644 > >> --- a/lib/netdev-provider.h > >> +++ b/lib/netdev-provider.h > >> @@ -59,9 +59,12 @@ struct netdev { > >> * opening this device, and therefore got assigned to the "system" > >> class */ > >> bool auto_classified; > >> > >> - /* This bitmask of the offloading features enabled by the netdev. */ > >> + /* Bitmask of the offloading features supported by the netdev. */ > >> uint64_t ol_flags; > >> > >> + /* Bitmask of the offloading features disabled by the user. */ > >> + uint64_t disabled_ol_flags; > > This has to be atomic, because it is changed not only on reconfiguration, > but also while forwarding is running. Which will be unneeded if we simply filter checksums support for net/tap at device init. -- David Marchand _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
