On Sun, 3 Jul 2022 20:38:21 +0100 Konstantin Ananyev <konstantin.v.anan...@yandex.ru> wrote:
> > > > The base/existing design for DPDK was done with one particular HW > > architecture in mind where there was an abundance of resources. > > Unfortunately, that HW architecture is fast evolving and DPDK is adopted in > > use cases where that kind of resources are not available. For ex: > > efficiency cores are being introduced by every CPU vendor now. Soon enough, > > we will see big-little architecture in networking as well. The existing PMD > > design introduces 512B of stores (256B for copying to stack variable and > > 256B to store lcore cache) and 256B load/store on RX side every 32 packets > > back to back. It doesn't make sense to have that kind of memcopy for > > little/efficiency cores just for the driver code. > > I don't object about specific use-case optimizations. > Specially if the use-case is a common one. > But I think such changes has to be transparent to the user as > much as possible and shouldn't cause further DPDK code fragmentation > (new CONFIG options, etc.). > I understand that it is not always possible, but for pure SW based > optimizations, I think it is a reasonable expectation. Great discussion. Also, if you look back at the mailing list history, you can see that lots of users just use DPDK because it is "go fast" secret sauce and have not understanding of the internals. My concern, is that if one untestable optimization goes in for one hardware platform then users will enable it all the time thinking it makes any and all uses cases faster. Try explaining to a Linux user that the real-time kernel is *not* faster than the normal kernel...
