[ovs-dev] OVS "soft freeze" for 2.16 is in effect.

[Stokes, Ian]

> 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?
> 

I was hoping to merge tomorrow, MFEX has received required acks for patches (although I'd like to receive an additional ack on one of the patches from one of the reviewers, hopefully tomorrow morning).

I'm finishing some testing on the RXQ scheduling but again should be finished by tomorrow before EOD.


> >
> > 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/20210701181933.944
> 0-2-twilson at redhat.com/
> -
> https://patchwork.ozlabs.org/project/openvswitch/patch/20210416120631.458
> 4-1-david.marchand at redhat.com/
> -
> https://patchwork.ozlabs.org/project/openvswitch/patch/20210629204339.397
> 58-1-vdasari at gmail.com/
> 
> Would be great if you can proof-read/review the "bring your own lab"
> documentation update from Aaron:
> 

Will do.

> https://patchwork.ozlabs.org/project/openvswitch/patch/20210628180028.581
> 283-1-aconole at redhat.com/
> 
> 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.
+1

Thanks
Ian
> 
> Best regards, Ilya Maximets.