DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Marc Sune <marc.sune@bisdn.de>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC PATCH 0/4] pktdev
Date: Mon, 20 Apr 2015 11:43:16 +0100	[thread overview]
Message-ID: <20150420104316.GA9280@bricha3-MOBL3> (raw)
In-Reply-To: <5534A1EE.4060905@bisdn.de>

On Mon, Apr 20, 2015 at 08:51:26AM +0200, Marc Sune wrote:
> 
> 
> On 17/04/15 21:50, Wiles, Keith wrote:
> >Hi Marc and Bruce,
> 
> Hi Keith, Bruce,
> 
> >
> >On 4/17/15, 1:49 PM, "Marc Sune" <marc.sune@bisdn.de> wrote:
> What I was proposing is to try to add the minimum common shared state in
> order to properly demultiplex the RX/TX call and have a common set of
> abstract calls (the pkt_dev type). In a way, I was proposing to deliberately
> not have a shared struct rte_dev_data because I think the internals of the
> "pkt_dev" can be very different across devices (e.g. queues in kni vs eth
> port vs. crypto?). I treat the pkt_dev as a "black box" that conforms to
> TX/RX API, leaving the developer of that device to define its internal
> structures as it better suites the needs. I only use each of the specific
> device type TX/RX APIs (external to us, pkt_dev library) in rte_pkt_dev.h.
> This also simplifies the refactor required to eventually integrate the
> rte_pkt_dev library and builds it "on top" of the existing APIs.
> 
> The other important difference with both, Bruce and your approach, and mine
> is the use of function pointers for RX/TX. I don't use them, which makes the
> entire abstracted TX/RX (including the final RX/TX routines itself)
> functions be "inlinable".
> 
> Btw, I forgot to add something basic in the previous pseudo-code. The
> different types have to be conditionally compiled according to compiled-in
> DPDK libs:
> 
> rte_pkt_dev.h:
> 
>     #include <rte_config.h>
> 
>     //Eth devices
>     #ifdef RTE_LIBRTE_ETHER
>     #include <rte_ethdev.h>
>     #endif
> 
>     //KNI
>     #ifdef RTE_LIBRTE_KNI
>     #include <rte_kni.h>
>     #endif
> 
>     //...
>     //Include PMD (and non-PMD) TX/RX headers...
> 
>    static inline uint16_t
>    rte_pkt_tx_burst(pkt_dev_t* dev, uint16_t queue_id,
>              struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
>    {
>         switch (((struct rte_pkt_dev_data*)dev)->type){
>             #ifdef RTE_LIBRTE_ETHER
>             case  RTE_PKT_DEV_ETH:
>                 struct rte_eth_dev* eth_dev = (struct rte_eth_dev*)pkt_dev;
>                 rte_pkt_tx_burst(eth_dev, queue_id, tx_pkts, nb_pkts);
>                 break;
>             #endif
> 
>             #ifdef RTE_LIBRTE_KNI
>             case RTE_PKT_DEV_KNI:
>                 //...
>                 break;
>             #endif
> 
>             default:
>                     //Corrupted type or unsupported (without compiled
> support)
>                     //Ignore or fail(fatal error)?
>                     break;
>         }
>    }
> 
>    //...

Yes, this is an interesting approach, and with the inlining could indeed be
less overhead for the ring and kni compared to my suggestion due to the inlining.
There might be a slight overhead for the RX/TX ethdev functions though - 1/2
cycles due to the extra (hopefully predictable) branch in the RX/TX call, since
we always need the indirect function call for the PMDs.

I also like the use of pointers rather than port ids.

Let me think on this a bit more.

/Bruce

  reply	other threads:[~2015-04-20 10:43 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-13 19:44 [dpdk-dev] [RFC PATCH 0/4 v2] Extending DPDK with multiple device support Keith Wiles
2015-04-13 19:44 ` [dpdk-dev] [RFC PATCH 1/4 v2] Adding the common device files for " Keith Wiles
2015-05-04 13:13   ` Marc Sune
2015-05-04 14:44     ` Wiles, Keith
2015-04-13 19:44 ` [dpdk-dev] [RFC PATCH 2/4 v2] Add the ethdev changes " Keith Wiles
2015-04-13 19:44 ` [dpdk-dev] [RFC PATCH 3/4 v2] Add the test file changes for common " Keith Wiles
2015-04-13 19:44 ` [dpdk-dev] [RFC PATCH 4/4 v2] Update PMD files for new " Keith Wiles
2015-04-17 15:16 ` [dpdk-dev] [RFC PATCH 0/4] pktdev Bruce Richardson
2015-04-17 15:16   ` [dpdk-dev] [RFC PATCH 1/4] Add example pktdev implementation Bruce Richardson
2015-04-20 11:26     ` Ananyev, Konstantin
2015-04-20 15:02       ` Bruce Richardson
2015-04-21  8:40         ` Ananyev, Konstantin
2015-04-21  9:23           ` Bruce Richardson
2015-04-17 15:16   ` [dpdk-dev] [RFC PATCH 2/4] Make ethdev explicitly a subclass of pktdev Bruce Richardson
2015-04-17 15:16   ` [dpdk-dev] [RFC PATCH 3/4] add support for a ring to be a pktdev Bruce Richardson
2015-04-17 17:31     ` Neil Horman
2015-04-18  0:00     ` Ouyang, Changchun
2015-04-20 10:32     ` Ananyev, Konstantin
2015-04-17 15:16   ` [dpdk-dev] [RFC PATCH 4/4] example app showing pktdevs used in a chain Bruce Richardson
2015-04-17 17:28   ` [dpdk-dev] [RFC PATCH 0/4] pktdev Neil Horman
2015-04-17 18:49   ` Marc Sune
2015-04-17 19:50     ` Wiles, Keith
2015-04-20  6:51       ` Marc Sune
2015-04-20 10:43         ` Bruce Richardson [this message]
2015-04-20 17:03           ` Marc Sune
2015-04-20 13:19         ` Wiles, Keith
2015-04-20 13:30           ` Wiles, Keith
2015-05-04 13:13 ` [dpdk-dev] [RFC PATCH 0/4 v2] Extending DPDK with multiple device support Marc Sune

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=20150420104316.GA9280@bricha3-MOBL3 \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=marc.sune@bisdn.de \
    /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).