That solution also makes sense.

For the per-branch periodic testing page that Thomas is mentioning (here: https://lab.dpdk.org/results/dashboard/periodic_testing/) we are publishing regular test reports on next-net, but not next-net-brcm. But, it makes sense for us to start periodic runs on next-net-brcm, so I will add this now. It should only take a few minutes to add to our CI system. Then I will do a manual trigger which will add the first periodic testrun for next-net-brcm. Otherwise, it should run once every other day at midnight US eastern time.

Let us know if this solution works for you Ajit. Thanks.

On Wed, Oct 22, 2025 at 7:36 PM Thomas Monjalon <thomas@monjalon.net> wrote:

Hello,

Not related to CI, but the best would be to not wait a year
for updating the driver in one series.

As you maintain a repository branch,
you can merge the patches and wait for UNH CI running on it.
Also the GitHub robot can run if you push in a GitHub repo.

23/10/2025 01:05, Patrick Robb:
> Hi Ajit,
>
> That sounds annoying. A sanity check question to start - is there any sense
> in resubmitting the series and just intentionally delaying sending the 2nd
> half of the commits? I.e.
>
> 1. git send-email /my-patches-dir/*
> 2. Send the first 30
> 3. At prompt for 31st patch, pause.
> 4. wait 10 minutes.
> 5. Return to terminal, send patches 31 through 57.
>
> Or, if this is not possible, I think there should be some solution on the
> patchwork mail server policy side. I think Ali Alnubani from NVIDIA manages
> it and he is usually pretty responsive with such modification requests. We
> could ask about solutions like:
>
> 1. Add a complete exception to the mail server message rate restriction for
> emails coming from email addresses associated with DPDK member companies.
>
> or
>
> 2. Simply make the message rate restrictions more permissive than they are
> currently (i.e. allow 100 emails, not 30).
>
> If the ideas above will not work, I will have to assess the "bundle" idea
> tomorrow when I have time available than I do right now. Most likely it's
> technically possible to facilitate but I do feel like simply resolving the
> original issue (the mail server is not letting you submit your series) and
> allowing the CI system automation to intake the patchseries from patchwork
> in the normal way is the ideal approach.
>
> On Wed, Oct 22, 2025 at 5:39 PM Ajit Khaparde <ajit.khaparde@broadcom.com>
> wrote:
>
> > Hi Patrick,
> > When Manish was submitting his patchset,
> > Looks like because of a mail server message rate restriction,
> > only 31 of 57 patches went through in the first attempt
> >
> > He submitted the remaining patches 32 to 57 in second attempt.
> >
> > I created a bundle for the series now. [1]
> >
> > Also a couple of patches were stuck at the gate.
> > So a proper build has not happened on the patchset yet. [2]
> > Do we have a way to trigger a build on the bundle?
> >
> > Please advise.
> >
> > [1] https://patchwork.dpdk.org/bundle/ajitkhaparde/BNXT%2025.11/
> > [2] https://mails.dpdk.org/archives/test-report/2025-October/921500.html
> >
> > Thanks
> > Ajit