<div dir="ltr">That solution also makes sense.<div> </div><div>For the per-branch periodic testing page that Thomas is mentioning (here: <a href="https://lab.dpdk.org/results/dashboard/periodic_testing/">https://lab.dpdk.org/results/dashboard/periodic_testing/</a>) 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.</div><div> </div><div>Let us know if this solution works for you Ajit. Thanks. </div></div> <div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Oct 22, 2025 at 7:36 PM Thomas Monjalon <<a href="mailto:thomas@monjalon.net">thomas@monjalon.net</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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 <<a href="mailto:ajit.khaparde@broadcom.com" target="_blank">ajit.khaparde@broadcom.com</a>> > 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] <a href="https://patchwork.dpdk.org/bundle/ajitkhaparde/BNXT%2025.11/" rel="noreferrer" target="_blank">https://patchwork.dpdk.org/bundle/ajitkhaparde/BNXT%2025.11/</a> > > [2] <a href="https://mails.dpdk.org/archives/test-report/2025-October/921500.html" rel="noreferrer" target="_blank">https://mails.dpdk.org/archives/test-report/2025-October/921500.html</a> > > > > Thanks > > Ajit </blockquote></div>