There are multiple next-net-brcm branches at https://git.dpdk.org/next/dpdk-next-net-brcm/. I have chosen the for-next-net branch. Let me know if I should adjust.

So, you can go to https://lab.dpdk.org/results/dashboard/periodic_testing/ and select the "showing branch" dropdown on the right and select "next-net-brcm-for-next-net"

I kicked off a run from that branch so it should populate a new set of results within a couple hours. Then like I said a new run of that branch will kick off every 48 hours. 

Good luck!

On Wed, Oct 22, 2025 at 8:09 PM Ajit Khaparde <ajit.khaparde@broadcom.com> wrote:
On Wed, Oct 22, 2025 at 4:52 PM Patrick Robb <probb@iol.unh.edu> wrote:
>
> That solution also makes sense.
Agree. Thanks Thomas.

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

Yes, Patrick, this should work.

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