On 10/13/2016 08:02 AM, Wang, Zhihong wrote: >> > Yes, that's great effort! With your hardwork, we know what the bottleneck >> > is and how it could be improved. >> > >> > However, you don't have to do code refactor (merge two code path to one) >> > to apply those improvements. From what I know, in this patchset, there >> > are two factors could improve the performance: >> > >> > - copy hdr together with packet data >> > >> > - shadow used ring update and update at once >> > >> > The overall performance boost I got with your v6 patchset with mrg-Rx >> > code path is about 27% (in PVP case). And I have just applied the 1st >> > optimization, it yields about 20% boosts. The left could be covered if >> > we apply the 2nd optimization (I guess). >> > >> > That would be a clean way to optimize vhost mergeable Rx path: >> > >> > - you don't touch non-mrg Rx path (well, you may could apply the >> > shadow_used_ring trick to it as wel) >> > >> > This would at least make sure we will have no such performance >> > regression issue reported by ARM guys. >> > >> > - you don't refactor the code >> > >> > The rewrite from scratch could introduce other issues, besides the >> > performance regression. We may just don't know it yet. >> > >> > >> > Make sense to you? If you agree, I think we could still make it in >> > this release: they would be some small changes after all. For example, >> > below is the patch applies the 1st optimization tip on top of >> > dpdk-next-virtio > > Thanks for this great idea. I think it's a better way to do it. > I'll start to make the patch then. > >
I personally find having two paths better for maintenance as it is easier to understand (IMHO). So if we can have the performance gain while keeping the two paths, I definitely support the idea. Thanks, Maxime