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