From: Joe Damato <jdamato@fastly.com>
To: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: "Samudrala, Sridhar" <sridhar.samudrala@intel.com>,
Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
kuba@kernel.org, davem@davemloft.net, anthony.l.nguyen@intel.com
Subject: Re: [next-queue v2 2/4] i40e: Record number TXes cleaned during NAPI
Date: Thu, 6 Oct 2022 15:56:57 -0700 [thread overview]
Message-ID: <20221006225656.GA86976@fastly.com> (raw)
In-Reply-To: <3e78ef0a-db8a-0380-0a7a-ca8571513355@intel.com>
On Thu, Oct 06, 2022 at 03:35:36PM -0700, Jesse Brandeburg wrote:
> On 10/6/2022 10:32 AM, Joe Damato wrote:
> >Sorry, but I don't see the value in the second param. NAPI decides what to
> >do based on nb_pkts. That's the only parameter that matters for the purpose
> >of NAPI going into poll mode or not, right?
> >
> >If so: I don't see any reason why a second parameter is necessary.
>
> Sridhar and I talked about this offline. We agree now that you can just
> proceed with the single parameter.
OK, thanks.
> >
> >As I mentioned earlier: if it's just that the name of the parameter isn't
> >right (e.g., you want it to be 'tx_processed' instead of 'tx_cleaned') then
> >that's an easy fix; I'll just change the name.
>
> I think the name change isn't necessary, since we're not going to extend
> this patch with full XDP events printed (see below)
>
> >
> >It doesn't seem helpful to have xsk_frames as an out parameter for
> >i40e_napi_poll tracepoint; that value is not used to determine anything
> >about i40e's NAPI.
> >
> >>I am not completely clear on the reasoning behind setting clean_complete
> >>based on number of packets transmitted in case of XDP.
> >>>
> >>>>That might reduce the complexity a bit, and will probably still be pretty
> >>>>useful for people tuning their non-XDP workloads.
> >>
> >>This option is fine too.
> >
> >I'll give Jesse a chance to weigh in before I proceed with spinning a v3.
>
> I'm ok with the patch you have now, that shows nb_pkts because it's the
> input to the polling decision. We can add the detail about XDP transmits
> cleaned in a later series or patch that is by someone who wants the XDP
> details in the napi poll context.
Thanks for the detailed and thoughtful feedback, it is much appreciated.
I'll leave this patch the way it is then and tweak the RX patch to include
an rx_clean_complete boolean as I mentioned in my response to that patch
and send out a v3.
FWIW, I had assumed that you would suggest dropping the XDP stuff so I
pre-emptively spun a branch locally that dropped it... it is a much smaller
change of course, but I suspect that this tracepoint might useful for XDP
users, so I think the decision to leave it with nb_pkts makes sense.
Thanks again for the review. I'll send a v3 shortly.
next prev parent reply other threads:[~2022-10-06 22:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-05 21:21 [next-queue v2 0/4] i40e: Add an i40e_napi_poll tracepoint Joe Damato
2022-10-05 21:21 ` [next-queue v2 1/4] i40e: Store the irq number in i40e_q_vector Joe Damato
2022-10-05 21:21 ` [next-queue v2 2/4] i40e: Record number TXes cleaned during NAPI Joe Damato
2022-10-06 0:16 ` Samudrala, Sridhar
2022-10-06 0:31 ` Joe Damato
2022-10-06 1:00 ` Joe Damato
2022-10-06 13:03 ` Maciej Fijalkowski
2022-10-06 14:57 ` Samudrala, Sridhar
2022-10-06 17:32 ` Joe Damato
2022-10-06 22:35 ` Jesse Brandeburg
2022-10-06 22:56 ` Joe Damato [this message]
2022-10-07 8:08 ` Maciej Fijalkowski
2022-10-05 21:21 ` [next-queue v2 3/4] i40e: Record number of RXes " Joe Damato
2022-10-06 0:36 ` Joe Damato
2022-10-05 21:21 ` [next-queue v2 4/4] i40e: Add i40e_napi_poll tracepoint Joe Damato
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221006225656.GA86976@fastly.com \
--to=jdamato@fastly.com \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jesse.brandeburg@intel.com \
--cc=kuba@kernel.org \
--cc=maciej.fijalkowski@intel.com \
--cc=netdev@vger.kernel.org \
--cc=sridhar.samudrala@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).