Interesting discussion. > Yes it is possible to use DPDK in VPP with degraded performance. > If an user wants best performance with VPP and a real NIC, > a new driver must be implemented for VPP only. > > Anyway real performance benefits are in hardware device offloads > which will be hard to implement in VPP native drivers. > Support (investment) would be needed from vendors to make it happen. > About offloads, VPP is not using crypto or compression drivers > that DPDK provides (plus regex coming). > > VPP is a CPU-based packet processing software. > If users want to leverage hardware device offloads, > a truly DPDK-based software is required. > If I understand well your replies, such software cannot be VPP.
I don't think that we are principled against having features run on the NIC as such. VPP is a framework for building forwarding applications. That often implies doing lots of funky stuff with packets. And more often than we like hardware offload creates problems. Be it architecturally with layer violations like GSO/GRO. Correct handling of IPv6 extension headers, fragments. Dealing with various encaps and tunnels. Or doing symmetric RSS on two sides of a NAT. Or even other transport protocols than TCP/UDP. And it's not like there is any consistency across NICs: http://doc.dpdk.org/guides/nics/overview.html#id1 We don't want VPP to only support DPDK drivers. It's of course a tradeoff, and it's not like we don't have experience with hardware to do packet forwarding. At least in my own experience, as soon as you want to have features running in hardware, you loose a lot of flexiblity and agility. That's just the name of that game. Living under the yoke of hardware limitations is something I've tried to escape for 20 years. I'm probably not alone, and that's why you are seeing some pushback... VPP performance for the core features is largely bound by PCI-e bandwidth (with all caveats coming with that statement obviously). It's not like that type of platform is going to grow a terabit switching fabric any time soon... Software forwarding lags probable a decade and an order of magnitude. That it makes up for in agility, flexiblity, scale... If you don't want that, wouldn't you just build something with a Trident 4? ;-) Best regards, Ole
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14773): https://lists.fd.io/g/vpp-dev/message/14773 Mute This Topic: https://lists.fd.io/mt/65218320/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
