From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH v2 1/2] ethdev: add buffered tx api
Date: Wed, 09 Mar 2016 16:52:18 +0100 [thread overview]
Message-ID: <2507362.eR3Lu18VyN@xps13> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB97725836B1A669@irsmsx105.ger.corp.intel.com>
2016-03-09 15:42, Ananyev, Konstantin:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 2016-03-09 15:23, Ananyev, Konstantin:
> > > >
> > > > 2016-03-09 13:36, Ananyev, Konstantin:
> > > > > > > + if (to_send == 0)
> > > > > > > + return 0;
> > > > > >
> > > > > > Why this check is done in the lib?
> > > > > > What is the performance gain if we are idle?
> > > > > > It can be done outside if needed.
> > > > >
> > > > > Yes, that could be done outside, but if user has to do it anyway,
> > > > > why not to put it inside?
> > > > > I don't expect any performance gain/loss because of that -
> > > > > just seems a bit more convenient to the user.
> > > >
> > > > It is handling an idle case so there is no gain obviously.
> > > > But the condition branching is surely a loss.
> > >
> > > I suppose that condition should always be checked:
> > > either in user code prior to function call or inside the
> > > function call itself.
> > > So don't expect any difference in performance here...
> > > Do you have any particular example when you think it would?
> > > Or are you talking about rte_eth_tx_buffer() calling
> > > rte_eth_tx_buffer_flush() internally?
> > > For that one - both are flush is 'static inline' , so I expect
> > > compiler be smart enough to remove this redundant check.
> > >
> > > > So why the user would you like to do this check?
> > > Just for user convenience - to save him doing that manually.
> >
> > Probably I've missed something. If we remove this check, the function
> > will do nothing, right? How is it changing the behaviour?
>
> If we'll remove that check, then
> rte_eth_tx_burst(...,nb_pkts=0)->(*dev->tx_pkt_burst)(...,nb_pkts=0)
> will be called.
> So in that case it might be even slower, as we'll have to do a proper call.
If there is no packet, we have time to do a useless call.
> Of course user can avoid it by:
>
> If(tx_buffer->nb_pkts != 0)
> rte_eth_tx_buffer_flush(port, queue, tx_buffer);
>
> But as I said what for to force user to do that?
> Why not to make this check inside the function?
Because it may be slower when there are some packets
and will "accelerate" only the no-packet case.
We do not progress in this discussion. It is not a big deal, just a non sense.
So I agree to keep it if we change the website to announce that DPDK
accelerates the idle processing ;)
next prev parent reply other threads:[~2016-03-09 15:53 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-15 14:43 [PATCH 0/2] add support for buffered tx to ethdev Tomasz Kulasek
2016-01-15 14:43 ` [PATCH 1/2] ethdev: add buffered tx api Tomasz Kulasek
2016-01-15 18:13 ` Stephen Hemminger
2016-01-15 18:14 ` Stephen Hemminger
2016-01-15 18:44 ` Ananyev, Konstantin
2016-02-02 10:00 ` Kulasek, TomaszX
2016-02-02 13:49 ` Ananyev, Konstantin
2016-02-09 17:02 ` Kulasek, TomaszX
2016-02-09 23:56 ` Ananyev, Konstantin
2016-02-12 11:44 ` Ananyev, Konstantin
2016-02-12 16:40 ` Ivan Boule
2016-02-12 17:33 ` Bruce Richardson
2016-01-15 14:43 ` [PATCH 2/2] examples: sample apps rework to use " Tomasz Kulasek
2016-01-15 18:12 ` [PATCH 0/2] add support for buffered tx to ethdev Stephen Hemminger
2016-02-24 17:08 ` [PATCH v2 " Tomasz Kulasek
2016-02-24 17:08 ` [PATCH v2 1/2] ethdev: add buffered tx api Tomasz Kulasek
2016-03-08 22:52 ` Thomas Monjalon
2016-03-09 13:36 ` Ananyev, Konstantin
2016-03-09 14:25 ` Thomas Monjalon
2016-03-09 15:23 ` Ananyev, Konstantin
2016-03-09 15:26 ` Thomas Monjalon
2016-03-09 15:32 ` Kulasek, TomaszX
2016-03-09 15:37 ` Thomas Monjalon
2016-03-09 15:42 ` Ananyev, Konstantin
2016-03-09 15:52 ` Thomas Monjalon [this message]
2016-03-09 16:17 ` Ananyev, Konstantin
2016-03-09 16:21 ` Thomas Monjalon
2016-03-09 16:35 ` Kulasek, TomaszX
2016-03-09 17:06 ` Thomas Monjalon
2016-03-09 18:12 ` Kulasek, TomaszX
2016-02-24 17:08 ` [PATCH v2 2/2] examples: rework to use " Tomasz Kulasek
2016-02-25 16:17 ` [PATCH v2 0/2] add support for buffered tx to ethdev Ananyev, Konstantin
2016-03-10 10:57 ` [PATCH v3 " Tomasz Kulasek
2016-03-10 10:57 ` [PATCH v3 1/2] ethdev: add buffered tx api Tomasz Kulasek
2016-03-10 16:23 ` Thomas Monjalon
2016-03-10 17:15 ` Kulasek, TomaszX
2016-03-10 10:57 ` [PATCH v3 2/2] examples: rework to use buffered tx Tomasz Kulasek
2016-03-10 11:31 ` [PATCH v3 0/2] add support for buffered tx to ethdev Ananyev, Konstantin
2016-03-10 16:01 ` Jastrzebski, MichalX K
2016-03-10 17:19 ` [PATCH v4 " Tomasz Kulasek
2016-03-10 17:19 ` [PATCH v4 1/2] ethdev: add buffered tx api Tomasz Kulasek
2016-03-10 17:19 ` [PATCH v4 2/2] examples: rework to use buffered tx Tomasz Kulasek
2016-03-11 16:39 ` [PATCH v4 0/2] add support for buffered tx to ethdev Thomas Monjalon
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=2507362.eR3Lu18VyN@xps13 \
--to=thomas.monjalon@6wind.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@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 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.