On Sat, 25 Jul 2020 09:39:07 -0700 Tom Herbert wrote: > Jakub, > > The fundamental problem we have wrt DPDK is that they are not just > satisfied to just bypass the kernel datapath, they are endeavouring to > bypass the kernel control path as well with things like RTE flow API. > The purpose of this patch set, AFAICT, is to keep the kernel in the > control plane path so that we can maintain one consistent management > view of device resources. The unpleasant alternative is that DPDK will > send control messages directly to the device thereby bypassing the > kernel control plane and thus resulting in two independent entities > managing the same device and forcing a bifurcated control plane in the > device (which of course results in a complete mess!).
Sorry for a late reply. I try to do my best to predict what effect the community pushing back on merging features will have. It does appear that the unpleasant alternative you mention is becoming more and more prevalent. I believe this is a result of multiple factors - convenience of the single point of control, backward/forward compat, the growing size of the driver SW stack, relative SW vs Si development cost in a NIC project, software distribution models.. My day to day experience working with NICs shows that FW has already taken over high perf NICs, and I hate it. I'd take DPDK over closed source FW any time of the day, but I will not fool myself into thinking that expansion of FW control can be stopped by the kernel opening the floodgates to anything the vendors want to throw at us. Ergo the lesser evil argument does not apply. In this case, I'm guessing, Intel can reuse RTE flow -> AQ code written to run on PFs on the special VF. This community has selected switchdev + flower for programming flows. I believe implementing flower offloads would solve your use case, and at the same time be most beneficial to the netdev community.
