On Wed, Oct 22, 2025 at 4:52 PM Patrick Robb 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 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 >> > 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 >> >> >> >>