03/12/2019 20:56, Ole Troan: > 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.
I agree, of course there are a lot of experience in Cisco! > 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... Thank you for this interesting point of view. I understand and I think it is good to have different choices being implemented and experimented in various Open Source softwares. In order to motivate others to experiment the opposite, i.e. implementing dataplanes with aggressive device offloads, I think it is good to advertise clearly the VPP design choices. > 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? > ;-) Good point, this is all about use cases and trade-off.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14790): https://lists.fd.io/g/vpp-dev/message/14790 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] -=-=-=-=-=-=-=-=-=-=-=-
