[dpdk-dev] [PATCH] doc: ip_pipeline app user guide

[Thomas Monjalon]

2015-08-06 14:48, Cristian Dumitrescu:
> Signed-off-by: Cristian Dumitrescu 
> ---
>  doc/guides/index.rst   |1 +
>  doc/guides/ip_pipeline_ug/img/ip_pipelines_1.svg   |  718 +
>  doc/guides/ip_pipeline_ug/img/ip_pipelines_2.svg   |  997 +
>  doc/guides/ip_pipeline_ug/img/ip_pipelines_3.svg   |  826 ++
>  doc/guides/ip_pipeline_ug/index.rst|   38 +
>  doc/guides/ip_pipeline_ug/ip_pipeline_app.rst  | 1129 
> 
>  doc/guides/sample_app_ug/index.rst |1 -
>  .../sample_app_ug/internet_proto_ip_pipeline.rst   |  135 ---

The patch is corrupted.
Checkpatch reports:
ERROR:CORRUPTED_PATCH: patch seems to be corrupt (line wrapped?)
Git reports:
fatal: corrupt patch at line 191

[dpdk-dev] [PATCH v1] doc: prog_guide update for RX interrupt event

[Thomas Monjalon]

> > The patch updates the env_abstraction_layer.rst part in prog_guide.
> > It adds the RX interrupt event declaration and revises the others in 
> > interrupt event section.
> > 
> > Signed-off-by: Cunming Liang 
> Acked-by: Danny Zhou 

Applied, thanks

[dpdk-dev] [PATCH 0/2] Warn user if system has more than 64 cores when using VM power manager

[Thomas Monjalon]

2015-08-07 11:06, Gonzalez Monroy, Sergio:
> On 06/08/2015 12:07, Pablo de Lara wrote:
> > Pablo de Lara (2):
> >examples/vm_power_mgr: show warning when using systems with more than
> >  64 cores
> >doc: add known issue regarding VM power mgr in release notes
> >
> >   doc/guides/rel_notes/known_issues.rst   | 24 
> >   examples/vm_power_manager/channel_manager.c | 11 +--
> >   2 files changed, 29 insertions(+), 6 deletions(-)
> >
> Acked-by: Sergio Gonzalez Monroy 

Applied, thanks

[dpdk-dev] [PATCH v2] examples/l3fwd: fix compilation issue when using exact-match

[Thomas Monjalon]

2015-08-10 19:13, Thomas Monjalon:
> 2015-08-10 18:58, Thomas Monjalon:
> > Hi Pablo,
> > 
> > 2015-08-09 11:28, Pablo de Lara:
> > > From: "Pablo de Lara" 
> > > 
> > > L3fwd was trying to use an inexistent function "simple_ipv6_fwd_4pkts",
> > > instead it should be "simple_ipv6_fwd_8pkts", and "simple_ipv8_fwd_4pkts"
> > > instead of "simple_ipv4_fwd_8pkts".
> > > 
> > > Fixes: 80fcb4d4 ("examples/l3fwd: increase lookup burst size to 8")
> > > 
> > > Signed-off-by: Pablo de Lara 
> > > Acked-by: Sergio Gonzalez Monroy 
> > > ---
> > > 
> > > Changes in v2:
> > > 
> > > - Missing to fix additional type
> > 
> > More fixes are needed:
> > 
> > make RTE_SDK=$(readlink -m ../..) RTE_TARGET=x86_64-native-linuxapp-clang \
> > EXTRA_CFLAGS='-DAPP_LOOKUP_METHOD=APP_LOOKUP_EXACT_MATCH'
> > 
> > examples/l3fwd/main.c:545:1: error: unused function 'send_packetsx4'
> > examples/l3fwd/main.c:1165:1: error: unused function 'rfc1812_process'
> > 
> > The right fix would be to remove one APP_LOOKUP_METHOD.
> 
> Build flags are:
> - APP_LOOKUP_METHOD
> - DO_RFC_1812_CHECKS
> - defined(__SSE4_1__) -> ENABLE_MULTI_BUFFER_OPTIMIZE
> - RTE_NEXT_ABI
> 
> Waiting a cleanup for 2.2, this fix should be OK and will be applied:

Applied with additional fix.

[dpdk-dev] [PATCH]doc: Add performance tuning guide about how to get DPDK high perf on Intel platform.

[Qiu, Michael]

On 2015/8/10 9:11, Zhang, Helin wrote:
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
>> Sent: Monday, August 10, 2015 6:38 AM
>> To: Xu, Qian Q
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH]doc: Add performance tuning guide about how
>> to get DPDK high perf on Intel platform.
>>

[../..]

>>> +1. For Intel? 40G NICs, special configurations should be set before 
>>> compiling it,
>> as follows. **Note**: This is very important::
>>> +
>>> +  for at least DPDK release 1.8, 2.0 and 2.1, in
>> /config/common_linuxapp
>>> +  CONFIG_RTE_PCI_CONFIG=y
>>> +  CONFIG_RTE_PCI_EXTENDED_TAG=?on?
>> Please insert it in a i40e doc instead of here. Then you can reference it.
> Good idea!

Yes, agree, actually, for RRC(fm10k), this configure is meaningless.

Thanks,
Michael 
> Regards,
> Helin
>
>

[dpdk-dev] [PATCH v2] examples/l3fwd: fix compilation issue when using exact-match

[Thomas Monjalon]

2015-08-10 18:58, Thomas Monjalon:
> Hi Pablo,
> 
> 2015-08-09 11:28, Pablo de Lara:
> > From: "Pablo de Lara" 
> > 
> > L3fwd was trying to use an inexistent function "simple_ipv6_fwd_4pkts",
> > instead it should be "simple_ipv6_fwd_8pkts", and "simple_ipv8_fwd_4pkts"
> > instead of "simple_ipv4_fwd_8pkts".
> > 
> > Fixes: 80fcb4d4 ("examples/l3fwd: increase lookup burst size to 8")
> > 
> > Signed-off-by: Pablo de Lara 
> > Acked-by: Sergio Gonzalez Monroy 
> > ---
> > 
> > Changes in v2:
> > 
> > - Missing to fix additional type
> 
> More fixes are needed:
> 
> make RTE_SDK=$(readlink -m ../..) RTE_TARGET=x86_64-native-linuxapp-clang \
>   EXTRA_CFLAGS='-DAPP_LOOKUP_METHOD=APP_LOOKUP_EXACT_MATCH'
> 
> examples/l3fwd/main.c:545:1: error: unused function 'send_packetsx4'
> examples/l3fwd/main.c:1165:1: error: unused function 'rfc1812_process'
> 
> The right fix would be to remove one APP_LOOKUP_METHOD.

Build flags are:
- APP_LOOKUP_METHOD
- DO_RFC_1812_CHECKS
- defined(__SSE4_1__) -> ENABLE_MULTI_BUFFER_OPTIMIZE
- RTE_NEXT_ABI

Waiting a cleanup for 2.2, this fix should be OK and will be applied:

--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -541,6 +541,7 @@ send_single_packet(struct rte_mbuf *m, uint8_t port)
return 0;
 }

+#if (APP_LOOKUP_METHOD == APP_LOOKUP_LPM)
 static inline __attribute__((always_inline)) void
 send_packetsx4(struct lcore_conf *qconf, uint8_t port,
struct rte_mbuf *m[], uint32_t num)
@@ -618,6 +619,7 @@ send_packetsx4(struct lcore_conf *qconf, uint8_t port,

qconf->tx_mbufs[port].len = len;
 }
+#endif /* APP_LOOKUP_LPM */

 #ifdef DO_RFC_1812_CHECKS
 static inline int
@@ -1138,6 +1140,8 @@ l3fwd_simple_forward(struct rte_mbuf *m, uint8_t portid, 
struct lcore_conf *qcon
 #endif
 }

+#if ((APP_LOOKUP_METHOD == APP_LOOKUP_LPM) && \
+   (ENABLE_MULTI_BUFFER_OPTIMIZE == 1))
 #ifdef DO_RFC_1812_CHECKS

 #defineIPV4_MIN_VER_IHL0x45
@@ -1188,6 +1192,7 @@ rfc1812_process(struct ipv4_hdr *ipv4_hdr, uint16_t *dp, 
uint32_t flags)
 #else
 #definerfc1812_process(mb, dp) do { } while (0)
 #endif /* DO_RFC_1812_CHECKS */
+#endif /* APP_LOOKUP_LPM && ENABLE_MULTI_BUFFER_OPTIMIZE */


 #if ((APP_LOOKUP_METHOD == APP_LOOKUP_LPM) && \

[dpdk-dev] [PATCH v2] examples/l3fwd: fix compilation issue when using exact-match

[Thomas Monjalon]

Hi Pablo,

2015-08-09 11:28, Pablo de Lara:
> From: "Pablo de Lara" 
> 
> L3fwd was trying to use an inexistent function "simple_ipv6_fwd_4pkts",
> instead it should be "simple_ipv6_fwd_8pkts", and "simple_ipv8_fwd_4pkts"
> instead of "simple_ipv4_fwd_8pkts".
> 
> Fixes: 80fcb4d4 ("examples/l3fwd: increase lookup burst size to 8")
> 
> Signed-off-by: Pablo de Lara 
> Acked-by: Sergio Gonzalez Monroy 
> ---
> 
> Changes in v2:
> 
> - Missing to fix additional type

More fixes are needed:

make RTE_SDK=$(readlink -m ../..) RTE_TARGET=x86_64-native-linuxapp-clang \
EXTRA_CFLAGS='-DAPP_LOOKUP_METHOD=APP_LOOKUP_EXACT_MATCH'

examples/l3fwd/main.c:545:1: error: unused function 'send_packetsx4'
examples/l3fwd/main.c:1165:1: error: unused function 'rfc1812_process'

The right fix would be to remove one APP_LOOKUP_METHOD.

[dpdk-dev] [PATCH] examples/kni: Fix segmentation fault at program exit

[Thomas Monjalon]

> > In kni_free_kni(), p[i] should be p[port_id]
> > 
> > Signed-off-by: Hyun Yoo 
> Acked-by: Helin Zhang 

Applied, thanks

[dpdk-dev] [PATCH]doc: Add performance tuning guide about how to get DPDK high perf on Intel platform.

[Thomas Monjalon]

Hi Helin,
Your comment is unreadable. Please remove useless lines of your reply.

[dpdk-dev] [PATCH]doc: Add performance tuning guide about how to get DPDK high perf on Intel platform.

[Zhang, Helin]

Sorry for repeat! I should have removed the useless pieces!


> +Hardware platform Network Interface Card Essential requirements:
> +
> 
> +
> +1. Get an high end Intel(r) NIC, e.g: Intel(r) XL710.
> +
> +2. Make sure each NIC has flashed the latest version of NVM/firmware, 
> +if there
> is.
> +
> +3. Use PCIe Gen3 slots, such as Gen3 x8 or Gen3 x16 because PCIe Gen2 
> +slots
> can't provide enough bandwidth for 2x10G and above.
Pci gen2 x 8 may not provide enough, pci gen2 x 16 may support that.

> +
> +4. When inserting NICs to the PCI slots, be careful about the NUMA. 
> +If you will
+
> +Example
> +---
> +
> +Below is an case of running dpdk l3fwd sample to get high performance 
> +with
> Intel platform and NIC.
> +
> +**Note**: The scenario is to get best performance with two 
> +Intel(r)XL710 40G
> ports. See below Figure1 as the performance test setup.
> +
> +.. figure:: img/pf_performance_test_setup.*
> +
> +**Figure 1. PF_Performance_Test_setup**
> +
> +
> +1. Insert two NICs(Intel(r)XL710) into the platform, and use one port 
> +per card to
> get best performance. The reason using two NICs is the PCIe Gen3's 
> limitations.
> **Note**: As PCIe Gen3 can't provide 80G bandwidth for two 40G ports, 
> but two
Pci gen3 x 8 cannot provide 

[dpdk-dev] [PATCH v2] test: fix test_tlb_tx_burst

[Thomas Monjalon]

> Test failed on verification if number of bytes
> transmitted on each slave is not less than 90%
> and greater than 110% of mean value of bytes transmitted
> thru one slave. This was verified on a real system
> but is difficult to achieve using virtualpmd.
> That's why for unit tests only, it is sufficient to verify that with
> high load (2 seconds transsmission) all slaves are trasnitting
> so the traffic is balanced.
> 
> v2 changes:
> - improved description
> - reverted number of packets generated (in v1 it was decreased,
>   but to achieve balancing it has to be high load).
>   
> Signed-off-by: Michal Jastrzebski 

Fixes: 0c8396e6d786 ("bond: unit tests for mode 5")

Applied thanks

[dpdk-dev] [PATCH]doc: Add performance tuning guide about how to get DPDK high perf on Intel platform.

[Zhang, Helin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Monday, August 10, 2015 6:38 AM
> To: Xu, Qian Q
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH]doc: Add performance tuning guide about how
> to get DPDK high perf on Intel platform.
> 
> Hi,
> 
> Thanks for adding more helpful documentation.
> 
> 2015-08-10 14:34, Qian Xu:
> > Signed-off-by: Qian Xu 
> 
> The Sign-off line must be below the commit message.
> 
> > Add a new guide doc under guides folder. This document is a
> > step-by-step guide about how to get high performance with DPDK on Intel's
> platform and NICs.
> > It is designed for users who are not familiar with DPDK but would like
> > to measure the best performance. It contains step-by-step instructions to 
> > set
> the platform and NICs to its best performance.
> > The document will add more sections with the DPDK features' increment.
> > Currently, the document has only one section about PF performance test 
> > setup,
> and will add below cases in near future.
> >
> > *  VF performance tuning.
> > *  Vhost/virtio performance tuning.
> > *  new features
> 
> Good idea, thanks
> 
> > --- /dev/null
> > +++ b/doc/guides/perf_tuning_guide/img/pf_performance_test_setup.svg
> > +   > + width="609.375"
> > + height="349.6875"
> > + preserveAspectRatio="none"
> > + xlink:href="data:image/png;base64,
> 
> This is a PNG picture embedded in SVG.
> Please draw only some true SVG files.
> Inkscape is the preferred tool.
> 
> > +++ b/doc/guides/perf_tuning_guide/performance_tuning.rst
> 
> This file is Intel-specific. So it should be renamed
>   doc/guides/perf_tuning/intel_platform.rst
Agree with this.

> 
> > +This document is a step-by-step guide for getting high DPDK performance
> with Intel's platform and NICs.
> 
> Could it be specific to Intel's CPU but allows some chapters for other NICs 
> tuning
> (e.g. Chelsio, Cisco, Mellanox)?
> Ideally, the NIC tuning should refer to sections in doc/guides/nics/.
Yes, we want to have it as common as possible, and take Intel(r) NIC/Server as 
an example.

> 
> > +1. Get an high end Intel? NIC, e.g: Intel? XL710.
> 
> "Get an high end NIC that can sustain a high packet rate."?
Usually yes, talking about 1G is meaningless now, and 10G @ line rate is not so 
challenging
and complicated.
40G is more challenging, and complicated, so take it as an example.

> 
> > +2. Make sure each NIC has flashed the latest version of NVM/firmware, if
> there is.
> > +
> > +3. Use PCIe Gen3 slots, such as Gen3 x8 or Gen3 x16 because PCIe Gen2 slots
> can't provide enough bandwidth for 2x10G and above.
> 
> Could you describe how to get this characteristics with lspci?
> 
> > +4. When inserting NICs to the PCI slots, be careful about the NUMA. If you 
> > will
> use 2 or more ports from different NICs, please make sure these NICs on the
> same CPU socket.
> 
> Could you describe how to know the CPU-PCI mapping? lstopo, lspci?
Below there already have the descriptions.

> 
> > +BIOS settings:
> > +~~
> > +
> > +1. To be sure, reset all the BIOS settings to default.
> > +
> > +2. Disable all power saving options, and set all options for best 
> > performance.
> > +
> > +3. Disable Turbo to ensure the performance scaling with core numbers
> increment.
> > +
> > +4. Set memory frequency to the highest number, NOT auto.
> > +
> > +5. Disable all Virtualization options when you test physical function of 
> > NIC, and
> turn on VT-d if you wants to use VFIO.
> 
> Could you describe usage of dmidecode to check this, please?
> 
> > +1. Get an widely used 64 bits Linux distribution installed, e.g. Fedora 20 
> > - 64
> bits.
> 
> Why not describe build options and run-time options to use with any Linux?
Actually there is nothing special for performance testing, comparing to running
DPDK basically.
No need to duplicate here, as all the setup requirements are described in GSG.

> 
> > +3. Make sure the widely used and fully validated version of kernel 
> > installed,
> e.g. 3.18.
> 
> Reference to release notes required.
Agree with this.

> 
> > +4. Make sure the required components are enabled for some old version of
> kernels, before rebuilding the kernel. The kernel may need to be rebuilt if 
> any
> DPDK component is missing. Refer to Getting Started Guide on www.dpdk.org
> for more details.
> 
> Please use sphinx reference.
> 
> > +1. For Intel? 40G NICs, special configurations should be set before 
> > compiling it,
> as follows. **Note**: This is very important::
> > +
> > +  for at least DPDK release 1.8, 2.0 and 2.1, in
> /config/common_linuxapp
> > +  CONFIG_RTE_PCI_CONFIG=y
> > +  CONFIG_RTE_PCI_EXTENDED_TAG=?on?
> 
> Please insert it in a i40e doc instead of here. Then you can reference it.
Good idea!

Regards,
Helin

[dpdk-dev] [PATCH]doc: Add performance tuning guide about how to get DPDK high perf on Intel platform.

[Zhang, Helin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Qian Xu
> Sent: Sunday, August 9, 2015 11:35 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH]doc: Add performance tuning guide about how to
> get DPDK high perf on Intel platform.
> 
> Signed-off-by: Qian Xu 
> 
> Add a new guide doc under guides folder. This document is a step-by-step guide
> about how to get high performance with DPDK on Intel's platform and NICs.
> It is designed for users who are not familiar with DPDK but would like to 
> measure
> the best performance. It contains step-by-step instructions to set the 
> platform
> and NICs to its best performance.
> The document will add more sections with the DPDK features' increment.
> Currently, the document has only one section about PF performance test setup,
> and will add below cases in near future.
> 
> *  VF performance tuning.
> *  Vhost/virtio performance tuning.
> *  new features
> 
> 
> diff --git a/doc/guides/perf_tuning_guide/img/pf_performance_test_setup.svg
> b/doc/guides/perf_tuning_guide/img/pf_performance_test_setup.svg
> new file mode 100644
> index 000..50ce92d
> --- /dev/null
> +++ b/doc/guides/perf_tuning_guide/img/pf_performance_test_setup.svg
> @@ -0,0 +1,375 @@
> +
> +
> +
> + +   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:xlink="http://www.w3.org/1999/xlink";
> +   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd";
> +   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape";
> +   id="svg2"
> +   version="1.1"
> +   inkscape:version="0.91 r13725"
> +   width="609.375"
> +   height="349.6875"
> +   viewBox="0 0 609.375 349.6875"
> +   sodipodi:docname="Performance_test_setup.svg">
> +   + id="metadata8">
> +
> +   + rdf:about="">
> +image/svg+xml
> + +   rdf:resource="http://purl.org/dc/dcmitype/StillImage"; />
> +
> +  
> +
> +  
> +   + id="defs6" />
> +   + pagecolor="#ff"
> + bordercolor="#66"
> + borderopacity="1"
> + objecttolerance="10"
> + gridtolerance="10"
> + guidetolerance="10"
> + inkscape:pageopacity="0"
> + inkscape:pageshadow="2"
> + inkscape:window-width="1596"
> + inkscape:window-height="1108"
> + id="namedview4"
> + showgrid="false"
> + inkscape:zoom="0.56123077"
> + inkscape:cx="308.2511"
> + inkscape:cy="174.84375"
> + inkscape:window-x="0"
> + inkscape:window-y="27"
> + inkscape:window-maximized="1"
> + inkscape:current-layer="svg2" />
> +   + width="609.375"
> + height="349.6875"
> + preserveAspectRatio="none"
> +
> +xlink:href="data:image/png;base64,iVBORw0KGgoNSUhEUgAAAooAAAF1
> CAIAA
> +ADgOlyKAXNSR0IArs4c6QRnQU1BAACx
> +jwv8YQUJcEhZcwAADsMAAA7DAcdvqGQAAEUsSURBVHhe7d0JcBT3nS/w
> v3yA1htqkcx
> +l78qW
> +0AgjLHadxY84owBCCIOgEstOVlbWSSG24hF6rofGu6YCu7AyDxJIOVmPXGULydlF
> VHZjWS+xSVJI
> +HDKHeYy9xGych2BsNDqCtmxhsERCDvARvf/VPd093aM5ejQ9o++npobunp6r0cx
> 3ft3//v+
> +zxsbG
> +CDjJTfJfcAzEMwAAgOMgngEAABwH8QwAAOA4iGcAAADHQTwDAA
> A4DuIZAADAcRD
> +P
> +joN4BgAAcBzEMwAAgOMgngEAABwH8QwAAOA4iGcAAADHQTwDAAA4DuIZA
> ADAcRDPjoN
> +4BgAA
> +cBzEMwAAgOMgngEAABwH8QwAAOA4iGcAAADHQTwDAAA4DuIZAADAcRDPA
> AAAjoN4BgAAcBz
> +EMwAA
> +gOMgngEAABwH8QwAAOA4WWNjY3ISIEWysrLkFABAhoo1bVE9AwAAOA7iGQA
> AwHGwcxtST92
> +5jb9G
> +AMgwcX+/oXoGAABwHMQzAACA4yCeAQAAHAfxDAAA4DiIZwAAAMdBPAMA
> ADgO4hkAAMBxEM8
> +AMgwcX+AAACO
> +g3gGAABwHMQzAACA4yCeAQAAHCfBPrevNHme9/bJGaaiemwLqVtxYkHbhoY8
> uSxuwfY9RS8
> +Snx0P
> +BU6GPrcBIFOlss9tz47GsdeUy5ZiuTRBQydLV2wvGpjlkfMAAACTyATs3A7UrdieJS6
> 7AmJ
> +R167t
> +pe1XxLQGrcW31/n5xI6jJTT1DWHvfyVrxZ6mITkHAACQqZIdzzRxO3oef4LX1k/4Bj
> pEKlc
> +uW+gf
> +uKysoMb25fN9C6vcdGJGQ2tjC5vQcz8y9hp2dAMAQOazIZ5btynF8YpXuuQyhf91
> b9/CrTU
> +z+MyM
> +htqF/hdfZ+vkzXR3B9jEUKCjj5CBK0E67Q+0VhRXsjUBAAAmNXuPPT9iEq6FM4vkF
> E9lOVF
> +cXfjB
> +hSESPHWOPF7tI+cO0OmLH7gLZorbYXLKguSQ2xcA0kfyjz33Xe6VU7RWvsyOLDM
> z1paTjlO
> +hSESPHWOPF7tI+BA0dJ
> +dWmxZlrU2QAAAJNakuPZvdRXeHanbAV2pantrPvxpaLCdt01y3/0RAe5d20ecZXe
> S5RpAAA
> +ASEY8
> +F1dVXPLWiuPQMxpaq0tefJ4fmX7eW1B9Sh6Hpsld7Om7RMqLXXQ6r7iaXPIXzGD
> TEaDldqY
> +bA1vJ
> +zQoAaSjBbkkAbKAeHMVfo72wYQFSLu6PYfKPPQMAAECMEM8AAACOg3gGAAB
> wHMQzAACA4yC
> +eAQAA
> +HAfxDEl2/bqcAACAqCUYz3xAC9nhNrvw8aZsoY5eJac1zxLx1Gd2brSypjJAVrhg+57
> Ij5P
> +4CkCG
> +h8mTT5KHH5azAAAQNRuq51Cf223lPdtMR4qMxGJwSaPQs+yYpfR5Eu5K04mZv
> WK116o93R0
> +h8mTT5KHH5azAAAQNRuq51Cf223lPdtMR4qMxGJwSaPQs+mPxfG
> +HUk68RVABHNBAfH5UD0DAMTB1p3beUtO7VDGpGJCIz2rMUnDWKluWelJZ9d0
> Ez/rVizqSpR
> +3FLqf
> +PqBJJ2IzGrYsUboeK66qID0XDcFvMZJ0SOIrTG4IZgAAO9h97Nld7CFsKCqezepIz9V
> kG89
> +R/ytr
> +BsqV6paN3Fy5pbGzgrjZarEP5DzO8M+B/d2k5C7DGBsWI0mHJL7CZIVgBgCwTzKa
> hl06z5I
> +BsqV6paN3Fy5pbGzgrjZarEP5DzO8M+40FpY
> +vk/2

[dpdk-dev] [PATCH 2/2] mem: fix freeing an IVSHMEM memzone

[Thomas Monjalon]

2015-08-07 16:27, Sergio Gonzalez Monroy:
> There is no sync between host and guest to allow removal of memzones,
> and freeing them result in undefined behavior.
> 
> In the guest, we identify IVSHMEM memsegs/memzones by having
> ioremap_addr != 0. In the host, nothing is done to the memzone, meaning
> ioremap_addr == 0.
> 
> As a solution, mark memzones being added to IVSHMEM in the host, by
> setting ioremap_addr, then return an error whenever we try to free an
> IVSHMEM memzone.
> 
> Fixes: ff909fe21f0 ("mem: introduce memzone freeing")
> 
> Signed-off-by: Sergio Gonzalez Monroy 

Series applied, thanks

[dpdk-dev] How to do packet mirroring

[Masoud Moshref Javadi]

Hi

I want to know how the pool mirroring works in dpdk.
Can I only mirror to another physical port or I can make NIC mirror 
packets to an application running on the server?
What I want is to just monitor every packet received or sent from the NIC.


I wanted to test the feature using testpmd using
set port 0 mirror-rule 0 pool-mirror 0x8 dst-pool 1 on
but it says "ixgbe_vmdq_mode_check(): VMDq must be enabled for this setting"
I'm using 82599 10G NIC with two ports on DPDK 2.0

Thanks

[dpdk-dev] [PATCH]doc: Add performance tuning guide about how to get DPDK high perf on Intel platform.

[Thomas Monjalon]

Hi,

Thanks for adding more helpful documentation.

2015-08-10 14:34, Qian Xu:
> Signed-off-by: Qian Xu 

The Sign-off line must be below the commit message.

> Add a new guide doc under guides folder. This document is a step-by-step 
> guide about how to get high performance with
> DPDK on Intel's platform and NICs.
> It is designed for users who are not familiar with DPDK but would like to 
> measure the best performance. It contains
> step-by-step instructions to set the platform and NICs to its best 
> performance.
> The document will add more sections with the DPDK features' increment.
> Currently, the document has only one section about PF performance test setup, 
> and will add below cases in near future.
> 
> *  VF performance tuning.
> *  Vhost/virtio performance tuning.
> *  new features

Good idea, thanks

> --- /dev/null
> +++ b/doc/guides/perf_tuning_guide/img/pf_performance_test_setup.svg
> +   + width="609.375"
> + height="349.6875"
> + preserveAspectRatio="none"
> + xlink:href="data:image/png;base64,

This is a PNG picture embedded in SVG.
Please draw only some true SVG files.
Inkscape is the preferred tool.

> +++ b/doc/guides/perf_tuning_guide/performance_tuning.rst

This file is Intel-specific. So it should be renamed
doc/guides/perf_tuning/intel_platform.rst

> +This document is a step-by-step guide for getting high DPDK performance with 
> Intel's platform and NICs.

Could it be specific to Intel's CPU but allows some chapters for other NICs
tuning (e.g. Chelsio, Cisco, Mellanox)?
Ideally, the NIC tuning should refer to sections in doc/guides/nics/.

> +1. Get an high end Intel? NIC, e.g: Intel? XL710.

"Get an high end NIC that can sustain a high packet rate."?

> +2. Make sure each NIC has flashed the latest version of NVM/firmware, if 
> there is.
> +
> +3. Use PCIe Gen3 slots, such as Gen3 x8 or Gen3 x16 because PCIe Gen2 slots 
> can't provide enough bandwidth for 2x10G and above.

Could you describe how to get this characteristics with lspci?

> +4. When inserting NICs to the PCI slots, be careful about the NUMA. If you 
> will use 2 or more ports from different NICs, please make sure these NICs on 
> the same CPU socket.

Could you describe how to know the CPU-PCI mapping? lstopo, lspci?

> +BIOS settings:
> +~~
> +
> +1. To be sure, reset all the BIOS settings to default.
> +
> +2. Disable all power saving options, and set all options for best 
> performance.
> +
> +3. Disable Turbo to ensure the performance scaling with core numbers 
> increment.
> +
> +4. Set memory frequency to the highest number, NOT auto.
> +
> +5. Disable all Virtualization options when you test physical function of 
> NIC, and turn on VT-d if you wants to use VFIO.

Could you describe usage of dmidecode to check this, please?

> +1. Get an widely used 64 bits Linux distribution installed, e.g. Fedora 20 - 
> 64 bits.

Why not describe build options and run-time options to use with any Linux?

> +3. Make sure the widely used and fully validated version of kernel 
> installed, e.g. 3.18.

Reference to release notes required.

> +4. Make sure the required components are enabled for some old version of 
> kernels, before rebuilding the kernel. The kernel may need to be rebuilt if 
> any DPDK component is missing. Refer to Getting Started Guide on www.dpdk.org 
> for more details.

Please use sphinx reference.

> +1. For Intel? 40G NICs, special configurations should be set before 
> compiling it, as follows. **Note**: This is very important::
> +
> +  for at least DPDK release 1.8, 2.0 and 2.1, in 
> /config/common_linuxapp
> +  CONFIG_RTE_PCI_CONFIG=y
> +  CONFIG_RTE_PCI_EXTENDED_TAG=?on?

Please insert it in a i40e doc instead of here. Then you can reference it.

[dpdk-dev] [PATCH]doc: Add performance tuning guide about how to get DPDK high perf on Intel platform.

[Qian Xu]

Signed-off-by: Qian Xu 

Add a new guide doc under guides folder. This document is a step-by-step guide 
about how to get high performance with
DPDK on Intel's platform and NICs.
It is designed for users who are not familiar with DPDK but would like to 
measure the best performance. It contains
step-by-step instructions to set the platform and NICs to its best performance.
The document will add more sections with the DPDK features' increment.
Currently, the document has only one section about PF performance test setup, 
and will add below cases in near future.

*  VF performance tuning.
*  Vhost/virtio performance tuning.
*  new features


diff --git a/doc/guides/perf_tuning_guide/img/pf_performance_test_setup.svg 
b/doc/guides/perf_tuning_guide/img/pf_performance_test_setup.svg
new file mode 100644
index 000..50ce92d
--- /dev/null
+++ b/doc/guides/perf_tuning_guide/img/pf_performance_test_setup.svg
@@ -0,0 +1,375 @@
+
+
+
+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:xlink="http://www.w3.org/1999/xlink";
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd";
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape";
+   id="svg2"
+   version="1.1"
+   inkscape:version="0.91 r13725"
+   width="609.375"
+   height="349.6875"
+   viewBox="0 0 609.375 349.6875"
+   sodipodi:docname="Performance_test_setup.svg">
+  
+
+  
+image/svg+xml
+http://purl.org/dc/dcmitype/StillImage"; />
+
+  
+
+  
+  
+  
+  
+
diff --git a/doc/guides/perf_tuning_guide/index.rst 
b/doc/guides/perf_tuning_guide/index.rst
new file mode 100644
index 000..ff325e9
--- /dev/null
+++ b/doc/guides/perf_tuning_guide/index.rst
@@ -0,0 +1,47 @@
+..  BSD LICENSE
+Copyright(c) 2010-2015 Intel Corporation. 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.
+
+Performance Tuning Guide for Intel's platform
+=
+
+|today|
+
+Contents
+
+.. toctree::
+:maxdepth: 2
+:numbered:
+
+intro
+performance_tuning
+
+
+
+
diff --git a/doc/guides/perf_tuning_guide/intro.rst 
b/doc/guides/perf_tuning_guide/intro.rst
new file mode 100644
index 000..5672549
--- /dev/null
+++ b/doc/guides/perf_tuning_guide/intro.rst
@@ -0,0 +1,44 @@
+..  BSD LICENSE
+Copyright(c) 2010-2015 Intel Corporation. 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, T

[dpdk-dev] [PATCH v1] Change rte_eal_vdev_init to update port_id

[Tetsuya Mukawa]

On 2015/08/08 7:06, Ravi Kerur wrote:
> Hi Tetsuya,
>
> On Thu, Aug 6, 2015 at 7:25 PM, Tetsuya Mukawa  > wrote:
>
> On 2015/08/07 3:04, Ravi Kerur wrote:
> > diff --git a/drivers/net/enic/enic_ethdev.c
> b/drivers/net/enic/enic_ethdev.c
> > index 8280cea..472ef5a 100644
> > --- a/drivers/net/enic/enic_ethdev.c
> > +++ b/drivers/net/enic/enic_ethdev.c
> > @@ -36,8 +36,8 @@
> >  #include 
> >  #include 
> >
> > -#include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
>
> Hi Ravi,
>
> Do we need this fixing?
>
> >
> > diff --git a/drivers/net/mpipe/mpipe_tilegx.c
> b/drivers/net/mpipe/mpipe_tilegx.c
> > index 743feef..6e3e304 100644
> > --- a/drivers/net/mpipe/mpipe_tilegx.c
> > +++ b/drivers/net/mpipe/mpipe_tilegx.c
> > @@ -1582,6 +1582,7 @@ rte_pmd_mpipe_devinit(const char *ifname,
> >   if (!eth_dev) {
> >   RTE_LOG(ERR, PMD, "%s: Failed to allocate
> device.\n", ifname);
> >   rte_free(priv);
> > + return -ENOMEM;
>
> How about separating this fixing from the patch, and put it as an
> one of
> cleanup patch series?
>
>
> rte_pmd_mpipe_devinit is the init func pointer called via
> rte_eal_vdev_init. Since we were fixing rte_eal_vdev_init thought of
> taking care of mpipe issue. If you think it's unrelated to this patch
> I will send a separate one.
>

Hi Ravi,

To avoid segmentation fault like above has a point, even if rest of this
patch won't be applied.
So I guess it's nice to separate the patch.


Thanks,
Tetsuya

[dpdk-dev] [dpdk-dev,3/3] acl: mark deprecated functions

[Butler, Siobhan A]

Hi Stephen
Would you be able to patch in some notices to the Depreciation section of the 
documentation for these changes?
Thanks
Siobhan

[dpdk-dev] Performance of rte_ring APIs

[Bruce Richardson]

On Fri, Aug 07, 2015 at 10:07:07AM -0700, Gopakumar Choorakkot Edakkunni wrote:
> Hi All,
> 
> I have an extremely simple test - I have just one single DPDK EAL
> thread which pulls packets from one 10G port and just puts the packet
> exactly as is (no changes) on another 10G port - I get 9.5million pps,
> so far so good. So its like this
> 
> dpdk_rx
> dpdk_tx
> 
> 9.5 Millionpps
> 
> Now I do the below and the performance comes down to like 4 Million
> pps, less than half !
> 
> dpdk_rx
> rte_ring_mc_dequeue_bulk(my_ring1, my_array, nb_rx)
> dpdk_tx
> rte_ring_mp_enqueue_bulk(my_ring1, my_array, nb_rx)
> 
> Note that I do nothing with the things I dequeue from the ring, I just
> enqueue it back. So is there any gotchas in using these rings ? I am
> sure I am missing something, it cant drop from 9.5Mpps to 4Mpps just
> because of a dequeue/enqueue ?
> 
You are using the multi-producer and multi-consumer ring functions, which tend 
to
be much more expensive than the single producer single consumer function. 
Depending
on the contention on those rings, performance can vary considerably in your 
application.

/Bruce

[dpdk-dev] TX-packet counter increased when no packets were actually sent

[Bruce Richardson]

On Thu, Aug 06, 2015 at 02:46:53PM +0200, Stefan Binna wrote:
> Hi,
> 
> I have created a little testbed for DPDK testing.
> 
> NIC: Intel Gigabit 82574L (1-port)
> 
> The testbed for DPDK has following structure:
> 
> 1) al40-118 (10.100.40.118/24): DUT running the DPDK application
> 2) al40-119 (10.100.40.119/24): Used for sending traffic to al40-118
> 3) al40-111 (10.100.40.111/24): Used to sniff the traffic send on the
> network
> 
> All three devices are connected via a hub and use the network
> 10.100.40.1/24.
> 
> *Test:* Ping the DUT and review network traffic
> 

The use of ping implies the presence of an IP protocol stack to respond to
that ping. Testpmd included no protocol stack support so can't respond to the
ping request.

> At al40-119 an ARP-Table-Entry was created and the device al40-118 was
> pinged:
> 
> arp -s 10.100.40.118 68:05:ca:37:51:75
> ping 10.100.40.118
> 
> On al40-118 the application testpmd was started with following parameters:
> 
> ./x86_64-native-linuxapp-gcc/build/app/test-pmd/testpmd -c 0xf -n 4 -- -i 
> --portmask=0x1 --nb-cores=2 --port-topology=chained
> 
> After start of the testpmd application the ports were started and after a
> while stopped:
> 
> start #wait a while due to testduration
> stop
> 
> What's interesting is, that the TX-packet counter in the output of the
> "stop" command had the same value as the RX-packet counter. But the actual
> traffic on the network sniffed with Wireshark only showed the ping request
> but never a response on any layer (not even L2).
> 
> Sample output of the "stop" command:
> 
> Telling cores to stop...
> Waiting for lcores to finish...
> 
>   -- Forward statistics for port 0  --
>   RX-packets: 2  RX-dropped: 0 RX-total: 2
>   TX-packets: 2  TX-dropped: 0 TX-total: 2
>   
> 
>   +++ Accumulated forward statistics for all ports+++
>   RX-packets: 2  RX-dropped: 0 RX-total: 2
>   TX-packets: 2  TX-dropped: 0 TX-total: 2
>   
> 
> Done.
> Stopping port 0...done
> 
> Could you tell me why the TX-packet counter increased when actually no
> packets were sent out to the 10.100.40.1 network or in other words, where
> have the packets been sent out?

Packets were sent out by the DUT. However, those packets weren't ping responses,
they were the ping requests themselves being forwarded. That's why they showed
up in your wireshark track on the receiving side.

/Bruce

[dpdk-dev] [PATCH] rte_ethdev: whitespace cleanup

[Stephen Hemminger]

From: Stephen Hemminger 

Cleanup whitespace and other trivial warnings from checkpatch.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_ether/rte_ethdev.h | 54 +--
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 544afe0..b2ff337 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -244,7 +244,7 @@ struct rte_eth_link {
uint16_t link_speed;  /**< ETH_LINK_SPEED_[10, 100, 1000, 1] */
uint16_t link_duplex; /**< ETH_LINK_[HALF_DUPLEX, FULL_DUPLEX] */
uint8_t  link_status : 1; /**< 1 -> link up, 0 -> link down */
-}__attribute__((aligned(8))); /**< aligned for atomic64 read/write */
+} __attribute__((aligned(8))); /**< aligned for atomic64 read/write */

 #define ETH_LINK_SPEED_AUTONEG  0   /**< Auto-negotiate link speed. */
 #define ETH_LINK_SPEED_10   10  /**< 10 megabits/second. */
@@ -746,7 +746,7 @@ enum rte_l4type {
  */
 enum rte_iptype {
RTE_FDIR_IPTYPE_IPV4 = 0, /**< IPv4. */
-   RTE_FDIR_IPTYPE_IPV6 ,/**< IPv6. */
+   RTE_FDIR_IPTYPE_IPV6, /**< IPv6. */
 };

 /**
@@ -864,7 +864,7 @@ struct rte_eth_conf {
struct rte_eth_rxmode rxmode; /**< Port RX configuration. */
struct rte_eth_txmode txmode; /**< Port TX configuration. */
uint32_t lpbk_mode; /**< Loopback operation mode. By default the value
-is 0, meaning the loopback mode is disabled.
+is 0, meaning the loopback mode is disabled.
 Read the datasheet of given ethernet controller
 for details. The possible values of this field
 are defined in implementation of each driver. 
*/
@@ -1454,15 +1454,15 @@ struct eth_dev_ops {
/**< Set eeprom */
   /* bypass control */
 #ifdef RTE_NIC_BYPASS
-  bypass_init_t bypass_init;
-  bypass_state_set_t bypass_state_set;
-  bypass_state_show_t bypass_state_show;
-  bypass_event_set_t bypass_event_set;
-  bypass_event_show_t bypass_event_show;
-  bypass_wd_timeout_set_t bypass_wd_timeout_set;
-  bypass_wd_timeout_show_t bypass_wd_timeout_show;
-  bypass_ver_show_t bypass_ver_show;
-  bypass_wd_reset_t bypass_wd_reset;
+   bypass_init_t bypass_init;
+   bypass_state_set_t bypass_state_set;
+   bypass_state_show_t bypass_state_show;
+   bypass_event_set_t bypass_event_set;
+   bypass_event_show_t bypass_event_show;
+   bypass_wd_timeout_set_t bypass_wd_timeout_set;
+   bypass_wd_timeout_show_t bypass_wd_timeout_show;
+   bypass_ver_show_t bypass_ver_show;
+   bypass_wd_reset_t bypass_wd_reset;
 #endif

/** Configure RSS hash protocols. */
@@ -1628,10 +1628,10 @@ struct rte_eth_dev_data {
/**< Common rx buffer size handled by all queues */

uint64_t rx_mbuf_alloc_failed; /**< RX ring mbuf allocation failures. */
-   struct ether_addr* mac_addrs;/**< Device Ethernet Link address. */
+   struct ether_addr *mac_addrs; /**< Device Ethernet Link address. */
uint64_t mac_pool_sel[ETH_NUM_RECEIVE_MAC_ADDR];
/** bitmap array of associating Ethernet MAC addresses to pools */
-   struct ether_addr* hash_mac_addrs;
+   struct ether_addr *hash_mac_addrs;
/** Device Ethernet MAC addresses of hash filtering. */
uint8_t port_id;   /**< Device [external] port identifier. */
uint8_t promiscuous   : 1, /**< RX promiscuous mode ON(1) / OFF(0). */
@@ -2342,7 +2342,7 @@ extern int rte_eth_dev_set_mtu(uint8_t port_id, uint16_t 
mtu);
  *   - (-ENOSYS) if VLAN filtering on *port_id* disabled.
  *   - (-EINVAL) if *vlan_id* > 4095.
  */
-extern int rte_eth_dev_vlan_filter(uint8_t port_id, uint16_t vlan_id , int on);
+extern int rte_eth_dev_vlan_filter(uint8_t port_id, uint16_t vlan_id, int on);

 /**
  * Enable/Disable hardware VLAN Strip by a rx queue of an Ethernet device.
@@ -2563,10 +2563,10 @@ extern uint32_t rte_eth_rx_queue_count(uint8_t port_id, 
uint16_t queue_id);
 static inline uint32_t
 rte_eth_rx_queue_count(uint8_t port_id, uint16_t queue_id)
 {
-struct rte_eth_dev *dev;
+   struct rte_eth_dev *dev;

-dev = &rte_eth_devices[port_id];
-return (*dev->dev_ops->rx_queue_count)(dev, queue_id);
+   dev = &rte_eth_devices[port_id];
+   return (*dev->dev_ops->rx_queue_count)(dev, queue_id);
 }
 #endif

@@ -2595,8 +2595,8 @@ rte_eth_rx_descriptor_done(uint8_t port_id, uint16_t 
queue_id, uint16_t offset)
struct rte_eth_dev *dev;

dev = &rte_eth_devices[port_id];
-   return (*dev->dev_ops->rx_descriptor_done)( \
-   dev->data->rx_queues[queue_id], offset);
+   return (*dev->dev_ops->rx_descriptor_done)
+   (dev->data->rx_queues[queue_id], offset);
 }
 #endif

@@ -2911,8 +2911,8 @@ enum rte_eth_event_ty

[dpdk-dev] [PATCH] vchost: Notify application of ownership change

[Jan Kiszka]

On 2015-08-10 03:20, Ouyang, Changchun wrote:
>> -Original Message-
>> From: Jan Kiszka [mailto:jan.kiszka at siemens.com]
>> Sent: Saturday, August 8, 2015 2:43 PM
>> To: Ouyang, Changchun; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] vchost: Notify application of ownership
>> change
>>
>> On 2015-08-08 02:25, Ouyang, Changchun wrote:
>>>
>>>
 -Original Message-
 From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jan Kiszka
 Sent: Saturday, August 8, 2015 1:21 AM
 To: dev at dpdk.org
 Subject: [dpdk-dev] [PATCH] vchost: Notify application of ownership
 change
>>>
>>> Vchost should be vhost in the title
>>
>> Oops. Unless I need to resend for some other reason, I guess the commit can
>> fix this up.
>>
>>>

 On VHOST_*_RESET_OWNER, we reinitialize the device but without
 telling the application. That will cause crashes when it continues to
 invoke vhost services on the device. Fix it by calling the
 destruction hook if the device is still in use.
>>> What's your qemu version?
>>
>> git head, see my other reply for details.
>>
>>> Any validation work on this patch?
>>
>> What do you mean with this? Test cases? Or steps to reproduce? For the
>> latter, just fire up a recent qemu, let the guest enable the virtio device, 
>> then
>> reboot or simply terminate qemu.
> 
> Here, I mean test case, 
> Need make sure the change works on both qemu 2.4(with the reset commit in 
> qemu) and qemu2.2/2.3(without the commit in qemu).
> 

I suspect, 2.2 and 2.3 stable have this fix queued already. If not, we
should trigger this. The previous versions were subtly broken and
shouldn't be used for production purposes.

>>

 Signed-off-by: Jan Kiszka 
 ---

 This is the surprisingly simple answer to my questions in
 http://thread.gmane.org/gmane.comp.networking.dpdk.devel/22661.

  lib/librte_vhost/virtio-net.c | 3 +++
  1 file changed, 3 insertions(+)

 diff --git a/lib/librte_vhost/virtio-net.c
 b/lib/librte_vhost/virtio-net.c index
 b520ec5..3c5b5b2 100644
 --- a/lib/librte_vhost/virtio-net.c
 +++ b/lib/librte_vhost/virtio-net.c
 @@ -402,6 +402,9 @@ reset_owner(struct vhost_device_ctx ctx)

ll_dev = get_config_ll_entry(ctx);

 +  if ((ll_dev->dev.flags & VIRTIO_DEV_RUNNING))
 +  notify_ops->destroy_device(&ll_dev->dev);
 +
>>>
>>> I am not sure whether destroy_device here will affect the second time
>> init_device(below) and new_device(after the reset) or not.
>>> Need validation.
>>
>> Cannot follow, what do you mean with "second time"? If the callback could
>> invoke something that causes cleanup_device to be called as well?
>> That's at least not the case with vhost-switch, but I'm far from being 
>> familiar
>> with the API to asses if that is possible in general.
> 
> RESET is often followed by a second time virtio device creation. 
> If you have chance to run testpmd with virtio PMD on guest, that would be 
> that case:
> Call RESET, and then create virtio device again to make it work for packets 
> rx/tx 

OK, need to dig into this, probably not the next days, though.

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

[dpdk-dev] Crash when 'ifconfig vEth0 X.X.X.X'

[Hyun Yoo]

After kni, I want to wake vEth0 up automatically.
so, I executed 'ifconfig vEth0 X.X.X.X' programatically with various ways.

A) put system('ifconfig...)' right after check_all_ports_link_status() in
main()  examples/kni/main.c
B) put system('ifconfig...)' in callback using
rte_eth_dev_callback_register().
C) in shell script,
examples/kni/build/kni &
for loop
  ifconfig ...

In either ways, linux crashes sometimes.
No keyboard, mouse works. I have to reboot.
There was usually no error message but once time I saw something about irq
balance...
It seems ifconfig shouldn't be run right after(or before) link is up, maybe.

Has anyone experienced the same?

I'm using DPDK 2.0.0 on RHEL 6.5 (kernel 2.6.32).

[dpdk-dev] [PATCH] testpmd: modify the mac of csum forwarding

[Qiu, Michael]

On 2015/8/7 17:13, Ouyang, Changchun wrote:
>
>>

[.../...]

>>
>>  eth_hdr = rte_pktmbuf_mtod(m, struct ether_hdr *);
>> +ether_addr_copy(&peer_eth_addrs[fs->peer_addr],
>> +ð_hdr->d_addr);
>> +ether_addr_copy(&ports[fs->tx_port].eth_addr,
>> +ð_hdr->s_addr);
>> Is it really necessary? Why other NICs do not need this?
>>
> Seems the behavior changes from io fwd into mac fwd?

Yes, but I think it is no influence for checksum offload.

Thanks,
Michael
>>> parse_ethernet(eth_hdr, &info);
>>> l3_hdr = (char *)eth_hdr + info.l2_len;
>>>
>>> --
>>> 1.9.3
>

[dpdk-dev] [PATCH v3 1/1] bonding: fix device initialisation error handling

[Thomas Monjalon]

> > If the name parameter to rte_eth_bond_create() was NULL,
> > there was a segmentation fault because eth_dev was also NULL.
> > Add error handling of mac_addrs memory allocation.
> > Add call to rte_eth_dev_release_port() in error handling.
> > 
> > Signed-off-by: Bernard Iremonger 
> Acked-by: Michal Jastrzebski 

Applied, thanks

[dpdk-dev] [PATCH v2] bonding: 8023ad: fix incorrect typecast of socket

[Thomas Monjalon]

> > On slave activation in LACP (8023AD) SOCKET_ANY_ID (which is -1)
> > is being casted to unsigned char and then to signed int.
> > The result is that socket_id has value of 255, not -1.
> > This results to memory allocation failure.
> > 
> > Signed-off-by: Sergey Balabanov 
> 
> Acked-by: Pablo de Lara 

Fixes: 46fb43683679 ("bond: add mode 4")

Applied, thanks

Please Sergey, do not set the status as "Accepted" yourself in patchwork.
The "Accepted" status means that it has been applied. Setting it before could
result in having your patch forgotten.

[dpdk-dev] [PATCH] vchost: Notify application of ownership change

[Ouyang, Changchun]

> -Original Message-
> From: Jan Kiszka [mailto:jan.kiszka at siemens.com]
> Sent: Saturday, August 8, 2015 2:43 PM
> To: Ouyang, Changchun; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] vchost: Notify application of ownership
> change
> 
> On 2015-08-08 02:25, Ouyang, Changchun wrote:
> >
> >
> >> -Original Message-
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jan Kiszka
> >> Sent: Saturday, August 8, 2015 1:21 AM
> >> To: dev at dpdk.org
> >> Subject: [dpdk-dev] [PATCH] vchost: Notify application of ownership
> >> change
> >
> > Vchost should be vhost in the title
> 
> Oops. Unless I need to resend for some other reason, I guess the commit can
> fix this up.
> 
> >
> >>
> >> On VHOST_*_RESET_OWNER, we reinitialize the device but without
> >> telling the application. That will cause crashes when it continues to
> >> invoke vhost services on the device. Fix it by calling the
> >> destruction hook if the device is still in use.
> > What's your qemu version?
> 
> git head, see my other reply for details.
> 
> > Any validation work on this patch?
> 
> What do you mean with this? Test cases? Or steps to reproduce? For the
> latter, just fire up a recent qemu, let the guest enable the virtio device, 
> then
> reboot or simply terminate qemu.

Here, I mean test case, 
Need make sure the change works on both qemu 2.4(with the reset commit in qemu) 
and qemu2.2/2.3(without the commit in qemu).

> 
> >>
> >> Signed-off-by: Jan Kiszka 
> >> ---
> >>
> >> This is the surprisingly simple answer to my questions in
> >> http://thread.gmane.org/gmane.comp.networking.dpdk.devel/22661.
> >>
> >>  lib/librte_vhost/virtio-net.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/lib/librte_vhost/virtio-net.c
> >> b/lib/librte_vhost/virtio-net.c index
> >> b520ec5..3c5b5b2 100644
> >> --- a/lib/librte_vhost/virtio-net.c
> >> +++ b/lib/librte_vhost/virtio-net.c
> >> @@ -402,6 +402,9 @@ reset_owner(struct vhost_device_ctx ctx)
> >>
> >>ll_dev = get_config_ll_entry(ctx);
> >>
> >> +  if ((ll_dev->dev.flags & VIRTIO_DEV_RUNNING))
> >> +  notify_ops->destroy_device(&ll_dev->dev);
> >> +
> >
> > I am not sure whether destroy_device here will affect the second time
> init_device(below) and new_device(after the reset) or not.
> > Need validation.
> 
> Cannot follow, what do you mean with "second time"? If the callback could
> invoke something that causes cleanup_device to be called as well?
> That's at least not the case with vhost-switch, but I'm far from being 
> familiar
> with the API to asses if that is possible in general.

RESET is often followed by a second time virtio device creation. 
If you have chance to run testpmd with virtio PMD on guest, that would be that 
case:
Call RESET, and then create virtio device again to make it work for packets 
rx/tx 

> 
> Jan
> 
> >
> >>cleanup_device(&ll_dev->dev);
> >>init_device(&ll_dev->dev);
> >>
> >> --
> >> 2.1.4
> 
> 
> --
> Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate
> Competence Center Embedded Linux

[dpdk-dev] vhost-switch example: huge memory need and CRC off-loading issue

[Ouyang, Changchun]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Sunday, August 9, 2015 4:56 PM
> To: Jan Kiszka
> Cc: dev at dpdk.org; Ouyang, Changchun
> Subject: Re: [dpdk-dev] vhost-switch example: huge memory need and CRC
> off-loading issue
> 
> 2015-08-08 09:17, Jan Kiszka:
> > On 2015-08-08 02:39, Ouyang, Changchun wrote:
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jan Kiszka
> > >> - MAX_QUEUES of 512 causes pretty high memory need for the
> application
> > >>   (something between 1 and 2G) - is that really needed? I'm now running
> > >>   with 32, and I'm able to get away with 256M. Can we tune this
> > >>   default?
> > >
> > > Don't think we need change default just because your platform is 32,
> > > Well, my platform is 128, other platform may have other value, :-)
> >
> > Then let's make it configurable or explore the actual device needs
> > before allocating the buffer. The impact on memory consumption is way
> > too big to hard-code this, specifically as this is per physical port IIUC.
> 
> You can add a run-time option and/or add a comment in the documentation.
> It is just an example, so it must be simple to understand.

Agree, that is better than changing the default macro value.