* Re: [PATCH 01/32] doc: add dpaa2 nic details
From: Hemant Agrawal @ 2016-12-06 13:58 UTC (permalink / raw)
To: Mcnamara, John, dev@dpdk.org
Cc: thomas.monjalon@6wind.com, Richardson, Bruce,
shreyansh.jain@nxp.com
In-Reply-To: <B27915DBBA3421428155699D51E4CFE20266ECED@IRSMSX103.ger.corp.intel.com>
On 12/5/2016 10:42 PM, Mcnamara, John wrote:
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Hemant Agrawal
>> Sent: Sunday, December 4, 2016 6:17 PM
>> To: dev@dpdk.org
>> Cc: thomas.monjalon@6wind.com; Richardson, Bruce
>> <bruce.richardson@intel.com>; shreyansh.jain@nxp.com; Hemant Agrawal
>> <hemant.agrawal@nxp.com>
>> Subject: [dpdk-dev] [PATCH 01/32] doc: add dpaa2 nic details
>>
>> Add the dpaa2 architecture and pmd details
>>
>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>
>
> Thanks for the detailed doc.
>
> There is a whitespace warning on merge. Also, some comments below.
Thanks for all your comments. I will take care of these in v2
>> +
>> +DPAA2 Poll Mode Driver
>> +===============================
>> +
>
> The underline should match the length of the title. Also, there should be
> 1 newline after each section header. This is in this example but there are
> several without it.
>
>
>
>> +
>> +NXP DPAA2 (Data Path Acceleration Architecture Gen2)
>> +----------------------------------------------------
>> +
>> +This section provides an overview of the NXP DPAA2 architecture and how
>> +it is integrated into the DPDK.
>
> The text says "This section" which implies that the following sections are
> subsections. In that case the underline for the sub sections should probably
> be: ~~~~~~~~~~~~~~~~
>
> http://dpdk.org/doc/guides/contributing/documentation.html#section-headers
>
> This applies to some other section introductions below as well.
>
>> +
>> +Contents summary
>> +- DPAA2 overview
>> +- Overview of DPAA2 objects
>> +- DPAA2 driver architecture overview
>
> This needs a newline after "Contents summary" to generate a list.
>
>
>> +
>> +DPAA2 Overview
>> +--------------
>> +Refer: `FSL MC BUS in Linux Kernel
>> <https://www.kernel.org/doc/readme/drivers-staging-fsl-mc-README.txt>`_.
>
> s/Refer/Reference/
>
> Note, I was very impressed with this doc until I saw that the text was all
> in the other README file. :-)
>
>
>> +DPAA2 is a hardware architecture designed for high-speeed network
>
> s/speeed/speed/
>
>
>
>> + Toggle display of generic debugging messages
>> +
>> +- ``CONFIG_RTE_LIBRTE_DPAA2_USE_PHYS_IOVA`` (default ``y``)
>> +
>> + Toggle to use physical address vs virtual address for hardware
>> acceleraters.
>
> s/acceleraters/accelerators/
>
>
>
>> +
>> +Driver Compilation
>> +~~~~~~~~~~~~~~~~~~
>> +
>> +To compile the DPAA2 PMD for Linux arm64 gcc target, run the following
>> +“make†command:
>
> Non-ascii/non-Unicode characters here. Use ``make`` instead.
>
>
>> +
>> +# configure the resource container
>> +
>> + configure resources in MC and create the DPRC container
>> + export the DPRC container
>> + e.g. export DPRCT=dprc.2
>
> Should be #. and have a console block or directive like the example below.
>
>
>
>> +
>> +#. Start ``testpmd`` with basic parameters:
>> +
>> + .. code-block:: console
>> +
>> + ./arm64-dpaa2-linuxapp-gcc/testpmd -c 0xff -n 1 \
>> + -- -i --portmask=0x1 --nb-cores=1 --no-flush-rx
>> +
>> +
>
>
>
^ permalink raw reply
* Re: [PATCH] mempool: fix Api documentation
From: Thomas Monjalon @ 2016-12-06 13:39 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev, Mcnamara, John, Wiles, Keith
In-Reply-To: <B27915DBBA3421428155699D51E4CFE20266ADD3@IRSMSX103.ger.corp.intel.com>
> > A previous commit changed the local_cache table into a pointer, reducing
> > the size of the rte_mempool structure.
> >
> > Fix the API comment of rte_mempool_create() related to this modification.
> >
> > Fixes: 213af31e0960 ("mempool: reduce structure size if no cache needed")
> >
> > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] app/testpmd: display port driver name
From: Thomas Monjalon @ 2016-12-06 13:35 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Mcnamara, John, De Lara Guarch, Pablo
In-Reply-To: <B27915DBBA3421428155699D51E4CFE202664B45@IRSMSX103.ger.corp.intel.com>
> > This makes it easier to check which driver name is reported through ethdev
> > rte_eth_dev_info_get().
> >
> > Example:
> >
> > root@ubuntu1604:~/dpdk# ./build/app/testpmd -c 0x6 --vdev
> > net_af_packet0,iface=mgmt0 -- -i --total-num-mbufs 2049 [snip]
> > testpmd> show port info all
> >
> > ********************* Infos for port 0 ********************* MAC address:
> > DE:AD:DE:01:02:03 Driver name: net_af_packet Connect to socket: 0 memory
> > allocation on the socket: 0
> >
> > Signed-off-by: David Marchand <david.marchand@6wind.com>
>
> Good idea.
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] net: introduce big and little endian types
From: Bruce Richardson @ 2016-12-06 13:34 UTC (permalink / raw)
To: Ananyev, Konstantin
Cc: Nélio Laranjeiro, dev@dpdk.org, Olivier Matz, Lu, Wenzhuo,
Adrien Mazarguil
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0E46DC@irsmsx105.ger.corp.intel.com>
On Tue, Dec 06, 2016 at 12:41:00PM +0000, Ananyev, Konstantin wrote:
>
>
> > -----Original Message-----
> > From: Richardson, Bruce
> > Sent: Tuesday, December 6, 2016 11:55 AM
> > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > Cc: Nélio Laranjeiro <nelio.laranjeiro@6wind.com>; dev@dpdk.org; Olivier Matz <olivier.matz@6wind.com>; Lu, Wenzhuo
> > <wenzhuo.lu@intel.com>; Adrien Mazarguil <adrien.mazarguil@6wind.com>
> > Subject: Re: [dpdk-dev] [PATCH] net: introduce big and little endian types
> >
> > On Tue, Dec 06, 2016 at 11:23:42AM +0000, Ananyev, Konstantin wrote:
> > > Hi Neilo,
> > >
> > >
> > > Hi Neilo,
> > > > > >
> > > > > > This commit introduces new rte_{le,be}{16,32,64}_t types and updates
> > > > > > rte_{le,be,cpu}_to_{le,be,cpu}_*() and network header structures
> > > > > > accordingly.
> > > > > >
> > > > > > Specific big/little endian types avoid uncertainty and conversion mistakes.
> > > > > >
> > > > > > No ABI change since these are simply typedefs to the original types.
> > > > >
> > > > > It seems like quite a lot of changes...
> > > > > Could you probably explain what will be the benefit in return?
> > > > > Konstantin
> > > >
> > > > Hi Konstantin,
> > > >
> > > > The benefit is to provide documented byte ordering for data types
> > > > software is manipulating to determine when network to CPU (or CPU to
> > > > network) conversion must be performed.
> > >
> > > Ok, but is it really worth it?
> > > User can still make a mistake and forget to call ntoh()/hton() at some particular place.
> > > From other side most people do know that network protocols headers are usually in BE format.
> > > I would understand the effort, if we'll have some sort of tool that would do some sort of static code analysis
> > > based on these special types or so.
> > > Again, does it mean that we should go and change uint32_t to rte_le_32 inside all Intel PMDs
> > > (and might be in some others too) to be consistent?
> > > Konstantin
> > >
> >
> > I actually quite like this patch as I think it will help make things
> > clear when the user is possibly doing something wrong. I don't think we
> > need to globally change all PMDs to use the types, though.
>
> Ok, so where do you believe we should draw a line?
> Why let say inside lib/librte_net people should use these typedefs, but
> inside drivers/net/ixgbe they don't?
Because those are not public APIs. It would be great if driver writers
used the typedefs, but I don't think it should be mandatory.
>
> >
> > One thing I'm wondering though, is if we might want to take this
> > further. For little endian environments, we could define the big endian
> > types as structs using typedefs, and similarly the le types on be
> > platforms, so that assigning from the non-native type to the native one
> > without a transformation function would cause a compiler error.
>
> Not sure I understand you here.
> Could you possibly provide some example?
>
typedef struct {
short val;
} rte_be16_t;
That way if you try to assign a value of type rte_be16_t to a uint16_t
variable you'll get a compiler error, unless you use an appropriate
conversion function. In short, it changes things from not just looking
wrong - which is the main purpose of Neilo's patchset - to actually
making it incorrect from the compiler's point of view too.
/Bruce
^ permalink raw reply
* Re: [PATCH v2] app/testpmd: unify help strings
From: Thomas Monjalon @ 2016-12-06 13:32 UTC (permalink / raw)
To: Yigit, Ferruh; +Cc: dev, Mcnamara, John, De Lara Guarch, Pablo, Wu, Jingjing
In-Reply-To: <B27915DBBA3421428155699D51E4CFE20266D23D@IRSMSX103.ger.corp.intel.com>
> > Formatted as:
> > cmd fixed_string fixed|string|options <variable>: Description
> >
> > If there is no description, final colon emitted.
> >
> > Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
>
> Good refactoring work to give consistency. It might be worth having a look at the testpmd docs to see if some of the same improvements can be made there as well. That could be a separate patch.
>
> > .f = cmd_config_rss_hash_key_parsed,
> > .data = NULL,
> > - .help_str =
> > - "port config X rss-hash-key ipv4|ipv4-frag|ipv4-tcp|ipv4-udp|"
> > - "ipv4-sctp|ipv4-other|ipv6|ipv6-frag|ipv6-tcp|ipv6-udp|"
> > - "ipv6-sctp|ipv6-other|l2-payload|"
> > - "ipv6-ex|ipv6-tcp-ex|ipv6-udp-ex "
> > - "<string of hexa digits (variable length, NIC dependent)>\n",
> > + .help_str = "port config <port_id> rss-hash-key "
> > + "ipv4|ipv4-frag|ipv4-tcp|ipv4-udp|ipv4-sctp|ipv4-other|"
> > + "ipv6|ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|ipv6-other|"
> > + "l2-payload|ipv6-ex|ipv6-tcp-ex|ipv6-udp-ex "
> > + "<string of hexa digits (variable length, NIC dependent)>",
>
> /hex/hexa/
fixed
> Apart from that:
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] net: introduce big and little endian types
From: Bruce Richardson @ 2016-12-06 13:30 UTC (permalink / raw)
To: Nélio Laranjeiro
Cc: Ananyev, Konstantin, dev@dpdk.org, Olivier Matz, Lu, Wenzhuo,
Adrien Mazarguil
In-Reply-To: <20161206131416.GR21794@autoinstall.dev.6wind.com>
On Tue, Dec 06, 2016 at 02:14:17PM +0100, Nélio Laranjeiro wrote:
> Hi Konstantin, Bruce,
>
> On Tue, Dec 06, 2016 at 11:55:02AM +0000, Bruce Richardson wrote:
> > On Tue, Dec 06, 2016 at 11:23:42AM +0000, Ananyev, Konstantin wrote:
> > > Hi Neilo,
> > >
> > >
> > > Hi Neilo,
> > > > > >
> > > > > > This commit introduces new rte_{le,be}{16,32,64}_t types and updates
> > > > > > rte_{le,be,cpu}_to_{le,be,cpu}_*() and network header structures
> > > > > > accordingly.
> > > > > >
> > > > > > Specific big/little endian types avoid uncertainty and conversion mistakes.
> > > > > >
> > > > > > No ABI change since these are simply typedefs to the original types.
> > > > >
> > > > > It seems like quite a lot of changes...
> > > > > Could you probably explain what will be the benefit in return?
> > > > > Konstantin
> > > >
> > > > Hi Konstantin,
> > > >
> > > > The benefit is to provide documented byte ordering for data types
> > > > software is manipulating to determine when network to CPU (or CPU to
> > > > network) conversion must be performed.
> > >
> > > Ok, but is it really worth it?
> > > User can still make a mistake and forget to call ntoh()/hton() at some particular place.
> > > From other side most people do know that network protocols headers are usually in BE format.
> > > I would understand the effort, if we'll have some sort of tool that would do some sort of static code analysis
> > > based on these special types or so.
> > > Again, does it mean that we should go and change uint32_t to rte_le_32 inside all Intel PMDs
> > > (and might be in some others too) to be consistent?
> > > Konstantin
> > >
> >
> > I actually quite like this patch as I think it will help make things
> > clear when the user is possibly doing something wrong. I don't think we
> > need to globally change all PMDs to use the types, though.
>
> I agree, at least APIs should use this, PMDs can do as they want.
>
> > One thing I'm wondering though, is if we might want to take this
> > further. For little endian environments, we could define the big endian
> > types as structs using typedefs, and similarly the le types on be
> > platforms, so that assigning from the non-native type to the native one
> > without a transformation function would cause a compiler error.
> >
> > /Bruce
>
> If I understand you correctly, this will break hton like functions which
> expects an uint*_t not a structure.
>
Yes, it would break the standard ones, which is the downside of doing
this. We could try "fixing" that with a macro, but that too won't always
work. It's a question of whether the additional safety given by having
the compiler flag an error on an invalid assignment, e.g. of a big-endian
value to a native-little endian value, is worth having to change existing
code using htons to use e.g. rte_htons. Given the cost of changing a lot of
existing code, it may just not be worthwhile, but I thought I'd suggest
it anyway as a way of even better guaranteeing endian-ness safety.
/Bruce
^ permalink raw reply
* Re: [PATCH v2] ethdev: check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS
From: Thomas Monjalon @ 2016-12-06 13:24 UTC (permalink / raw)
To: Alejandro Lucero, Bert van Leeuwen; +Cc: Olivier Matz, dev
In-Reply-To: <20161205135354.4aaa789b@platinum>
> > > From: Bert van Leeuwen <bert.vanleeuwen@netronome.com>
> > >
> > > Arrays inside rte_eth_stats have size=RTE_ETHDEV_QUEUE_STAT_CNTRS.
> > > Some devices report more queues than that and this code blindly uses
> > > the reported number of queues by the device to fill those arrays up.
> > > This patch fixes the problem using MIN between the reported number
> > > of queues and RTE_ETHDEV_QUEUE_STAT_CNTRS.
> > >
> > > Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
> > >
> >
> > Reviewed-by: Olivier Matz <olivier.matz@6wind.com>
>
> Fixes: ce757f5c9a4d ("ethdev: new method to retrieve extended statistics")
Applied, thanks
^ permalink raw reply
* Re: [PATCH] net: introduce big and little endian types
From: Nélio Laranjeiro @ 2016-12-06 13:14 UTC (permalink / raw)
To: Bruce Richardson
Cc: Ananyev, Konstantin, dev@dpdk.org, Olivier Matz, Lu, Wenzhuo,
Adrien Mazarguil
In-Reply-To: <20161206115502.GA12224@bricha3-MOBL3.ger.corp.intel.com>
Hi Konstantin, Bruce,
On Tue, Dec 06, 2016 at 11:55:02AM +0000, Bruce Richardson wrote:
> On Tue, Dec 06, 2016 at 11:23:42AM +0000, Ananyev, Konstantin wrote:
> > Hi Neilo,
> >
> >
> > Hi Neilo,
> > > > >
> > > > > This commit introduces new rte_{le,be}{16,32,64}_t types and updates
> > > > > rte_{le,be,cpu}_to_{le,be,cpu}_*() and network header structures
> > > > > accordingly.
> > > > >
> > > > > Specific big/little endian types avoid uncertainty and conversion mistakes.
> > > > >
> > > > > No ABI change since these are simply typedefs to the original types.
> > > >
> > > > It seems like quite a lot of changes...
> > > > Could you probably explain what will be the benefit in return?
> > > > Konstantin
> > >
> > > Hi Konstantin,
> > >
> > > The benefit is to provide documented byte ordering for data types
> > > software is manipulating to determine when network to CPU (or CPU to
> > > network) conversion must be performed.
> >
> > Ok, but is it really worth it?
> > User can still make a mistake and forget to call ntoh()/hton() at some particular place.
> > From other side most people do know that network protocols headers are usually in BE format.
> > I would understand the effort, if we'll have some sort of tool that would do some sort of static code analysis
> > based on these special types or so.
> > Again, does it mean that we should go and change uint32_t to rte_le_32 inside all Intel PMDs
> > (and might be in some others too) to be consistent?
> > Konstantin
> >
>
> I actually quite like this patch as I think it will help make things
> clear when the user is possibly doing something wrong. I don't think we
> need to globally change all PMDs to use the types, though.
I agree, at least APIs should use this, PMDs can do as they want.
> One thing I'm wondering though, is if we might want to take this
> further. For little endian environments, we could define the big endian
> types as structs using typedefs, and similarly the le types on be
> platforms, so that assigning from the non-native type to the native one
> without a transformation function would cause a compiler error.
>
> /Bruce
If I understand you correctly, this will break hton like functions which
expects an uint*_t not a structure.
--
Nélio Laranjeiro
6WIND
^ permalink raw reply
* Re: [PATCH v2 3/3] doc: consistently quote directory names
From: Mcnamara, John @ 2016-12-06 12:48 UTC (permalink / raw)
To: Baruch Siach, dev@dpdk.org
In-Reply-To: <87dec97f0194546888b9920d74e8af4d83e21208.1481027890.git.baruch@tkos.co.il>
> -----Original Message-----
> From: Baruch Siach [mailto:baruch@tkos.co.il]
> Sent: Tuesday, December 6, 2016 12:38 PM
> To: dev@dpdk.org
> Cc: Mcnamara, John <john.mcnamara@intel.com>; Baruch Siach
> <baruch@tkos.co.il>
> Subject: [PATCH v2 3/3] doc: consistently quote directory names
>
> Quote the names of the app and example directories like other directory
> names in this chapter.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
* Re: [PATCH] nfp: add doc about supported features
From: Mcnamara, John @ 2016-12-06 12:46 UTC (permalink / raw)
To: Yigit, Ferruh, Alejandro Lucero, dev@dpdk.org
In-Reply-To: <3133b0c5-672d-de7d-1690-815c7603e581@intel.com>
> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Tuesday, December 6, 2016 12:08 PM
> To: Alejandro Lucero <alejandro.lucero@netronome.com>; dev@dpdk.org;
> Mcnamara, John <john.mcnamara@intel.com>
> Subject: Re: [dpdk-dev] [PATCH] nfp: add doc about supported features
>
> On 12/2/2016 8:17 AM, Alejandro Lucero wrote:
> > Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
> > ---
> > doc/guides/nics/features/nfp.ini | 25 +++++++++++++++++++++++++
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/doc/guides/nics/features/nfp.ini
> b/doc/guides/nics/features/nfp.ini
> > index d967151..dd78233 100644
> > --- a/doc/guides/nics/features/nfp.ini
> > +++ b/doc/guides/nics/features/nfp.ini
> > @@ -4,3 +4,28 @@
> > ; Refer to default.ini for the full list of available PMD features.
> > ;
> > [Features]
> > +SR-IOV = Y
> > +Link status = Y
> > +Link status event = Y
> > +Rx interrupt = N
>
> Hi John,
>
> Do we support 'N'? Since this is the first 'N' in the table.
>
> I guess not having a value implies feature is not supported.
N or any other single letter is supported.
The nice thing about it is that it is explicitly NO rather than implicitly NO. However, if all the nics filled in the NOes then the table might be hard to read.
So, for consistency it is probably best to just let the unsupported features be blank.
^ permalink raw reply
* Re: [PATCH v2 2/3] doc: correct the description of the app directory
From: Mcnamara, John @ 2016-12-06 12:48 UTC (permalink / raw)
To: Baruch Siach, dev@dpdk.org
In-Reply-To: <8fc9b97c4944544bc680351fb7e72a821275ca4d.1481027890.git.baruch@tkos.co.il>
> -----Original Message-----
> From: Baruch Siach [mailto:baruch@tkos.co.il]
> Sent: Tuesday, December 6, 2016 12:38 PM
> To: dev@dpdk.org
> Cc: Mcnamara, John <john.mcnamara@intel.com>; Baruch Siach
> <baruch@tkos.co.il>
> Subject: [PATCH v2 2/3] doc: correct the description of the app directory
>
> The applications under the app directory are just that, not sample
> applications.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
* Re: [PATCH v2 1/3] doc: note that the app list is incomplete
From: Mcnamara, John @ 2016-12-06 12:48 UTC (permalink / raw)
To: Baruch Siach, dev@dpdk.org
In-Reply-To: <04aef536b67faf3c09e0f4603736057f95b5ef66.1481027890.git.baruch@tkos.co.il>
Acked-by: John McNamara <john.mcnamara@intel.com>
> -----Original Message-----
> From: Baruch Siach [mailto:baruch@tkos.co.il]
> Sent: Tuesday, December 6, 2016 12:38 PM
> To: dev@dpdk.org
> Cc: Mcnamara, John <john.mcnamara@intel.com>; Baruch Siach
> <baruch@tkos.co.il>
> Subject: [PATCH v2 1/3] doc: note that the app list is incomplete
>
> Extend the note at the end of Source Organization chapter to also mention
> the app directory.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
* Re: [PATCH] net: introduce big and little endian types
From: Ananyev, Konstantin @ 2016-12-06 12:41 UTC (permalink / raw)
To: Richardson, Bruce
Cc: Nélio Laranjeiro, dev@dpdk.org, Olivier Matz, Lu, Wenzhuo,
Adrien Mazarguil
In-Reply-To: <20161206115502.GA12224@bricha3-MOBL3.ger.corp.intel.com>
> -----Original Message-----
> From: Richardson, Bruce
> Sent: Tuesday, December 6, 2016 11:55 AM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: Nélio Laranjeiro <nelio.laranjeiro@6wind.com>; dev@dpdk.org; Olivier Matz <olivier.matz@6wind.com>; Lu, Wenzhuo
> <wenzhuo.lu@intel.com>; Adrien Mazarguil <adrien.mazarguil@6wind.com>
> Subject: Re: [dpdk-dev] [PATCH] net: introduce big and little endian types
>
> On Tue, Dec 06, 2016 at 11:23:42AM +0000, Ananyev, Konstantin wrote:
> > Hi Neilo,
> >
> >
> > Hi Neilo,
> > > > >
> > > > > This commit introduces new rte_{le,be}{16,32,64}_t types and updates
> > > > > rte_{le,be,cpu}_to_{le,be,cpu}_*() and network header structures
> > > > > accordingly.
> > > > >
> > > > > Specific big/little endian types avoid uncertainty and conversion mistakes.
> > > > >
> > > > > No ABI change since these are simply typedefs to the original types.
> > > >
> > > > It seems like quite a lot of changes...
> > > > Could you probably explain what will be the benefit in return?
> > > > Konstantin
> > >
> > > Hi Konstantin,
> > >
> > > The benefit is to provide documented byte ordering for data types
> > > software is manipulating to determine when network to CPU (or CPU to
> > > network) conversion must be performed.
> >
> > Ok, but is it really worth it?
> > User can still make a mistake and forget to call ntoh()/hton() at some particular place.
> > From other side most people do know that network protocols headers are usually in BE format.
> > I would understand the effort, if we'll have some sort of tool that would do some sort of static code analysis
> > based on these special types or so.
> > Again, does it mean that we should go and change uint32_t to rte_le_32 inside all Intel PMDs
> > (and might be in some others too) to be consistent?
> > Konstantin
> >
>
> I actually quite like this patch as I think it will help make things
> clear when the user is possibly doing something wrong. I don't think we
> need to globally change all PMDs to use the types, though.
Ok, so where do you believe we should draw a line?
Why let say inside lib/librte_net people should use these typedefs, but
inside drivers/net/ixgbe they don't?
>
> One thing I'm wondering though, is if we might want to take this
> further. For little endian environments, we could define the big endian
> types as structs using typedefs, and similarly the le types on be
> platforms, so that assigning from the non-native type to the native one
> without a transformation function would cause a compiler error.
Not sure I understand you here.
Could you possibly provide some example?
Konstantin
^ permalink raw reply
* [PATCH v2 3/3] doc: consistently quote directory names
From: Baruch Siach @ 2016-12-06 12:38 UTC (permalink / raw)
To: dev; +Cc: John McNamara, Baruch Siach
In-Reply-To: <04aef536b67faf3c09e0f4603736057f95b5ef66.1481027890.git.baruch@tkos.co.il>
Quote the names of the app and example directories like other directory
names in this chapter.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
v2: New patch
---
doc/guides/prog_guide/source_org.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/guides/prog_guide/source_org.rst b/doc/guides/prog_guide/source_org.rst
index 27e18e8951a0..6167384db4d3 100644
--- a/doc/guides/prog_guide/source_org.rst
+++ b/doc/guides/prog_guide/source_org.rst
@@ -125,7 +125,7 @@ Applications
Applications are source files that contain a ``main()`` function.
They are located in the ``$(RTE_SDK)/app`` and ``$(RTE_SDK)/examples`` directories.
-The app directory contains applications that are used to test DPDK (such as autotests)
+The ``app`` directory contains applications that are used to test DPDK (such as autotests)
or the Poll Mode Drivers (test-pmd)::
app
@@ -135,7 +135,7 @@ or the Poll Mode Drivers (test-pmd)::
+-- test-pipeline # Test the IP Pipeline framework
+-- test-pmd # Test and benchmark poll mode drivers
-The examples directory contains sample applications that show how libraries can be used::
+The ``examples`` directory contains sample applications that show how libraries can be used::
examples
+-- cmdline # Example of using the cmdline library
@@ -162,5 +162,5 @@ The examples directory contains sample applications that show how libraries can
.. note::
- The actual app and examples directories may contain additional applications to those shown above.
+ The actual ``app`` and ``examples`` directories may contain additional applications to those shown above.
Check the latest DPDK source files for details.
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/3] doc: correct the description of the app directory
From: Baruch Siach @ 2016-12-06 12:38 UTC (permalink / raw)
To: dev; +Cc: John McNamara, Baruch Siach
In-Reply-To: <04aef536b67faf3c09e0f4603736057f95b5ef66.1481027890.git.baruch@tkos.co.il>
The applications under the app directory are just that, not sample
applications.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
v2: New patch (John M)
---
doc/guides/prog_guide/source_org.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/guides/prog_guide/source_org.rst b/doc/guides/prog_guide/source_org.rst
index be4b564fb23e..27e18e8951a0 100644
--- a/doc/guides/prog_guide/source_org.rst
+++ b/doc/guides/prog_guide/source_org.rst
@@ -125,7 +125,7 @@ Applications
Applications are source files that contain a ``main()`` function.
They are located in the ``$(RTE_SDK)/app`` and ``$(RTE_SDK)/examples`` directories.
-The app directory contains sample applications that are used to test DPDK (such as autotests)
+The app directory contains applications that are used to test DPDK (such as autotests)
or the Poll Mode Drivers (test-pmd)::
app
--
2.10.2
^ permalink raw reply related
* [PATCH v2 1/3] doc: note that the app list is incomplete
From: Baruch Siach @ 2016-12-06 12:38 UTC (permalink / raw)
To: dev; +Cc: John McNamara, Baruch Siach
Extend the note at the end of Source Organization chapter to also mention
the app directory.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
v2: Refer to 'applications' in general (John M)
---
doc/guides/prog_guide/source_org.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/guides/prog_guide/source_org.rst b/doc/guides/prog_guide/source_org.rst
index 4a4a0a325dd7..be4b564fb23e 100644
--- a/doc/guides/prog_guide/source_org.rst
+++ b/doc/guides/prog_guide/source_org.rst
@@ -162,5 +162,5 @@ The examples directory contains sample applications that show how libraries can
.. note::
- The actual examples directory may contain additional sample applications to those shown above.
+ The actual app and examples directories may contain additional applications to those shown above.
Check the latest DPDK source files for details.
--
2.10.2
^ permalink raw reply related
* [PATCH v2] doc: introduce PVP reference benchmark
From: Maxime Coquelin @ 2016-12-06 12:24 UTC (permalink / raw)
To: yuanhan.liu, thomas.monjalon, john.mcnamara, zhiyong.yang,
ktraynor, dev
Cc: Maxime Coquelin
Having reference benchmarks is important in order to obtain
reproducible performance figures.
This patch describes required steps to configure a PVP setup
using testpmd in both host and guest.
Not relying on external vSwitch ease integration in a CI loop by
not being impacted by DPDK API changes.
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
---
Thanks to all the reviewers, this v2 should take all remarks into account.
-- Maxime
doc/guides/howto/img/pvp_2nics.svg | 556 +++++++++++++++++++++++++++
doc/guides/howto/index.rst | 1 +
doc/guides/howto/pvp_reference_benchmark.rst | 395 +++++++++++++++++++
3 files changed, 952 insertions(+)
create mode 100644 doc/guides/howto/img/pvp_2nics.svg
create mode 100644 doc/guides/howto/pvp_reference_benchmark.rst
diff --git a/doc/guides/howto/img/pvp_2nics.svg b/doc/guides/howto/img/pvp_2nics.svg
new file mode 100644
index 0000000..517a800
--- /dev/null
+++ b/doc/guides/howto/img/pvp_2nics.svg
@@ -0,0 +1,556 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://creativecommons.org/ns#"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="127.46428mm"
+ height="139.41411mm"
+ viewBox="0 0 451.64508 493.987"
+ id="svg2"
+ version="1.1"
+ inkscape:version="0.92pre2 r"
+ sodipodi:docname="pvp_2nics.svg"
+ inkscape:export-filename="/home/max/Pictures/dpdk/pvp/pvp.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <marker
+ inkscape:stockid="Arrow1Lend"
+ orient="auto"
+ refY="0"
+ refX="0"
+ id="marker4760"
+ style="overflow:visible"
+ inkscape:isstock="true">
+ <path
+ inkscape:connector-curvature="0"
+ id="path4762"
+ d="M 0,0 5,-5 -12.5,0 5,5 Z"
+ style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1"
+ transform="matrix(-0.8,0,0,-0.8,-10,0)" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow1Lend"
+ orient="auto"
+ refY="0"
+ refX="0"
+ id="marker4642"
+ style="overflow:visible"
+ inkscape:isstock="true">
+ <path
+ inkscape:connector-curvature="0"
+ id="path4644"
+ d="M 0,0 5,-5 -12.5,0 5,5 Z"
+ style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1"
+ transform="matrix(-0.8,0,0,-0.8,-10,0)" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow1Lstart"
+ orient="auto"
+ refY="0"
+ refX="0"
+ id="marker10370"
+ style="overflow:visible"
+ inkscape:isstock="true">
+ <path
+ id="path10372"
+ d="M 0,0 5,-5 -12.5,0 5,5 Z"
+ style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1"
+ transform="matrix(0.8,0,0,0.8,10,0)"
+ inkscape:connector-curvature="0" />
+ </marker>
+ <marker
+ inkscape:isstock="true"
+ style="overflow:visible"
+ id="marker10306"
+ refX="0"
+ refY="0"
+ orient="auto"
+ inkscape:stockid="Arrow1Lend">
+ <path
+ transform="matrix(-0.8,0,0,-0.8,-10,0)"
+ style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1"
+ d="M 0,0 5,-5 -12.5,0 5,5 Z"
+ id="path10308"
+ inkscape:connector-curvature="0" />
+ </marker>
+ <marker
+ inkscape:isstock="true"
+ style="overflow:visible"
+ id="marker9757"
+ refX="0"
+ refY="0"
+ orient="auto"
+ inkscape:stockid="Arrow1Lend"
+ inkscape:collect="always">
+ <path
+ transform="matrix(-0.8,0,0,-0.8,-10,0)"
+ style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1"
+ d="M 0,0 5,-5 -12.5,0 5,5 Z"
+ id="path9759"
+ inkscape:connector-curvature="0" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow1Lstart"
+ orient="auto"
+ refY="0"
+ refX="0"
+ id="Arrow1Lstart"
+ style="overflow:visible"
+ inkscape:isstock="true">
+ <path
+ id="path4224"
+ d="M 0,0 5,-5 -12.5,0 5,5 Z"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
+ transform="matrix(0.8,0,0,0.8,10,0)"
+ inkscape:connector-curvature="0" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow1Lend"
+ orient="auto"
+ refY="0"
+ refX="0"
+ id="Arrow1Lend"
+ style="overflow:visible"
+ inkscape:isstock="true">
+ <path
+ id="path4227"
+ d="M 0,0 5,-5 -12.5,0 5,5 Z"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
+ transform="matrix(-0.8,0,0,-0.8,-10,0)"
+ inkscape:connector-curvature="0" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow1Lend"
+ orient="auto"
+ refY="0"
+ refX="0"
+ id="Arrow1Lend-1"
+ style="overflow:visible"
+ inkscape:isstock="true">
+ <path
+ inkscape:connector-curvature="0"
+ id="path4227-27"
+ d="M 0,0 5,-5 -12.5,0 5,5 Z"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
+ transform="matrix(-0.8,0,0,-0.8,-10,0)" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow1Lstart"
+ orient="auto"
+ refY="0"
+ refX="0"
+ id="Arrow1Lstart-9"
+ style="overflow:visible"
+ inkscape:isstock="true">
+ <path
+ inkscape:connector-curvature="0"
+ id="path4224-3"
+ d="M 0,0 5,-5 -12.5,0 5,5 Z"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
+ transform="matrix(0.8,0,0,0.8,10,0)" />
+ </marker>
+ <marker
+ inkscape:isstock="true"
+ style="overflow:visible"
+ id="marker9757-0"
+ refX="0"
+ refY="0"
+ orient="auto"
+ inkscape:stockid="Arrow1Lend">
+ <path
+ transform="matrix(-0.8,0,0,-0.8,-10,0)"
+ style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1"
+ d="M 0,0 5,-5 -12.5,0 5,5 Z"
+ id="path9759-6"
+ inkscape:connector-curvature="0" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow1Lstart"
+ orient="auto"
+ refY="0"
+ refX="0"
+ id="Arrow1Lstart-6"
+ style="overflow:visible"
+ inkscape:isstock="true">
+ <path
+ inkscape:connector-curvature="0"
+ id="path4224-0"
+ d="M 0,0 5,-5 -12.5,0 5,5 Z"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
+ transform="matrix(0.8,0,0,0.8,10,0)" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow1Lend"
+ orient="auto"
+ refY="0"
+ refX="0"
+ id="Arrow1Lend-62"
+ style="overflow:visible"
+ inkscape:isstock="true">
+ <path
+ inkscape:connector-curvature="0"
+ id="path4227-6"
+ d="M 0,0 5,-5 -12.5,0 5,5 Z"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
+ transform="matrix(-0.8,0,0,-0.8,-10,0)" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow1Lstart"
+ orient="auto"
+ refY="0"
+ refX="0"
+ id="marker10370-7"
+ style="overflow:visible"
+ inkscape:isstock="true">
+ <path
+ inkscape:connector-curvature="0"
+ id="path10372-9"
+ d="M 0,0 5,-5 -12.5,0 5,5 Z"
+ style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1"
+ transform="matrix(0.8,0,0,0.8,10,0)" />
+ </marker>
+ <marker
+ inkscape:isstock="true"
+ style="overflow:visible"
+ id="marker9757-2"
+ refX="0"
+ refY="0"
+ orient="auto"
+ inkscape:stockid="Arrow1Lend">
+ <path
+ transform="matrix(-0.8,0,0,-0.8,-10,0)"
+ style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1"
+ d="M 0,0 5,-5 -12.5,0 5,5 Z"
+ id="path9759-0"
+ inkscape:connector-curvature="0" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow1Lstart"
+ orient="auto"
+ refY="0"
+ refX="0"
+ id="Arrow1Lstart-9-2"
+ style="overflow:visible"
+ inkscape:isstock="true">
+ <path
+ inkscape:connector-curvature="0"
+ id="path4224-3-3"
+ d="M 0,0 5,-5 -12.5,0 5,5 Z"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
+ transform="matrix(0.8,0,0,0.8,10,0)" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow1Lend"
+ orient="auto"
+ refY="0"
+ refX="0"
+ id="Arrow1Lend-1-7"
+ style="overflow:visible"
+ inkscape:isstock="true">
+ <path
+ inkscape:connector-curvature="0"
+ id="path4227-27-5"
+ d="M 0,0 5,-5 -12.5,0 5,5 Z"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
+ transform="matrix(-0.8,0,0,-0.8,-10,0)" />
+ </marker>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="0.49497475"
+ inkscape:cx="206.7485"
+ inkscape:cy="227.93958"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ showgrid="false"
+ inkscape:object-nodes="true"
+ inkscape:window-width="1916"
+ inkscape:window-height="1040"
+ inkscape:window-x="0"
+ inkscape:window-y="38"
+ inkscape:window-maximized="0"
+ inkscape:snap-grids="true"
+ inkscape:snap-to-guides="true"
+ inkscape:snap-others="false"
+ inkscape:snap-nodes="false"
+ inkscape:snap-global="false" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ <dc:title></dc:title>
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1"
+ transform="translate(-5.3301459,-7.348317)">
+ <rect
+ style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:1.78969002;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect4140"
+ width="434.38919"
+ height="75.295639"
+ x="21.691195"
+ y="404.59354" />
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ x="421.47873"
+ y="501.3353"
+ id="text4142"><tspan
+ sodipodi:role="line"
+ id="tspan4144"
+ x="421.47873"
+ y="501.3353"
+ style="font-size:25px;line-height:125%">TE</tspan></text>
+ <rect
+ style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:1.46599996;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect4146"
+ width="92.934036"
+ height="32.324883"
+ x="182.57764"
+ y="372.03574" />
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ x="183.5878"
+ y="397.28958"
+ id="text4148"><tspan
+ sodipodi:role="line"
+ id="tspan4150"
+ x="183.5878"
+ y="397.28958"
+ style="font-size:25px">10G NIC</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ x="166.92024"
+ y="451.33276"
+ id="text4152"><tspan
+ sodipodi:role="line"
+ id="tspan4154"
+ x="166.92024"
+ y="451.33276">Moongen</tspan></text>
+ <rect
+ style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:1.39882457;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect4156"
+ width="449.73071"
+ height="244.32167"
+ x="6.0295582"
+ y="29.046324" />
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ x="405.31628"
+ y="25.048317"
+ id="text4158"><tspan
+ sodipodi:role="line"
+ id="tspan4160"
+ x="405.31628"
+ y="25.048317"
+ style="font-size:25px">DUT</tspan></text>
+ <rect
+ style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:1.14168489;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect4162"
+ width="418.69415"
+ height="107.50462"
+ x="19.038134"
+ y="41.044758" />
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ x="395.38812"
+ y="66.496857"
+ id="text4164"><tspan
+ sodipodi:role="line"
+ id="tspan4166"
+ x="395.38812"
+ y="66.496857"
+ style="font-size:25px">VM</tspan></text>
+ <rect
+ style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:1.46599996;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect4146-3"
+ width="92.934036"
+ height="32.324883"
+ x="183.0827"
+ y="274.05093" />
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ x="184.09286"
+ y="299.30475"
+ id="text4148-6"><tspan
+ sodipodi:role="line"
+ id="tspan4150-7"
+ x="184.09286"
+ y="299.30475"
+ style="font-size:25px">10G NIC</tspan></text>
+ <rect
+ style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:2.4804399;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect4189"
+ width="398.00476"
+ height="65.451302"
+ x="26.901583"
+ y="82.647781" />
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:25px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ x="30.683046"
+ y="108.31288"
+ id="text4191"><tspan
+ sodipodi:role="line"
+ id="tspan4193"
+ x="30.683046"
+ y="108.31288">TestPMD</tspan><tspan
+ sodipodi:role="line"
+ x="30.683046"
+ y="139.56288"
+ id="tspan10476">(macswap)</tspan></text>
+ <rect
+ style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:2.49124122;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect4189-5"
+ width="397.22263"
+ height="66.152573"
+ x="29.743357"
+ y="207.6543" />
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:25px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ x="42.720772"
+ y="231.14902"
+ id="text4191-3"><tspan
+ sodipodi:role="line"
+ id="tspan4193-5"
+ x="42.720772"
+ y="231.14902">TestPMD </tspan><tspan
+ sodipodi:role="line"
+ x="42.720772"
+ y="262.39902"
+ id="tspan9747">(io)</tspan></text>
+ <path
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.97838062px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend)"
+ d="M 202.56669,371.44487 V 308.37034"
+ id="path4218"
+ inkscape:connector-curvature="0" />
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.97297633px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow1Lstart)"
+ d="M 252.03098,369.63533 V 307.25568"
+ id="path4218-9"
+ inkscape:connector-curvature="0" />
+ <path
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.92982113px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend-1)"
+ d="M 198.63811,207.44389 V 150.47507"
+ id="path4218-0"
+ inkscape:connector-curvature="0" />
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.95360273px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow1Lstart-9)"
+ d="M 255.56859,206.9303 V 147.01008"
+ id="path4218-9-6"
+ inkscape:connector-curvature="0" />
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 1;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker9757)"
+ d="M 199.50513,271.00921 V 207.3696"
+ id="path9749"
+ inkscape:connector-curvature="0" />
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 1;stroke-dashoffset:0;stroke-opacity:1;marker-start:url(#marker10370)"
+ d="M 255.56859,270.56991 V 206.9303"
+ id="path9749-2"
+ inkscape:connector-curvature="0" />
+ <rect
+ style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:1.46599996;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect4146-36"
+ width="92.934036"
+ height="32.324883"
+ x="304.05591"
+ y="372.52954" />
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ x="305.06607"
+ y="397.78339"
+ id="text4148-7"><tspan
+ sodipodi:role="line"
+ id="tspan4150-5"
+ x="305.06607"
+ y="397.78339"
+ style="font-size:25px">10G NIC</tspan></text>
+ <rect
+ style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:1.46599996;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect4146-3-3"
+ width="92.934036"
+ height="32.324883"
+ x="306.07623"
+ y="273.53461" />
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:40px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ x="307.0864"
+ y="298.78842"
+ id="text4148-6-5"><tspan
+ sodipodi:role="line"
+ id="tspan4150-7-6"
+ x="307.0864"
+ y="298.78842"
+ style="font-size:25px">10G NIC</tspan></text>
+ <path
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.97838062px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend-62)"
+ d="M 323.7504,370.24835 V 307.17382"
+ id="path4218-1"
+ inkscape:connector-curvature="0" />
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.97297633px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow1Lstart-6)"
+ d="M 373.21469,368.43881 V 306.05916"
+ id="path4218-9-8"
+ inkscape:connector-curvature="0" />
+ <path
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.92982113px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend-1-7)"
+ d="M 324.93036,207.24894 V 150.28012"
+ id="path4218-0-9"
+ inkscape:connector-curvature="0" />
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.95360273px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow1Lstart-9-2)"
+ d="M 381.86084,206.73535 V 146.81513"
+ id="path4218-9-6-2"
+ inkscape:connector-curvature="0" />
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 1;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker9757-2)"
+ d="M 325.79738,270.81426 V 207.17465"
+ id="path9749-28"
+ inkscape:connector-curvature="0" />
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 1;stroke-dashoffset:0;stroke-opacity:1;marker-start:url(#marker10370-7)"
+ d="M 381.86084,270.37496 V 206.73535"
+ id="path9749-2-9"
+ inkscape:connector-curvature="0" />
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:2, 1;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker4642)"
+ d="M 198.57143,148.79077 V 95.93363 h 182.85714 v 50"
+ id="path3748"
+ inkscape:connector-curvature="0" />
+ <path
+ style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.01005316;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:2.02010632, 1.01005316;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker4760)"
+ d="m 325.70774,148.78714 v -32.84999 h -70.7012 v 30.70761"
+ id="path4634"
+ inkscape:connector-curvature="0" />
+ </g>
+</svg>
diff --git a/doc/guides/howto/index.rst b/doc/guides/howto/index.rst
index 5575b27..712a9f3 100644
--- a/doc/guides/howto/index.rst
+++ b/doc/guides/howto/index.rst
@@ -38,3 +38,4 @@ HowTo Guides
lm_bond_virtio_sriov
lm_virtio_vhost_user
flow_bifurcation
+ pvp_reference_benchmark
diff --git a/doc/guides/howto/pvp_reference_benchmark.rst b/doc/guides/howto/pvp_reference_benchmark.rst
new file mode 100644
index 0000000..c5bbd32
--- /dev/null
+++ b/doc/guides/howto/pvp_reference_benchmark.rst
@@ -0,0 +1,395 @@
+.. BSD LICENSE
+ Copyright(c) 2016 Red Hat, Inc. All rights reserved.
+ All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions
+ are met:
+
+ * Redistributions of source code must retain the above copyright
+ notice, this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in
+ the documentation and/or other materials provided with the
+ distribution.
+ * Neither the name of Intel Corporation nor the names of its
+ contributors may be used to endorse or promote products derived
+ from this software without specific prior written permission.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+
+PVP reference benchmark setup using testpmd
+===========================================
+
+This guide lists the steps required to setup a PVP benchmark using testpmd as
+a simple forwarder between NICs and Vhost interfaces. The goal of this setup
+is to have a reference PVP benchmark without using external vSwitches (OVS,
+VPP, ...) to make it easier to obtain reproducible results and to facilitate
+continuous integration testing.
+
+The guide covers two ways of launching the VM, either by directly calling the
+QEMU command line, or by relying on libvirt. It has been tested with DPDK
+v16.11 using RHEL7 for both host and guest.
+
+
+Setup overview
+--------------
+
+.. _figure_pvp_2nics:
+
+.. figure:: img/pvp_2nics.*
+
+ PVP setup using 2 NICs
+
+In this diagram, each red arrow represents one logical core. This use-case
+requires 6 dedicated logical cores. A forwarding configuration with a single
+NIC is also possible, requiring 3 logical cores.
+
+
+Host setup
+----------
+
+In this setup, we isolate 6 cores (from CPU2 to CPU7) on the same NUMA
+node. Two cores are assigned to the VM vCPUs running testpmd and four are
+assigned to testpmd on the host.
+
+
+Host tuning
+~~~~~~~~~~~
+
+#. On BIOS, disable turbo-boost and hyper-threads.
+
+#. Append these options to Kernel command line:
+
+ .. code-block:: console
+
+ intel_pstate=disable mce=ignore_ce default_hugepagesz=1G hugepagesz=1G hugepages=6 isolcpus=2-7 rcu_nocbs=2-7 nohz_full=2-7 iommu=pt intel_iommu=on
+
+#. Disable hyper-threads at runtime if necessary or if BIOS is not accessible:
+
+ .. code-block:: console
+
+ cat /sys/devices/system/cpu/cpu*[0-9]/topology/thread_siblings_list \
+ | sort | uniq \
+ | awk -F, '{system("echo 0 > /sys/devices/system/cpu/cpu"$2"/online")}'
+
+#. Disable NMIs:
+
+ .. code-block:: console
+
+ echo 0 > /proc/sys/kernel/nmi_watchdog
+
+#. Exclude isolated CPUs from the writeback cpumask:
+
+ .. code-block:: console
+
+ echo ffffff03 > /sys/bus/workqueue/devices/writeback/cpumask
+
+#. Isolate CPUs from IRQs:
+
+ .. code-block:: console
+
+ clear_mask=0xfc #Isolate CPU2 to CPU7 from IRQs
+ for i in /proc/irq/*/smp_affinity
+ do
+ echo "obase=16;$(( 0x$(cat $i) & ~$clear_mask ))" | bc > $i
+ done
+
+
+Qemu build
+~~~~~~~~~~
+
+Build Qemu:
+
+ .. code-block:: console
+
+ git clone git://git.qemu.org/qemu.git
+ cd qemu
+ mkdir bin
+ cd bin
+ ../configure --target-list=x86_64-softmmu
+
+
+DPDK build
+~~~~~~~~~~
+
+Build DPDK:
+
+ .. code-block:: console
+
+ git clone git://dpdk.org/dpdk
+ cd dpdk
+ export RTE_SDK=$PWD
+ make install T=x86_64-native-linuxapp-gcc DESTDIR=install
+
+
+Testpmd launch
+~~~~~~~~~~~~~~
+
+#. Assign NICs to DPDK:
+
+ .. code-block:: console
+
+ modprobe vfio-pci
+ $RTE_SDK/install/sbin/dpdk-devbind -b vfio-pci 0000:11:00.0 0000:11:00.1
+
+ .. Note::
+
+ The Sandy Bridge family seems to have some IOMMU limitations giving poor
+ performance results. To achieve good performance on these machines
+ consider using UIO instead.
+
+#. Launch the testpmd application:
+
+ .. code-block:: console
+
+ $RTE_SDK/install/bin/testpmd -l 0,2,3,4,5 --socket-mem=1024 -n 4 \
+ --vdev 'net_vhost0,iface=/tmp/vhost-user1' \
+ --vdev 'net_vhost1,iface=/tmp/vhost-user2' -- \
+ --portmask=f --disable-hw-vlan -i --rxq=1 --txq=1
+ --nb-cores=4 --forward-mode=io
+
+With this command, isolated CPUs 2 to 5 will be used as lcores for PMD threads.
+
+#. In testpmd interactive mode, set the portlist to obtain the correct port
+ chaining:
+
+ .. code-block:: console
+
+ set portlist 0,2,1,3
+ start
+
+
+VM launch
+~~~~~~~~~
+
+The VM may be launched either by calling QEMU directly, or by using libvirt.
+
+#. Qemu way:
+
+Launch QEMU with two Virtio-net devices paired to the vhost-user sockets
+created by testpmd. Below example uses default Virtio-net options, but options
+may be specified, for example to disable mergeable buffers or indirect
+descriptors.
+
+ .. code-block:: console
+
+ <QEMU path>/bin/x86_64-softmmu/qemu-system-x86_64 \
+ -enable-kvm -cpu host -m 3072 -smp 3 \
+ -chardev socket,id=char0,path=/tmp/vhost-user1 \
+ -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \
+ -device virtio-net-pci,netdev=mynet1,mac=52:54:00:02:d9:01,addr=0x10 \
+ -chardev socket,id=char1,path=/tmp/vhost-user2 \
+ -netdev type=vhost-user,id=mynet2,chardev=char1,vhostforce \
+ -device virtio-net-pci,netdev=mynet2,mac=52:54:00:02:d9:02,addr=0x11 \
+ -object memory-backend-file,id=mem,size=3072M,mem-path=/dev/hugepages,share=on \
+ -numa node,memdev=mem -mem-prealloc \
+ -net user,hostfwd=tcp::1002$1-:22 -net nic \
+ -qmp unix:/tmp/qmp.socket,server,nowait \
+ -monitor stdio <vm_image>.qcow2
+
+You can use this `qmp-vcpu-pin <https://patchwork.kernel.org/patch/9361617/>`_
+script to pin vCPUs.
+
+It can be used as follows, for example to pin 3 vCPUs to CPUs 1, 6 and 7,
+where isolated CPUs 6 and 7 will be used as lcores for Virtio PMDs:
+
+ .. code-block:: console
+
+ export PYTHONPATH=$PYTHONPATH:<QEMU path>/scripts/qmp
+ ./qmp-vcpu-pin -s /tmp/qmp.socket 1 6 7
+
+#. Libvirt way:
+
+Some initial steps are required for libvirt to be able to connect to testpmd's
+sockets.
+
+First, SELinux policy needs to be set to permissive, since testpmd is
+generally run as root (note, as reboot is required):
+
+ .. code-block:: console
+
+ cat /etc/selinux/config
+
+ # This file controls the state of SELinux on the system.
+ # SELINUX= can take one of these three values:
+ # enforcing - SELinux security policy is enforced.
+ # permissive - SELinux prints warnings instead of enforcing.
+ # disabled - No SELinux policy is loaded.
+ SELINUX=permissive
+
+ # SELINUXTYPE= can take one of three two values:
+ # targeted - Targeted processes are protected,
+ # minimum - Modification of targeted policy.
+ # Only selected processes are protected.
+ # mls - Multi Level Security protection.
+ SELINUXTYPE=targeted
+
+
+Also, Qemu needs to be run as root, which has to be specified in
+``/etc/libvirt/qemu.conf``:
+
+ .. code-block:: console
+
+ user = "root"
+
+Once the domain created, the following snippet is an extract of he most
+important information (hugepages, vCPU pinning, Virtio PCI devices):
+
+ .. code-block:: xml
+
+ <domain type='kvm'>
+ <memory unit='KiB'>3145728</memory>
+ <currentMemory unit='KiB'>3145728</currentMemory>
+ <memoryBacking>
+ <hugepages>
+ <page size='1048576' unit='KiB' nodeset='0'/>
+ </hugepages>
+ <locked/>
+ </memoryBacking>
+ <vcpu placement='static'>3</vcpu>
+ <cputune>
+ <vcpupin vcpu='0' cpuset='1'/>
+ <vcpupin vcpu='1' cpuset='6'/>
+ <vcpupin vcpu='2' cpuset='7'/>
+ <emulatorpin cpuset='0'/>
+ </cputune>
+ <numatune>
+ <memory mode='strict' nodeset='0'/>
+ </numatune>
+ <os>
+ <type arch='x86_64' machine='pc-i440fx-rhel7.0.0'>hvm</type>
+ <boot dev='hd'/>
+ </os>
+ <cpu mode='host-passthrough'>
+ <topology sockets='1' cores='3' threads='1'/>
+ <numa>
+ <cell id='0' cpus='0-2' memory='3145728' unit='KiB' memAccess='shared'/>
+ </numa>
+ </cpu>
+ <devices>
+ <interface type='vhostuser'>
+ <mac address='56:48:4f:53:54:01'/>
+ <source type='unix' path='/tmp/vhost-user1' mode='client'/>
+ <model type='virtio'/>
+ <driver name='vhost' rx_queue_size='256' />
+ <address type='pci' domain='0x0000' bus='0x00' slot='0x10' function='0x0'/>
+ </interface>
+ <interface type='vhostuser'>
+ <mac address='56:48:4f:53:54:02'/>
+ <source type='unix' path='/tmp/vhost-user2' mode='client'/>
+ <model type='virtio'/>
+ <driver name='vhost' rx_queue_size='256' />
+ <address type='pci' domain='0x0000' bus='0x00' slot='0x11' function='0x0'/>
+ </interface>
+ </devices>
+ </domain>
+
+
+Guest setup
+-----------
+
+
+Guest tuning
+~~~~~~~~~~~~
+
+#. Append these options to the Kernel command line:
+
+ .. code-block:: console
+
+ default_hugepagesz=1G hugepagesz=1G hugepages=1 intel_iommu=on iommu=pt isolcpus=1,2 rcu_nocbs=1,2 nohz_full=1,2
+
+#. Disable NMIs:
+
+ .. code-block:: console
+
+ echo 0 > /proc/sys/kernel/nmi_watchdog
+
+#. Exclude isolated CPU1 and CPU2 from the writeback cpumask:
+
+ .. code-block:: console
+
+ echo 1 > /sys/bus/workqueue/devices/writeback/cpumask
+
+#. Isolate CPUs from IRQs:
+
+ .. code-block:: console
+
+ clear_mask=0x6 #Isolate CPU1 and CPU2 from IRQs
+ for i in /proc/irq/*/smp_affinity
+ do
+ echo "obase=16;$(( 0x$(cat $i) & ~$clear_mask ))" | bc > $i
+ done
+
+
+DPDK build
+~~~~~~~~~~
+
+Build DPDK:
+
+ .. code-block:: console
+
+ git clone git://dpdk.org/dpdk
+ cd dpdk
+ export RTE_SDK=$PWD
+ make install T=x86_64-native-linuxapp-gcc DESTDIR=install
+
+
+Testpmd launch
+~~~~~~~~~~~~~~
+
+Probe vfio module without iommu:
+
+ .. code-block:: console
+
+ modprobe -r vfio_iommu_type1
+ modprobe -r vfio
+ modprobe vfio enable_unsafe_noiommu_mode=1
+ cat /sys/module/vfio/parameters/enable_unsafe_noiommu_mode
+ modprobe vfio-pci
+
+Bind the virtio-net devices to DPDK:
+
+ .. code-block:: console
+
+ $RTE_SDK/tools/dpdk-devbind.py -b vfio-pci 0000:00:10.0 0000:00:11.0
+
+Start testpmd:
+
+ .. code-block:: console
+
+ $RTE_SDK/install/bin/testpmd -l 0,1,2 --socket-mem 1024 -n 4 \
+ --proc-type auto --file-prefix pg -- \
+ --portmask=3 --forward-mode=macswap --port-topology=chained \
+ --disable-hw-vlan --disable-rss -i --rxq=1 --txq=1 \
+ --rxd=256 --txd=256 --nb-cores=2 --auto-start
+
+Results template
+----------------
+
+Below template should be used when sharing results:
+
+ .. code-block:: none
+
+ Traffic Generator: <Test equipment (e.g. IXIA, Moongen, ...)>
+ Acceptable Loss: <n>%
+ Validation run time: <n>min
+ Host DPDK version/commit: <version, SHA-1>
+ Guest DPDK version/commit: <version, SHA-1>
+ Patches applied: <link to patchwork>
+ QEMU version/commit: <version>
+ Virtio features: <features (e.g. mrg_rxbuf='off', leave empty if default)>
+ CPU: <CPU model>, <CPU frequency>
+ NIC: <NIC model>
+ Result: <n> Mpps
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] nfp: add doc about supported features
From: Ferruh Yigit @ 2016-12-06 12:08 UTC (permalink / raw)
To: Alejandro Lucero, dev, John McNamara
In-Reply-To: <1480666653-35544-1-git-send-email-alejandro.lucero@netronome.com>
On 12/2/2016 8:17 AM, Alejandro Lucero wrote:
> Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
> ---
> doc/guides/nics/features/nfp.ini | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/doc/guides/nics/features/nfp.ini b/doc/guides/nics/features/nfp.ini
> index d967151..dd78233 100644
> --- a/doc/guides/nics/features/nfp.ini
> +++ b/doc/guides/nics/features/nfp.ini
> @@ -4,3 +4,28 @@
> ; Refer to default.ini for the full list of available PMD features.
> ;
> [Features]
> +SR-IOV = Y
> +Link status = Y
> +Link status event = Y
> +Rx interrupt = N
Hi John,
Do we support 'N'? Since this is the first 'N' in the table.
I guess not having a value implies feature is not supported.
> +Queue start/stop = Y
> +MTU update = Y
> +Jumbo frame = Y
> +Scattered Rx = N
> +TSO = N
> +RSS hash = Y
> +RSS key update = Y
> +RSS reta update = Y
> +Flow control = Y
> +CRC offload = N
> +VLAN offload = Y
> +L3 checksum offload = Y
> +L4 checksum offload = Y
> +Promiscuous mode = Y
> +Basic stats = Y
> +Stats per queue = Y
> +Linux UIO = Y
> +Linux VFIO = Y
> +x86-32 = N
> +x86-64 = Y
> +Usage doc = Y
>
^ permalink raw reply
* Re: [PATCH v3] nfp: report link speed using hardware info
From: Ferruh Yigit @ 2016-12-06 11:57 UTC (permalink / raw)
To: Alejandro Lucero, dev
In-Reply-To: <1480669552-10411-1-git-send-email-alejandro.lucero@netronome.com>
On 12/2/2016 9:05 AM, Alejandro Lucero wrote:
> Previous reported speed was hardcoded.
>
> v3: remove unsed macro
> v2: using RTE_DIM instead of own macro
>
> Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
> ---
> drivers/net/nfp/nfp_net.c | 28 ++++++++++++++++++++++++++--
> 1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
> index c6b1587..24f3164 100644
> --- a/drivers/net/nfp/nfp_net.c
> +++ b/drivers/net/nfp/nfp_net.c
> @@ -816,6 +816,17 @@ static void nfp_net_read_mac(struct nfp_net_hw *hw)
> struct rte_eth_link link, old;
> uint32_t nn_link_status;
>
> + static const uint32_t ls_to_ethtool[] = {
> + [NFP_NET_CFG_STS_LINK_RATE_UNSUPPORTED] = ETH_SPEED_NUM_NONE,
> + [NFP_NET_CFG_STS_LINK_RATE_UNKNOWN] = ETH_SPEED_NUM_NONE,
> + [NFP_NET_CFG_STS_LINK_RATE_1G] = ETH_SPEED_NUM_1G,
> + [NFP_NET_CFG_STS_LINK_RATE_10G] = ETH_SPEED_NUM_10G,
> + [NFP_NET_CFG_STS_LINK_RATE_25G] = ETH_SPEED_NUM_25G,
> + [NFP_NET_CFG_STS_LINK_RATE_40G] = ETH_SPEED_NUM_40G,
> + [NFP_NET_CFG_STS_LINK_RATE_50G] = ETH_SPEED_NUM_50G,
> + [NFP_NET_CFG_STS_LINK_RATE_100G] = ETH_SPEED_NUM_100G,
> + };
> +
> PMD_DRV_LOG(DEBUG, "Link update\n");
>
> hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> @@ -831,8 +842,21 @@ static void nfp_net_read_mac(struct nfp_net_hw *hw)
> link.link_status = ETH_LINK_UP;
>
> link.link_duplex = ETH_LINK_FULL_DUPLEX;
> - /* Other cards can limit the tx and rx rate per VF */
> - link.link_speed = ETH_SPEED_NUM_40G;
> +
> + nn_link_status = (nn_link_status >> NFP_NET_CFG_STS_LINK_RATE_SHIFT) &
> + NFP_NET_CFG_STS_LINK_RATE_MASK;
> +
> + if ((NFD_CFG_MAJOR_VERSION_of(hw->ver) < 4) ||
> + ((NFD_CFG_MINOR_VERSION_of(hw->ver) == 4) &&
> + (NFD_CFG_MINOR_VERSION_of(hw->ver) == 0)))
> + link.link_speed = ETH_SPEED_NUM_40G;
Same comment from previous review:
For specific firmware version, speed is still hardcoded to 40G, can you
please mention from this and if possible its reason in commit log?
> + else {
> + if (nn_link_status == NFP_NET_CFG_STS_LINK_RATE_UNKNOWN ||
Again from previous review:
> This is for checking any wrong value from firmware/hardware.
I see, but removing this check will not change the logic, else branch is
taken and again same value set.
Still if you deliberately prefer to keep it, that is OK.
> + nn_link_status >= RTE_DIM(ls_to_ethtool))
> + link.link_speed = ETH_SPEED_NUM_NONE;
> + else
> + link.link_speed = ls_to_ethtool[nn_link_status];
> + }
>
> if (old.link_status != link.link_status) {
> nfp_net_dev_atomic_write_link_status(dev, &link);
>
^ permalink raw reply
* Re: [PATCH] net: introduce big and little endian types
From: Bruce Richardson @ 2016-12-06 11:55 UTC (permalink / raw)
To: Ananyev, Konstantin
Cc: Nélio Laranjeiro, dev@dpdk.org, Olivier Matz, Lu, Wenzhuo,
Adrien Mazarguil
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0E4632@irsmsx105.ger.corp.intel.com>
On Tue, Dec 06, 2016 at 11:23:42AM +0000, Ananyev, Konstantin wrote:
> Hi Neilo,
>
>
> Hi Neilo,
> > > >
> > > > This commit introduces new rte_{le,be}{16,32,64}_t types and updates
> > > > rte_{le,be,cpu}_to_{le,be,cpu}_*() and network header structures
> > > > accordingly.
> > > >
> > > > Specific big/little endian types avoid uncertainty and conversion mistakes.
> > > >
> > > > No ABI change since these are simply typedefs to the original types.
> > >
> > > It seems like quite a lot of changes...
> > > Could you probably explain what will be the benefit in return?
> > > Konstantin
> >
> > Hi Konstantin,
> >
> > The benefit is to provide documented byte ordering for data types
> > software is manipulating to determine when network to CPU (or CPU to
> > network) conversion must be performed.
>
> Ok, but is it really worth it?
> User can still make a mistake and forget to call ntoh()/hton() at some particular place.
> From other side most people do know that network protocols headers are usually in BE format.
> I would understand the effort, if we'll have some sort of tool that would do some sort of static code analysis
> based on these special types or so.
> Again, does it mean that we should go and change uint32_t to rte_le_32 inside all Intel PMDs
> (and might be in some others too) to be consistent?
> Konstantin
>
I actually quite like this patch as I think it will help make things
clear when the user is possibly doing something wrong. I don't think we
need to globally change all PMDs to use the types, though.
One thing I'm wondering though, is if we might want to take this
further. For little endian environments, we could define the big endian
types as structs using typedefs, and similarly the le types on be
platforms, so that assigning from the non-native type to the native one
without a transformation function would cause a compiler error.
/Bruce
^ permalink raw reply
* Re: [PATCH 2/2] doc: note that the app list is incomplete
From: Mcnamara, John @ 2016-12-06 11:54 UTC (permalink / raw)
To: Baruch Siach; +Cc: dev@dpdk.org
In-Reply-To: <20161206114604.njbhde25fvro7vn7@tarshish>
> -----Original Message-----
> From: Baruch Siach [mailto:baruch@tkos.co.il]
> Sent: Tuesday, December 6, 2016 11:46 AM
> To: Mcnamara, John <john.mcnamara@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [PATCH 2/2] doc: note that the app list is incomplete
>
> Hi John,
>
> On Tue, Dec 06, 2016 at 11:41:44AM +0000, Mcnamara, John wrote:
> > > Extend the note at the end of Source Organization chapter to also
> > > mention the app directory.
> > >
> > > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > > ---
> > > doc/guides/prog_guide/source_org.rst | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/doc/guides/prog_guide/source_org.rst
> > > b/doc/guides/prog_guide/source_org.rst
> > > index 4a4a0a325dd7..8fd98d507008 100644
> > > --- a/doc/guides/prog_guide/source_org.rst
> > > +++ b/doc/guides/prog_guide/source_org.rst
> > > @@ -162,5 +162,5 @@ The examples directory contains sample
> > > applications that show how libraries can
> > >
> > > .. note::
> > >
> > > - The actual examples directory may contain additional sample
> > > applications to those shown above.
> > > + The actual app and examples directories may contain additional
> > > + sample
> > > applications to those shown above.
> > > Check the latest DPDK source files for details.
> >
> > Strictly speaking the applications in the "app" directory aren't
> > "sample" apps and also they don't change very often.
>
> The text above says just that:
>
The docs keep making a liar of me. :-/
> The app directory contains sample applications that are used to test
> DPDK...
>
> Should I change the wording there?
Yes, change that line as well. Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] doc: note that the app list is incomplete
From: Baruch Siach @ 2016-12-06 11:46 UTC (permalink / raw)
To: Mcnamara, John; +Cc: dev@dpdk.org
In-Reply-To: <B27915DBBA3421428155699D51E4CFE20266F4BA@IRSMSX103.ger.corp.intel.com>
Hi John,
On Tue, Dec 06, 2016 at 11:41:44AM +0000, Mcnamara, John wrote:
> > Extend the note at the end of Source Organization chapter to also mention
> > the app directory.
> >
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > ---
> > doc/guides/prog_guide/source_org.rst | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/doc/guides/prog_guide/source_org.rst
> > b/doc/guides/prog_guide/source_org.rst
> > index 4a4a0a325dd7..8fd98d507008 100644
> > --- a/doc/guides/prog_guide/source_org.rst
> > +++ b/doc/guides/prog_guide/source_org.rst
> > @@ -162,5 +162,5 @@ The examples directory contains sample applications
> > that show how libraries can
> >
> > .. note::
> >
> > - The actual examples directory may contain additional sample
> > applications to those shown above.
> > + The actual app and examples directories may contain additional sample
> > applications to those shown above.
> > Check the latest DPDK source files for details.
>
> Strictly speaking the applications in the "app" directory aren't "sample" apps
> and also they don't change very often.
The text above says just that:
The app directory contains sample applications that are used to test DPDK...
Should I change the wording there?
> So I would leave this note as it is or change it to:
>
> The actual app and examples directories may contain additional applications
> to those shown above.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* Re: [PATCH] vhost: allow for many vhost user ports
From: Jan Wickbom @ 2016-12-06 11:42 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: huawei.xie@intel.com, dev@dpdk.org, Patrik Andersson R
In-Reply-To: <20161206065633.GQ24403@yliu-dev.sh.intel.com>
> -----Original Message-----
> From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com]
> Sent: den 6 december 2016 07:57
> To: Jan Wickbom <jan.wickbom@ericsson.com>
> Cc: huawei.xie@intel.com; dev@dpdk.org; Patrik Andersson R
> <patrik.r.andersson@ericsson.com>
> Subject: Re: [PATCH] vhost: allow for many vhost user ports
>
> On Thu, Dec 01, 2016 at 04:26:50PM +0100, Jan Wickbom wrote:
> > Currently select() is used to monitor file descriptors for vhostuser
> > ports. This limits the number of ports possible to create since the
> > fd number is used as index in the fd_set and we have seen fds > 1023.
>
> Yeah, it's a known issue for a while. Thanks for making a patch to fix
> that!
Thanks for your comments! Please see below for some questions/opinions.
>
> > This patch changes select() to poll(). This way we can keep an
> > packed (pollfd) array for the fds, e.g. as many fds as the size of
> > the array.
> >
> > Also see:
> > http://dpdk.org/ml/archives/dev/2016-April/037024.html
> >
> ...
> > +/**
> > + * Adjusts the highest index populated in the array of fds
>
> This function only shrinks (but not extends) the fdset array, so why
> not naming it to something like "fdset_shrink".
>
> > + * @return
> > + * Index of highest position populated + 1.
>
> I think it's clearer to say "The new size of fdset".
>
>
> > @@ -189,7 +206,7 @@
> > pfdset->fd[i].fd = -1;
> > pfdset->fd[i].rcb = pfdset-
> >fd[i].wcb = NULL;
> > pfdset->fd[i].dat = NULL;
> > - pfdset->num--;
> > + (void) fdset_adjust_num(pfdset);
>
> Unncessary cast.
I'd like to keep the cast. The function returns int and it's nice to show we deliberately
don't care. No strong opinion though, but we should do the same everywhere. Please
see below.
>
> > i = -1;
> > }
> > pthread_mutex_unlock(&pfdset->fd_mutex);
> > @@ -211,12 +228,12 @@
> >
> > pfdset->fd[index].fd = -1;
> > pfdset->fd[index].rcb = pfdset->fd[index].wcb = NULL;
> > - pfdset->fd[index].dat = NULL;
> > - pfdset->num--;
> > + (void) fdset_adjust_num(pfdset);
If we remove the cast above, we should remove this one as well.
> >
> > pthread_mutex_unlock(&pfdset->fd_mutex);
> > }
> >
> > +
> > /**
> > * This functions runs in infinite blocking loop until there is no fd in
> > * pfdset. It calls corresponding r/w handler if there is event on the fd.
> > @@ -229,44 +246,48 @@
> > void
> > fdset_event_dispatch(struct fdset *pfdset)
> > {
> > - fd_set rfds, wfds;
> > - int i, maxfds;
> > + int i;
> > struct fdentry *pfdentry;
> > - int num = MAX_FDS;
> > + int numfds;
> > fd_cb rcb, wcb;
> > void *dat;
> > int fd;
> > int remove1, remove2;
> > int ret;
> > + int handled;
> >
> > if (pfdset == NULL)
> > return;
> >
> > + struct pollfd * const rwfds =
> > + rte_malloc("struct pollfd", MAX_FDS *
> sizeof(*rwfds), 0);
>
> There is neither a NULL check, nor a free after the usage. Since it's
> a fixed size at compile time (MAX_FDS), you might want to define a
> static array for that.
>
> --yliu
^ permalink raw reply
* Re: [PATCH 1/2] doc: remove chkincs reference
From: Mcnamara, John @ 2016-12-06 11:42 UTC (permalink / raw)
To: Baruch Siach, dev@dpdk.org
In-Reply-To: <33b0b0e68842ec18280b049c28f785b26871affc.1481022133.git.baruch@tkos.co.il>
> -----Original Message-----
> From: Baruch Siach [mailto:baruch@tkos.co.il]
> Sent: Tuesday, December 6, 2016 11:02 AM
> To: dev@dpdk.org
> Cc: Mcnamara, John <john.mcnamara@intel.com>; Baruch Siach
> <baruch@tkos.co.il>
> Subject: [PATCH 1/2] doc: remove chkincs reference
>
> The chkincs app was removed in commit 1b938bb9dfb6 ("app: remove
> chkincs").
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
* Re: [PATCH 0/2] Event queue exception handling in Solarflare PMD
From: Ferruh Yigit @ 2016-12-06 11:42 UTC (permalink / raw)
To: Andrew Rybchenko, dev
In-Reply-To: <1480664481-26427-1-git-send-email-arybchenko@solarflare.com>
On 12/2/2016 7:41 AM, Andrew Rybchenko wrote:
> The patch series adds event queue exception handling.
>
> It is not required when everything goes fine, but has chances to
> recover if something goes wrong in either driver or HW.
>
> The patch series should be applied after
> [PATCH v2 00/55] Solarflare libefx-based PMD
> (Message-ID: 1480436367-20749-1-git-send-email-arybchenko@solarflare.com)
>
>
> Andrew Rybchenko (1):
> net/sfc: restart RxQ in case of exception on its event queue
>
> Ivan Malov (1):
> net/sfc: restart TxQ in case of exception on its event queue
>
> drivers/net/sfc/sfc.h | 6 ++++++
> drivers/net/sfc/sfc_ev.c | 40 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 46 insertions(+)
>
Series applied to dpdk-next-net/master, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox