From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Honnappa Nagarahalli" <Honnappa.Nagarahalli@arm.com>,
"Stephen Hemminger" <stephen@networkplumber.org>, <dev@dpdk.org>
Cc: "nd" <nd@arm.com>, "nd" <nd@arm.com>
Subject: RE: unnecessary rx callbacks when zero packets
Date: Mon, 8 Jan 2024 11:19:42 +0100 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F118@smartserver.smartshare.dk> (raw)
In-Reply-To: <DBAPR08MB58143669AD459E90DED7E42598642@DBAPR08MB5814.eurprd08.prod.outlook.com>
> From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> Sent: Sunday, 7 January 2024 21.57
>
> > From: Stephen Hemminger <stephen@networkplumber.org>
> > Sent: Sunday, January 7, 2024 11:37 AM
> >
> > I noticed while looking at packet capture that currently the receive
> callbacks
> > get called even if there are no packets. This seems unnecessary since
> if nb_rx is
> > zero, then there are no packets to look at. My one concern is that
> an
> > application could be using callbacks as some form of scheduling
> mechanism
> > which would be broken.
> Is it possible that the call back functions are maintaining statistics
> on zero packet polls?
I agree with this concern. The primary argument for introducing the callbacks (instead of the application simply calling the same functions at RX and TX time) was to provide instrumentation outside of the application itself. And for instrumentation purposes, zero-packet calls may be relevant.
TX also calls its callback with zero packets. The callbacks treatment should be the same for both RX and TX: Either always call, or only call if non-zero packets.
So: NAK.
Perhaps the packet capture library can be optimized for zero packets instead.
>
> >
> > The change would be:
> >
> >
> > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index
> > 21e3a21903ec..f64bf977c46e 100644
> > --- a/lib/ethdev/rte_ethdev.h
> > +++ b/lib/ethdev/rte_ethdev.h
> > @@ -6077,7 +6077,7 @@ rte_eth_rx_burst(uint16_t port_id, uint16_t
> > queue_id,
> > nb_rx = p->rx_pkt_burst(qd, rx_pkts, nb_pkts);
> >
> > #ifdef RTE_ETHDEV_RXTX_CALLBACKS
> > - {
> > + if (nb_rx > 0) {
> > void *cb;
> >
> > /* rte_memory_order_release memory order was used
> when the
next prev parent reply other threads:[~2024-01-08 10:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-07 17:37 Stephen Hemminger
2024-01-07 20:57 ` Honnappa Nagarahalli
2024-01-08 10:19 ` Morten Brørup [this message]
2024-01-08 15:20 ` Konstantin Ananyev
2024-01-09 11:28 ` Ferruh Yigit
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=98CBD80474FA8B44BF855DF32C47DC35E9F118@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=dev@dpdk.org \
--cc=nd@arm.com \
--cc=stephen@networkplumber.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 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).