DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2 3/4] examples: example showing use of callbacks.
Date: Tue, 17 Feb 2015 16:00:56 +0000	[thread overview]
Message-ID: <20150217160055.GB16360@bricha3-MOBL3> (raw)
In-Reply-To: <20150217154924.GA6309@neilslaptop.think-freely.org>

On Tue, Feb 17, 2015 at 10:49:24AM -0500, Neil Horman wrote:
> On Tue, Feb 17, 2015 at 01:50:58PM +0000, Bruce Richardson wrote:
> > On Tue, Feb 17, 2015 at 02:28:02PM +0100, Olivier MATZ wrote:
> > > Hi Bruce,
> > > 
> > > On 02/17/2015 01:25 PM, Bruce Richardson wrote:
> > > >On Mon, Feb 16, 2015 at 06:34:37PM +0100, Thomas Monjalon wrote:
> > > >>2015-02-16 15:16, Bruce Richardson:
> > > >>>In this specific instance, given that the application does little else, there
> > > >>>is no real advantage to using the callbacks - it's just to have a simple example
> > > >>>of how they can be used.
> > > >>>
> > > >>>Where callbacks are really designed to be useful, is for extending or augmenting
> > > >>>hardware capabilities. Taking the example of sequence numbers - to use the most
> > > >>>trivial example - an application could be written to take advantage of sequence
> > > >>>numbers written to packets by the hardware which received them. However, if such
> > > >>>an application was to be used with a NIC which does not provide sequence numbering
> > > >>>capability, for example, anything using ixgbe driver, the application writer has
> > > >>>two choices - either modify his application code to check each packet for
> > > >>>a sequence number in the data path, and add it there post-rx, or alternatively,
> > > >>>to check the NIC capabilities at initialization time, and add a callback there
> > > >>>at initialization, if the hardware does not support it. In the latter case,
> > > >>>the main packet processing body of the application can be written as though
> > > >>>hardware always has sequence numbering capability, safe in the knowledge that
> > > >>>any hardware not supporting it will be back-filled by a software fallback at
> > > >>>initialization-time.
> > > >>>
> > > >>>By the same token, we could also look to extend hardware capabilities. For
> > > >>>different filtering or hashing capabilities, there can be limits in hardware
> > > >>>which are far less than what we need to use in software. Again, callbacks will
> > > >>>allow the data path to be written in a way that is oblivious to the underlying
> > > >>>hardware limits, because software will transparently fill in the gaps.
> > > >>>
> > > >>>Hope this makes the use case clear.
> > > >>
> > > >>After thinking more about these callbacks, I realize these callbacks won't
> > > >>help, as Olivier said.
> > > >>
> > > >>With callback,
> > > >>1/ application checks device capability
> > > >>2/ application provides hardware emulation as DPDK callback
> > > >>3/ application forgets previous steps
> > > >>4/ application calls DPDK Rx
> > > >>5/ DPDK calls callback (without calling optimization)
> > > >>
> > > >>Without callback,
> > > >>1/ application checks device capability
> > > >>2/ application provides hardware emulation as internal function
> > > >>3/ application set an internal device-flag to enable this function
> > > >>4/ application calls DPDK Rx
> > > >>5/ application calls the hardware emulation if flag is set
> > > >>
> > > >>So the only difference is to keep persistent the device information in
> > > >>the application instead of storing it as a function pointer in the
> > > >>DPDK struct.
> > > >>You can also be faster with this approach: at initialization time,
> > > >>you can check that your NIC supports the feature and use a specific
> > > >>mainloop that adds or not the sequence number without any runtime
> > > >>test.
> > > >
> > > >That is assuming that all NICs are equal on your system. It's also assuming
> > > >that you only have a single point in your application where you call RX or
> > > >TX burst. In the case where you have a couple of different NICs on the system,
> > > >or where you want to write an application to take advantage of capabilities of
> > > >different NICs, the ability to resolve all these difference at initialization
> > > >time is useful. The main packet handling code can be written with just the
> > > >processing of packets in mind, rather than having to have a set of branches
> > > >after each RX burst call, or before each TX burst call, to "smooth out" the
> > > >different NIC capabilities.
> > > >
> > > >As for the option of maintaining different main loops for different NICs with
> > > >different capabilities - that sounds like a maintenance nightmare to
> > > >me, due to duplicated code! Callbacks is a far cleaner solution than that IMHO.
> > > 
> > > Why not just provide a function like this:
> > > 
> > >   rte_do_unsupported_stuff_by_software(m[], m_count, wanted_features,
> > >   	dev_feature_flags)
> > > 
> > > This function can be called (or not) from the application mainloop.
> > > You don't need to maintain several mainloops (for each device) as
> > > the specific work will be done depending on the given flags. And the
> > > applications that do not require these features (most applications?)
> > > are not penalized at all.
> > 
> > Have you measured the performance hit due to this proposed change? In my tests
> > it's very, very small, even for the fastest vectorized path. If performance is
> > a real concern, I'm happy enough to have this as a compile-time option so that
> > those who can't take the small performance hit can avoid it.
> > 
> How can you assert performance metrics on a patch like this?  The point of the
> change is to allow a callback to an application defined function, the contents
> of which are effectively arbitrary.  Not saying that its the wrong thing to do,
> but you can't really claim performance is not impacted, because the details of
> whats executed is outside your purview.
> Neil
>
I think the performance hit being referenced is a hit due to the patch itself
without any callbacks being in use. (That was certainly my assumption in replying)

/Bruce

  reply	other threads:[~2015-02-17 16:01 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-22 16:47 [dpdk-dev] [PATCH RFC 0/3] DPDK ethdev callback support Bruce Richardson
2014-12-22 16:47 ` [dpdk-dev] [PATCH RFC 1/3] ethdev: rename callbacks field to intr_cbs Bruce Richardson
2014-12-22 16:47 ` [dpdk-dev] [PATCH RFC 2/3] ethdev: Add in data rxtx callback support Bruce Richardson
2014-12-22 16:47 ` [dpdk-dev] [PATCH RFC 3/3] examples: example showing use of callbacks Bruce Richardson
2014-12-22 17:02 ` [dpdk-dev] [PATCH RFC 0/3] DPDK ethdev callback support Thomas Monjalon
2014-12-22 17:33   ` Bruce Richardson
2014-12-22 17:47     ` Neil Horman
2014-12-23  9:28       ` Bruce Richardson
2014-12-23 13:09         ` Neil Horman
2014-12-23 14:09           ` Bruce Richardson
2015-01-05 16:17     ` Bruce Richardson
2014-12-22 18:31 ` Stephen Hemminger
2014-12-23  9:29   ` Bruce Richardson
2014-12-23  4:23 ` Vithal S Mohare
2014-12-23  9:30   ` Bruce Richardson
2014-12-23  9:37     ` Vithal S Mohare
2014-12-24  1:43       ` Zhang, Helin
2014-12-24  5:06 ` Qiu, Michael
2015-02-12 19:57 ` [dpdk-dev] [PATCH " John McNamara
2015-02-12 19:57   ` [dpdk-dev] [PATCH 1/3] ethdev: rename callbacks field to intr_cbs John McNamara
2015-02-12 19:57   ` [dpdk-dev] [PATCH 2/3] ethdev: Add in data rxtx callback support John McNamara
2015-02-12 21:12     ` Neil Horman
2015-02-12 19:57   ` [dpdk-dev] [PATCH 3/3] examples: example showing use of callbacks John McNamara
2015-02-13 14:54   ` [dpdk-dev] [PATCH 0/3] DPDK ethdev callback support Declan Doherty
2015-02-13 15:39 ` [dpdk-dev] [PATCH v2 0/4] " John McNamara
2015-02-13 15:39   ` [dpdk-dev] [PATCH v2 1/4] ethdev: rename callbacks field to intr_cbs John McNamara
2015-02-13 16:06     ` Thomas Monjalon
2015-02-13 16:52       ` Thomas Monjalon
2015-02-13 15:39   ` [dpdk-dev] [PATCH v2 2/4] ethdev: Add in data rxtx callback support John McNamara
2015-02-13 16:33     ` Thomas Monjalon
2015-02-13 17:49       ` Bruce Richardson
2015-02-13 15:39   ` [dpdk-dev] [PATCH v2 3/4] examples: example showing use of callbacks John McNamara
2015-02-13 16:02     ` Thomas Monjalon
2015-02-16 14:33     ` Olivier MATZ
2015-02-16 15:16       ` Bruce Richardson
2015-02-16 17:34         ` Thomas Monjalon
2015-02-17 12:17           ` Declan Doherty
2015-02-17 12:25           ` Bruce Richardson
2015-02-17 13:28             ` Olivier MATZ
2015-02-17 13:50               ` Bruce Richardson
2015-02-17 15:49                 ` Neil Horman
2015-02-17 16:00                   ` Bruce Richardson [this message]
2015-02-17 16:08                     ` Neil Horman
2015-02-17 16:15                       ` Bruce Richardson
2015-02-17 19:27                         ` Neil Horman
2015-02-17 15:32             ` Thomas Monjalon
2015-02-17 15:58               ` Bruce Richardson
2015-02-13 15:39   ` [dpdk-dev] [PATCH v2 4/4] abi: Added rxtx callback functions to ABI versioning John McNamara
2015-02-13 15:59     ` Thomas Monjalon
2015-02-13 15:48   ` [dpdk-dev] [PATCH v2 0/4] DPDK ethdev callback support Declan Doherty
2015-02-18 17:42 ` [dpdk-dev] [PATCH v3 0/3] " John McNamara
2015-02-18 17:42   ` [dpdk-dev] [PATCH v3 1/3] ethdev: Rename callbacks field to link_intr_cbs John McNamara
2015-02-18 17:42   ` [dpdk-dev] [PATCH v3 2/3] ethdev: Add rxtx callback support John McNamara
2015-02-18 18:19     ` Thomas Monjalon
2015-02-19  9:33       ` Mcnamara, John
2015-02-18 17:42   ` [dpdk-dev] [PATCH v3 3/3] examples: example showing use of callbacks John McNamara
2015-02-19 17:56   ` [dpdk-dev] [PATCH v4 0/3] DPDK ethdev callback support John McNamara
2015-02-19 17:56     ` [dpdk-dev] [PATCH v4 1/3] ethdev: rename callbacks field to link_intr_cbs John McNamara
2015-02-19 17:56     ` [dpdk-dev] [PATCH v4 2/3] ethdev: add optional rxtx callback support John McNamara
2015-02-20 10:06       ` Bruce Richardson
2015-02-20 10:31         ` Thomas Monjalon
2015-02-19 17:56     ` [dpdk-dev] [PATCH v4 3/3] examples: example showing use of callbacks John McNamara
2015-02-20 17:03   ` [dpdk-dev] [PATCH v5 0/3] DPDK ethdev callback support John McNamara
2015-02-20 17:03     ` [dpdk-dev] [PATCH v5 1/3] ethdev: rename callbacks field to link_intr_cbs John McNamara
2015-02-20 17:03     ` [dpdk-dev] [PATCH v5 2/3] ethdev: add optional rxtx callback support John McNamara
2015-02-23 15:11       ` Thomas Monjalon
2015-02-23 17:27         ` Mcnamara, John
2015-02-20 17:03     ` [dpdk-dev] [PATCH v5 3/3] examples: example showing use of callbacks John McNamara
2015-02-23 18:30   ` [dpdk-dev] [PATCH v6 0/3] DPDK ethdev callback support John McNamara
2015-02-23 18:30     ` [dpdk-dev] [PATCH v6 1/3] ethdev: rename callbacks field to link_intr_cbs John McNamara
2015-02-23 18:30     ` [dpdk-dev] [PATCH v6 2/3] ethdev: add optional rxtx callback support John McNamara
2015-02-23 18:30     ` [dpdk-dev] [PATCH v6 3/3] examples: example showing use of callbacks John McNamara
2015-02-23 23:39     ` [dpdk-dev] [PATCH v6 0/3] DPDK ethdev callback support 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=20150217160055.GB16360@bricha3-MOBL3 \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=nhorman@tuxdriver.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).