On 16 Jan 2023, at 14:05, Ilya Maximets wrote:
> On 1/12/23 20:38, Dumitru Ceara wrote: >> On 1/12/23 19:13, Han Zhou wrote: >>> On Mon, Jan 2, 2023 at 3:08 PM Ilya Maximets <i.maxim...@ovn.org> 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 3.1 in two weeks from now, on Monday, Jan 16. >>>> With that, release should be on Thursday, Feb 16. >>>> >>>> Best regards, Ilya Maximets. >>>> _______________________________________________ >>>> dev mailing list >>>> d...@openvswitch.org >>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >>> >>> Hi Ilya, >>> >>> Here is a list of patches I'd like to bring to your attention: >>> >>> * https://patchwork.ozlabs.org/project/openvswitch/list/?series=336342 >>> This series is new, but it provides an IDL API to avoid a problem, so it >>> falls in between "bug fixes" and "new features". Please see if it can be >>> included in the release. >>> >> >> It would be nice indeed if this could make it into 3.1. It's contained >> enough and only changes behavior when explicitly requested. On the >> other hand it solves the (benign) error message that often raises questions. > > OK. Added this to my queue. > >> >>> * https://patchwork.ozlabs.org/project/openvswitch/list/?series=313042 >>> This series was posted in Aug. We have been using it downstream since then. >>> There was feedback from Adrian and he agreed with the first patch, so >>> hopefully at least this one can catch the release. > > There is an ongoing discussion about the issue here: > https://patchwork.ozlabs.org/project/openvswitch/patch/167274555298.379205.1390528419336184506.stgit@ebuild/ > > The issue is that the mechanism of removing flows without revalidation > should not kick in in the first place. We need more data on where and > why exactly revalidator threads are getting stuck. I'm not comfortable > applying workarounds without RCA. > >>> For the second patch, Adrian mentioned about a patch came later that is >>> related. Both patches are useful but it would be better to be aligned with >>> each other for the counter names. Could you suggest how to proceed with it? > > I would suggest asking Eelco for review on this patch. I agree that > coverage counters are orthogonal to USDT probes. If necessary, we > could get them after branching as there are no changes in the logic > and the patch is very simple. But, yes, we need to agree on naming. > I hope, Eelco and Adrian can help with that. Replied to the patches. I think the first patch might need some documentation to describe the 0 value. The second patch would be nice if it could be aligned with Kevin’s. However, I do not think Kevin will address his patch in the 3.1 timeframe, maybe we can take the code changes only, and not his script, and then Han can add coverage counters based on that patch? >>> * https://patchwork.ozlabs.org/project/openvswitch/list/?series=312997 >>> This one was also posted in Aug. The first patch got an ACK, and the second >>> one is still waiting for feedback. Could you comment on it, too? > > We can get this as a bug fix later, as it seems to be a bug fix more > than a new feature. But I had no chance to properly review it. > > Best regards, Ilya Maximets. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
