On 7/15/21 7:43 PM, Stokes, Ian wrote: >> Hi. As described in Documentation/internals/release-process.rst, we are >> in a "soft freeze" state: >> >> During the freeze, we ask committers to refrain from applying patches that >> add new features unless those patches were already being publicly >> discussed >> and reviewed before the freeze began. Bug fixes are welcome at any time. >> Please propose and discuss exceptions on ovs-dev. >> >> We should branch for version 2.16 in two weeks from now, on Friday, July 16. >> >> Current known exception that will likely be accepted during soft-freeze, but >> not prepared/reviewed yet: >> - We're awaiting patches to fix performance issue in VXLAN decap offloading >> implementation in userspace datapath, but this is more a bug fix than a >> new feature. >> > Hi Ilya,
Hi, Ian. > > With branching for 2.16 being planned tomorrow, the other exceptions that I > am aware of are as follows > > MFEX Optimiziation (v14 sent, awaiting ACK on minor rework) > RXQ Scheduling (Acked by RH and Intel already) > dpdk: Logs to announce removal of defaults for socket-mem and limit. These are not really exceptions for a "soft freeze" stage, because they were submitted and discussed/reviewed before the soft freeze was announced. But for the branching, I would be better to have all features (actual code changes) to be merged before the creation of a branch-2.16, which I plan to do tomorrow at the end of a day. Or do you expect these patches to not be merged before branching? > > Is there anything else on your side that you are aware that is in a position > to be applied? Form my side I'm going to merge OVSDB Relay patch-set, as it was reviewed and tested. Another big change is "dpif-netlink: Introduce per-cpu upcall dispatching" it's reviewed and tested by Flavio, Aaron is also reviewing. Kernel code is reviewed by Flavio, Pravin had only couple of small comments. We're expecting kernel part be accepted as soon as net-next is open (next week?), unfortunately this will be after branching, but taking into account that there were no objections during review and the backward compatibility of the feature, it should be fine to accept userspace parts sooner. I'm tracking this. And there is a bunch of small changes/features that was reviewed and tested for long time already. So, I'm going to look through them and apply ones that are in a good shape, e.g.: - https://patchwork.ozlabs.org/project/openvswitch/patch/[email protected]/ - https://patchwork.ozlabs.org/project/openvswitch/patch/[email protected]/ - https://patchwork.ozlabs.org/project/openvswitch/patch/[email protected]/ Would be great if you can proof-read/review the "bring your own lab" documentation update from Aaron: https://patchwork.ozlabs.org/project/openvswitch/patch/[email protected]/ We discussed previously the "direct output optimization" patch, but I don't think we have enough time now for another round of reviews and thorough testing. This will go to the next release. BTW, I'm still waiting for comments on it regarding integration into AVX512 code. Some testing also would be great, but it, likely, needs rebase now. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
