All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: Joe Damato <jdamato@fastly.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	kuba@kernel.org, davem@davemloft.net
Subject: Re: [Intel-wired-lan] [next-queue v2 2/4] i40e: Record number TXes cleaned during NAPI
Date: Fri, 7 Oct 2022 10:08:14 +0200	[thread overview]
Message-ID: <Yz/ebplwWG5UlU/i@boxer> (raw)
In-Reply-To: <20221006225656.GA86976@fastly.com>

On Thu, Oct 06, 2022 at 03:56:57PM -0700, Joe Damato wrote:
> 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)

So better to keep the twisted naming?

> > 
> > >
> > >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.

Please spell out whole AF_XDP instead of referring to XDP. Future readers
might get confused. XDP is totally fine with what Joe is doing, I'm trying
to bring up whole AF_XDP term and I feel like I'm being ignored.

number of produced packets to HW tx ring != number of produced packets to
AF_XDP CQ ring.

> 
> 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.
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

WARNING: multiple messages have this Message-ID (diff)
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: Joe Damato <jdamato@fastly.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>,
	"Samudrala, Sridhar" <sridhar.samudrala@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: Fri, 7 Oct 2022 10:08:14 +0200	[thread overview]
Message-ID: <Yz/ebplwWG5UlU/i@boxer> (raw)
In-Reply-To: <20221006225656.GA86976@fastly.com>

On Thu, Oct 06, 2022 at 03:56:57PM -0700, Joe Damato wrote:
> 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)

So better to keep the twisted naming?

> > 
> > >
> > >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.

Please spell out whole AF_XDP instead of referring to XDP. Future readers
might get confused. XDP is totally fine with what Joe is doing, I'm trying
to bring up whole AF_XDP term and I feel like I'm being ignored.

number of produced packets to HW tx ring != number of produced packets to
AF_XDP CQ ring.

> 
> 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.

  reply	other threads:[~2022-10-07  8:08 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-05 21:21 [Intel-wired-lan] [next-queue v2 0/4] i40e: Add an i40e_napi_poll tracepoint Joe Damato
2022-10-05 21:21 ` Joe Damato
2022-10-05 21:21 ` [Intel-wired-lan] [next-queue v2 1/4] i40e: Store the irq number in i40e_q_vector Joe Damato
2022-10-05 21:21   ` Joe Damato
2022-10-05 21:21 ` [Intel-wired-lan] [next-queue v2 2/4] i40e: Record number TXes cleaned during NAPI Joe Damato
2022-10-05 21:21   ` Joe Damato
2022-10-06  0:16   ` [Intel-wired-lan] " Samudrala, Sridhar
2022-10-06  0:16     ` Samudrala, Sridhar
2022-10-06  0:31     ` [Intel-wired-lan] " Joe Damato
2022-10-06  0:31       ` Joe Damato
2022-10-06  1:00       ` [Intel-wired-lan] " Joe Damato
2022-10-06  1:00         ` Joe Damato
2022-10-06 13:03         ` [Intel-wired-lan] " Maciej Fijalkowski
2022-10-06 13:03           ` Maciej Fijalkowski
2022-10-06 14:57           ` [Intel-wired-lan] " Samudrala, Sridhar
2022-10-06 14:57             ` Samudrala, Sridhar
2022-10-06 17:32             ` [Intel-wired-lan] " Joe Damato
2022-10-06 17:32               ` Joe Damato
2022-10-06 22:35               ` [Intel-wired-lan] " Jesse Brandeburg
2022-10-06 22:35                 ` Jesse Brandeburg
2022-10-06 22:56                 ` [Intel-wired-lan] " Joe Damato
2022-10-06 22:56                   ` Joe Damato
2022-10-07  8:08                   ` Maciej Fijalkowski [this message]
2022-10-07  8:08                     ` Maciej Fijalkowski
2022-10-05 21:21 ` [Intel-wired-lan] [next-queue v2 3/4] i40e: Record number of RXes " Joe Damato
2022-10-05 21:21   ` Joe Damato
2022-10-06  0:36   ` [Intel-wired-lan] " Joe Damato
2022-10-06  0:36     ` Joe Damato
2022-10-05 21:21 ` [Intel-wired-lan] [next-queue v2 4/4] i40e: Add i40e_napi_poll tracepoint Joe Damato
2022-10-05 21:21   ` 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=Yz/ebplwWG5UlU/i@boxer \
    --to=maciej.fijalkowski@intel.com \
    --cc=davem@davemloft.net \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jdamato@fastly.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.