From: Kevin Traynor <ktraynor@redhat.com>
To: Luca Boccassi <bluca@debian.org>
Cc: Shani Peretz <shperetz@nvidia.com>,
stable@dpdk.org, dev@dpdk.org, Robin Jarry <rjarry@redhat.com>,
David Marchand <david.marchand@redhat.com>,
Thomas Monjalon <thomas@monjalon.net>
Subject: Re: 23.11.7 patches review and test
Date: Fri, 15 May 2026 17:03:32 +0100 [thread overview]
Message-ID: <6f3be520-fb42-45d3-b5af-d86d7cb7669f@redhat.com> (raw)
In-Reply-To: <CAMw=ZnSLnz8uxwPJgZThKUm4fpsge_dvb8+o4grBeNYYsmuBMw@mail.gmail.com>
On 5/15/26 1:36 PM, Luca Boccassi wrote:
> On Fri, 15 May 2026 at 11:32, Kevin Traynor <ktraynor@redhat.com> wrote:
>>
>> On 4/30/26 12:02 PM, Kevin Traynor wrote:
>>> On 4/30/26 10:58 AM, Thomas Monjalon wrote:
>>>> 30/04/2026 11:32, Kevin Traynor:
>>>>> On 4/21/26 7:46 AM, Shani Peretz wrote:
>>>>>> The planned date for the final release is 30 April 2026.
>>>>>
>>>>> As discussed on thread [0] there was a quite serious regression caused
>>>>> by "net: fix packet type for stacked VLAN"
>>>>>
>>>>> As discussion on the fix is ongoing, I would suggest to just revert this
>>>>> patch for your release.
>>>>
>>>> I agree the revert is the best option here.
>>>>
>>>>> It doesn't require a new RC and re-validation as it's an isolated issue
>>>>> (and there wasn't test cases to catch before Robin's new patch anyway)
>>>>
>>>> I suppose 24.11.5 and 25.11.1 are also impacted?
>>>>
>>>>
>>>
>>> Yes, I was hoping we would have a fix in a few days and we could add and
>>> re-release. Given that there's now discussion on the patch and what
>>> functionality is needed, it's probably best to just revert and release a
>>> new 24.11/25.11.
>>
>> Hi Luca. Are you planning to do a 24.11 release with revert for above
>> issue ? If you have a time issue, let me know and I can help out.
>
> Hi, is it strictly necessary? Could it wait for the next one?
>
It's a user visible regression from the previous release that impacts
tap device with VLAN, causing good packets to be discarded. It's also
visible to any application using the net API in a similar way. Given the
effort is low as it's just a revert and we don't need validation teams
involved, then I think it's worthwhile.
prev parent reply other threads:[~2026-05-15 16:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-21 6:46 23.11.7 patches review and test Shani Peretz
2026-04-29 17:57 ` Ali Alnubani
2026-05-05 16:05 ` Shani Peretz
2026-04-30 1:29 ` Xu, HailinX
2026-05-05 16:05 ` Shani Peretz
2026-04-30 9:32 ` Kevin Traynor
2026-04-30 9:58 ` Thomas Monjalon
2026-04-30 10:02 ` Kevin Traynor
2026-05-15 10:31 ` Kevin Traynor
2026-05-15 12:36 ` Luca Boccassi
2026-05-15 16:03 ` Kevin Traynor [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6f3be520-fb42-45d3-b5af-d86d7cb7669f@redhat.com \
--to=ktraynor@redhat.com \
--cc=bluca@debian.org \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=rjarry@redhat.com \
--cc=shperetz@nvidia.com \
--cc=stable@dpdk.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.