>> Hi Darrell and Ben. >> >> > Hi All >> > >> > As mentioned before, I am using a repo for DPDK patch merging. >> > The repo is here: >> > https://github.com/darball/ovs/ >> > >> > There are still some outstanding patches from Bhanu that have not >> completed review yet: >> > >> > util: Add PADDED_MEMBERS_CACHELINE_MARKER macro to mark >cachelines.- >> > Bhanu >> > packets: Reorganize the pkt_metadata structure. - Bhanu >> > >> > and a series we would like to get into 2.8 >> > >> > netdev-dpdk: Use intermediate queue during packet transmission. >> > Bhanu Jun 29/V3 >> > netdev: Add netdev_txq_flush function. >> > netdev-dpdk: Add netdev_dpdk_txq_flush function. >> > netdev-dpdk: Add netdev_dpdk_vhost_txq_flush function. >> > netdev-dpdk: Add intermediate queue support. >> > netdev-dpdk: Enable intermediate queue for vHost User port. >> > dpif-netdev: Flush the packets in intermediate queue. >> >> I think that we still not reached agreement about the level of >> implementation (netdev-dpdk or dpif-netdev). Just few people >> participate in discussion which is not very productive. I suggest not >> to target output batching for 2.8 release because of this and also >> lack of testing and review. >> As I understand, we have only 3 days merge window for the new features >> and I expect that we can't finish discussion, review and testing in time. >> > >My own opinion on this, this feature has been kicking around for quite a >while, the original patch from Bhanu went out back in December. >https://mail.openvswitch.org/pipermail/ovs-dev/2016- >December/326348.html
Unfortunately it dates back to Aug 2016 and almost been an year. (Refer: https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/321748.html) I reported this issue and copied Ilya (original author) whose commit "b59cc14e032d (netdev-dpdk: Use instant sending instead of queueing of packets" introduced this particular issue in 2.6. Unfortunately the author who introduced this issue didn't respond to that question and we came up with the path series to address this. Multiple RFC versions were posted and even Ilya participated in reviews and provided feedback. It's unacceptable now to say that this patch series hasn't been reviewed enough. Lot of time has been invested on this feature especially for rebasing, testing, collecting latency stats and promptly replying to all the questions on ML. > >There's a level of due diligence carried out in terms of reviewing and testing >from a range of people in the community for the netdev approach and a >number of users are already using this without issue. As such I would like this >approach to be included in the 2.8 release. As Ian rightly pointed, we know of few internal and external customers already having this patch series with incremental changes and running in their deployments. There may always be few corner cases and those can be addressed and this shouldn't be a concern to get this in to 2.8 series. > >I think the dpif layer is more generic and in the long run more maintainable >but it was quite late in being flagged as an alternate approach and is not as >mature in terms of testing/reviews. As such I don't think it should block the >netdev approach until it has reached the same level of feedback and testing >from the community. The dpif approach could target the 2.9 release after it >has received more feedback and replace the netdev approach when the pros >and cons of both have been clearly demonstrated. This has been discussed and each approach has its own merits and demerits. Darrel already had put his views in other threads. - Bhanuprakash. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
