On Wed, Aug 02, 2017 at 11:23:06AM -0400, Aaron Conole wrote: > Ilya Maximets <[email protected]> writes: > > > 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. > > > >> Please let me know if something else is approved but missed ? > >> Anything else ? > >> > >> Thanks Darrell > > > > > > In addition I have a few general thoughts about merging via pull requests: > > > > 1. There is a requirement described in contribution guide that submitter > > must sign-off the patch. But merges on github doesn't work this way. > > So, the patches should be cherry-picked with footer modifications by > > submitter or contribution guide should be fixed to reflect pull > > request workflow. I understand that authorship of the merge commit can > > replace the sign-off somehow, but it's not so easy sometimes to find > > the corresponding merge commit for particular change. And this still > > doesn't mean that submitter agree with Developer's Certificate of Origin. > > > 2. I'm a fan of plain git history. Could we use 'Rebase and merge' policy > > without merge commits ? > > https://github.com/blog/2243-rebase-and-merge-pull-requests > > I would assume that the pull requests for this would be done similar to > how git pull requests are done in linux kernel. IE: Darrell will run > something like: > > $ git request-pull commit-sha https://github.com/darball/ovs/ > > and send the resulting email to ovs-dev and someone (such as Ben, > Justin, or Joe) will do a fetch + whatever merge strategy is specified. > > Is this not the way it was intended?
That's what I had in mind. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
