Re: BNXT patches

Re: BNXT patches

[Patrick Robb]

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

Re: BNXT patches

[Thomas Monjalon]

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

Re: BNXT patches

[Patrick Robb]

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

Re: BNXT patches

[Ajit Khaparde]

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

Re: BNXT patches

[Patrick Robb]

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