* Re: BNXT patches [not found] <CACZ4nhvBbK1kC8oCwkHRn+Mnov9zXgAwUsKduEc8wO3EXs7huw@mail.gmail.com> @ 2025-10-22 23:05 ` Patrick Robb 2025-10-22 23:36 ` Thomas Monjalon 0 siblings, 1 reply; 5+ messages in thread From: Patrick Robb @ 2025-10-22 23:05 UTC (permalink / raw) To: Ajit Khaparde; +Cc: ci, Ali Alnubani [-- Attachment #1: Type: text/plain, Size: 2088 bytes --] 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 > > [-- Attachment #2: Type: text/html, Size: 4245 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: BNXT patches 2025-10-22 23:05 ` BNXT patches Patrick Robb @ 2025-10-22 23:36 ` Thomas Monjalon 2025-10-22 23:52 ` Patrick Robb 0 siblings, 1 reply; 5+ messages in thread From: Thomas Monjalon @ 2025-10-22 23:36 UTC (permalink / raw) To: Ajit Khaparde; +Cc: ci, Ali Alnubani, Patrick Robb 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: BNXT patches 2025-10-22 23:36 ` Thomas Monjalon @ 2025-10-22 23:52 ` Patrick Robb 2025-10-23 0:09 ` Ajit Khaparde 0 siblings, 1 reply; 5+ messages in thread From: Patrick Robb @ 2025-10-22 23:52 UTC (permalink / raw) To: Thomas Monjalon; +Cc: Ajit Khaparde, ci, Ali Alnubani [-- Attachment #1: Type: text/plain, Size: 3384 bytes --] 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 > > > > > [-- Attachment #2: Type: text/html, Size: 4445 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: BNXT patches 2025-10-22 23:52 ` Patrick Robb @ 2025-10-23 0:09 ` Ajit Khaparde 2025-10-23 0:36 ` Patrick Robb 0 siblings, 1 reply; 5+ messages in thread From: Ajit Khaparde @ 2025-10-23 0:09 UTC (permalink / raw) To: Patrick Robb; +Cc: Thomas Monjalon, ci, Ali Alnubani [-- Attachment #1: Type: text/plain, Size: 3563 bytes --] 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 >> >> >> >> [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 5479 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: BNXT patches 2025-10-23 0:09 ` Ajit Khaparde @ 2025-10-23 0:36 ` Patrick Robb 0 siblings, 0 replies; 5+ messages in thread From: Patrick Robb @ 2025-10-23 0:36 UTC (permalink / raw) To: Ajit Khaparde; +Cc: Thomas Monjalon, ci, Ali Alnubani [-- Attachment #1: Type: text/plain, Size: 4426 bytes --] 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 > >> > >> > >> > >> > [-- Attachment #2: Type: text/html, Size: 6255 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-10-23 0:36 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CACZ4nhvBbK1kC8oCwkHRn+Mnov9zXgAwUsKduEc8wO3EXs7huw@mail.gmail.com> 2025-10-22 23:05 ` BNXT patches Patrick Robb 2025-10-22 23:36 ` Thomas Monjalon 2025-10-22 23:52 ` Patrick Robb 2025-10-23 0:09 ` Ajit Khaparde 2025-10-23 0:36 ` Patrick Robb
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).