* Re: [PATCH v2 09/12] doc/armv8: update documentation about crypto PMD
From: Mcnamara, John @ 2016-12-07 21:13 UTC (permalink / raw)
To: zbigniew.bodek@caviumnetworks.com, De Lara Guarch, Pablo,
jerin.jacob@caviumnetworks.com
Cc: dev@dpdk.org
In-Reply-To: <1481077985-4224-10-git-send-email-zbigniew.bodek@caviumnetworks.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of
> zbigniew.bodek@caviumnetworks.com
> Sent: Wednesday, December 7, 2016 2:33 AM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>;
> jerin.jacob@caviumnetworks.com
> Cc: dev@dpdk.org; Zbigniew Bodek <zbigniew.bodek@caviumnetworks.com>
> Subject: [dpdk-dev] [PATCH v2 09/12] doc/armv8: update documentation about
> crypto PMD
>
> From: Zbigniew Bodek <zbigniew.bodek@caviumnetworks.com>
>
> Add documentation about the driver and update release notes.
>
> Signed-off-by: Zbigniew Bodek <zbigniew.bodek@caviumnetworks.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
* Re: [PATCH v2] doc: introduce PVP reference benchmark
From: Mcnamara, John @ 2016-12-07 21:07 UTC (permalink / raw)
To: Maxime Coquelin, yuanhan.liu@linux.intel.com,
thomas.monjalon@6wind.com, Yang, Zhiyong, ktraynor@redhat.com,
dev@dpdk.org
In-Reply-To: <20161206122440.12039-1-maxime.coquelin@redhat.com>
> -----Original Message-----
> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
> Sent: Tuesday, December 6, 2016 12:25 PM
> To: yuanhan.liu@linux.intel.com; thomas.monjalon@6wind.com; Mcnamara, John
> <john.mcnamara@intel.com>; Yang, Zhiyong <zhiyong.yang@intel.com>;
> ktraynor@redhat.com; dev@dpdk.org
> Cc: Maxime Coquelin <maxime.coquelin@redhat.com>
> Subject: [PATCH v2] doc: introduce PVP reference benchmark
>
> 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>
There is one trailing whitespace warning but apart from that:
Acked-by: John McNamara <john.mcnamara@intel.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
* Re: [PATCH v10] drivers/net:new TUN/TAP device PMD
From: Aws Ismail @ 2016-12-07 20:15 UTC (permalink / raw)
To: Keith Wiles; +Cc: DPDK, pmatilai, yuanhan.liu, Ferruh Yigit, john.mcnamara
In-Reply-To: <20161207193844.41193-1-keith.wiles@intel.com>
On Wed, Dec 7, 2016 at 2:38 PM, Keith Wiles <keith.wiles@intel.com> wrote:
>
> Signed-off-by: Keith Wiles <keith.wiles@intel.com>
Tested-by: Aws Ismail <aismail@ciena.com>
^ permalink raw reply
* Re: [PATCH] vdev: fix missing alias check on uninit
From: Thomas Monjalon @ 2016-12-07 20:14 UTC (permalink / raw)
To: Anatoly Burakov; +Cc: dev, stable
In-Reply-To: <de4afc1a1893b9de27903088f7083805c088662f.1479486605.git.anatoly.burakov@intel.com>
2016-11-18 16:32, Anatoly Burakov:
> Fixes: d63eed6b2dca ("eal: add driver name alias")
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
CC: stable@dpdk.org
Applied, thanks
^ permalink raw reply
* Re: [RFC] ethdev: abstraction layer for QoS hierarchical scheduler
From: Dumitrescu, Cristian @ 2016-12-07 20:13 UTC (permalink / raw)
To: Thomas Monjalon, Stephen Hemminger
Cc: dev@dpdk.org, Hemant Agrawal, Shreyansh Jain, Jerin Jacob,
adrien.mazarguil@6wind.com, Olga Shern, Ajit Khaparde,
Rahul Lakkireddy, Alejandro Lucero
In-Reply-To: <2204708.uGZ3ieR731@xps13>
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Tuesday, December 6, 2016 10:14 PM
> To: Stephen Hemminger <stephen@networkplumber.org>
> Cc: dev@dpdk.org; Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Subject: Re: [dpdk-dev] [RFC] ethdev: abstraction layer for QoS hierarchical
> scheduler
>
> 2016-12-06 11:51, Stephen Hemminger:
> > Rather than reinventing wheel which seems to be DPDK Standard
> > Procedure, could an existing abstraction be used?
>
> Stephen, you know that the DPDK standard procedure is to consider
> reviews and good comments ;)
Thomas, sorry for not CC-ing you (as the librte_ether maintainer) when
the initial RFC was sent out, comments from you would be welcomed and
much appreciated as well!
Also same kind reminder for other people in the community as well.
(CC-ing just a few). Some of you have expressed interest in the past for
building an abstraction layer for QoS hierarchical scheduler, so here is the
RFC for it which we can evolve together. Let's make sure we build a robust
layer that fits well for all devices and vendors that are part of the DPDK
community!
^ permalink raw reply
* Re: [PATCH v2 02/12] lib: add cryptodev type for the upcoming ARMv8 PMD
From: Thomas Monjalon @ 2016-12-07 20:09 UTC (permalink / raw)
To: Zbigniew Bodek
Cc: dev, zbigniew.bodek, pablo.de.lara.guarch, jerin.jacob,
declan.doherty
In-Reply-To: <2cec934f-b645-be28-8e82-a271692260d0@caviumnetworks.com>
2016-12-07 20:04, Zbigniew Bodek:
> On 06.12.2016 21:27, Thomas Monjalon wrote:
> > 2016-12-06 18:32, zbigniew.bodek@caviumnetworks.com:
> >> From: Zbigniew Bodek <zbigniew.bodek@caviumnetworks.com>
> >>
> >> Add type and name for ARMv8 crypto PMD
> >>
> >> Signed-off-by: Zbigniew Bodek <zbigniew.bodek@caviumnetworks.com>
> > [...]
> >> --- a/lib/librte_cryptodev/rte_cryptodev.h
> >> +++ b/lib/librte_cryptodev/rte_cryptodev.h
> >> @@ -66,6 +66,8 @@
> >> /**< KASUMI PMD device name */
> >> #define CRYPTODEV_NAME_ZUC_PMD crypto_zuc
> >> /**< KASUMI PMD device name */
> >> +#define CRYPTODEV_NAME_ARMV8_PMD crypto_armv8
> >> +/**< ARMv8 CM device name */
> >>
> >> /** Crypto device type */
> >> enum rte_cryptodev_type {
> >> @@ -77,6 +79,7 @@ enum rte_cryptodev_type {
> >> RTE_CRYPTODEV_KASUMI_PMD, /**< KASUMI PMD */
> >> RTE_CRYPTODEV_ZUC_PMD, /**< ZUC PMD */
> >> RTE_CRYPTODEV_OPENSSL_PMD, /**< OpenSSL PMD */
> >> + RTE_CRYPTODEV_ARMV8_PMD, /**< ARMv8 crypto PMD */
> >> };
> >
> > Can we remove all these types and names in the generic crypto API?
> >
>
> Hello Thomas,
>
> I added another PMD type and therefore we need new, unique number for
> it. I'm not sure if I understand correctly what you mean here, so please
> elaborate.
My comment is not specific to your PMD.
I think there is something wrong in the design of cryptodev if we need
to update rte_cryptodev.h each time a new driver is added.
There is no such thing in ethdev.
^ permalink raw reply
* Re: [RFC] ethdev: abstraction layer for QoS hierarchical scheduler
From: Dumitrescu, Cristian @ 2016-12-07 19:52 UTC (permalink / raw)
To: Alan Robertson; +Cc: dev@dpdk.org, Thomas Monjalon
In-Reply-To: <6d862b500e1e4f34a4cbf790db8d5d48@EMEAWP-EXMB11.corp.brocade.com>
Hi Alan,
Thanks for your comments!
> Hi Cristian,
> Looking at points 10 and 11 it's good to hear nodes can be dynamically added.
Yes, many implementations allow on-the-fly remapping a node from one parent to another
one, or simply adding more nodes post-initialization, so it is natural for the API to provide this.
> We've been trying to decide the best way to do this for support of qos on tunnels for
> some time now and the existing implementation doesn't allow this so effectively ruled
> out hierarchical queueing for tunnel targets on the output interface.
> Having said that, has thought been given to separating the queueing from being so closely
> tied to the Ethernet transmit process ? When queueing on a tunnel for example we may
> be working with encryption. When running with an anti-reply window it is really much
> better to do the QOS (packet reordering) before the encryption. To support this would
> it be possible to have a separate scheduler structure which can be passed into the
> scheduling API ? This means the calling code can hang the structure of whatever entity
> it wishes to perform qos on, and we get dynamic target support (sessions/tunnels etc).
Yes, this is one point where we need to look for a better solution. Current proposal attaches
the hierarchical scheduler function to an ethdev, so scheduling traffic for tunnels that have a
pre-defined bandwidth is not supported nicely. This question was also raised in VPP, but
there tunnels are supported as a type of output interfaces, so attaching scheduling to an
output interface also covers the tunnels case.
Looks to me that nice tunnel abstractions are a gap in DPDK as well. Any thoughts about
how tunnels should be supported in DPDK? What do other people think about this?
> Regarding the structure allocation, would it be possible to make the number of queues
> associated with a TC a compile time option which the scheduler would accommodate ?
> We frequently only use one queue per tc which means 75% of the space allocated at
> the queueing layer for that tc is never used. This may be specific to our implementation
> but if other implementations do the same if folks could say we may get a better idea
> if this is a common case.
> Whilst touching on the scheduler, the token replenishment works using a division and
> multiplication obviously to cater for the fact that it may be run after several tc windows
> have passed. The most commonly used industrial scheduler simply does a lapsed on the tc
> and then adds the bc. This relies on the scheduler being called within the tc window
> though. It would be nice to have this as a configurable option since it's much for efficient
> assuming the infra code from which it's called can guarantee the calling frequency.
This is probably feedback for librte_sched as opposed to the current API proposal, as the
Latter is intended to be generic/implementation-agnostic and therefor its scope far
exceeds the existing set of librte_sched features.
Btw, we do plan using the librte_sched feature as the default fall-back when the HW
ethdev is not scheduler-enabled, as well as the implementation of choice for a lot of
use-cases where it fits really well, so we do have to continue evolve and improve
librte_sched feature-wise and performance-wise.
> I hope you'll consider these points for inclusion into a future road map. Hopefully in the
> future my employer will increase the priority of some of the tasks and a PR may appear
> on the mailing list.
> Thanks,
> Alan.
^ permalink raw reply
* [PATCH v10] drivers/net:new TUN/TAP device PMD
From: Keith Wiles @ 2016-12-07 19:38 UTC (permalink / raw)
To: dev; +Cc: pmatilai, yuanhan.liu, ferruh.yigit, john.mcnamara
In-Reply-To: <1476396234-44694-1-git-send-email-keith.wiles@intel.com>
The PMD allows for DPDK and the host to communicate using a raw
device interface on the host and in the DPDK application. The device
created is a Tap device with a L2 packet header.
v10- Change the string name used to allow for multiple devices.
v9 - Fix up the docs to use correct syntax
v8 - Fix issue with tap_tx_queue_setup() not return zero on success.
v7 - Reword the comment in common_base and fix the data->name issue
v6 - fixed the checkpatch issues
v5 - merge in changes from list review see related emails
fixed many minor edits
v4 - merge with latest driver changes
v3 - fix includes by removing ifdef for other type besides Linux
Fix the copyright notice in the Makefile
v2 - merge all of the patches into one patch
Fix a typo on naming the tap device
Update the maintainers list
Signed-off-by: Keith Wiles <keith.wiles@intel.com>
---
MAINTAINERS | 5 +
config/common_base | 9 +
config/common_linuxapp | 1 +
doc/guides/nics/tap.rst | 136 ++++++
drivers/net/Makefile | 1 +
drivers/net/tap/Makefile | 57 +++
drivers/net/tap/rte_eth_tap.c | 765 ++++++++++++++++++++++++++++++++
drivers/net/tap/rte_pmd_tap_version.map | 4 +
mk/rte.app.mk | 1 +
9 files changed, 979 insertions(+)
create mode 100644 doc/guides/nics/tap.rst
create mode 100644 drivers/net/tap/Makefile
create mode 100644 drivers/net/tap/rte_eth_tap.c
create mode 100644 drivers/net/tap/rte_pmd_tap_version.map
diff --git a/MAINTAINERS b/MAINTAINERS
index 26d9590..842fb6d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -398,6 +398,11 @@ F: doc/guides/nics/pcap_ring.rst
F: app/test/test_pmd_ring.c
F: app/test/test_pmd_ring_perf.c
+Tap PMD
+M: Keith Wiles <keith.wiles@intel.com>
+F: drivers/net/tap
+F: doc/guides/nics/tap.rst
+
Null Networking PMD
M: Tetsuya Mukawa <mtetsuyah@gmail.com>
F: drivers/net/null/
diff --git a/config/common_base b/config/common_base
index 652a839..eb51cdb 100644
--- a/config/common_base
+++ b/config/common_base
@@ -590,3 +590,12 @@ CONFIG_RTE_APP_TEST_RESOURCE_TAR=n
CONFIG_RTE_TEST_PMD=y
CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
+
+#
+# Compile the TAP PMD
+#
+# The TAP PMD is currently only built for Linux and the
+# option is enabled by default in common_linuxapp file,
+# set to 'n' in the common_base file.
+#
+CONFIG_RTE_LIBRTE_PMD_TAP=n
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 2483dfa..782b503 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -44,3 +44,4 @@ CONFIG_RTE_LIBRTE_PMD_VHOST=y
CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
CONFIG_RTE_LIBRTE_POWER=y
CONFIG_RTE_VIRTIO_USER=y
+CONFIG_RTE_LIBRTE_PMD_TAP=y
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
new file mode 100644
index 0000000..622b9e7
--- /dev/null
+++ b/doc/guides/nics/tap.rst
@@ -0,0 +1,136 @@
+.. BSD LICENSE
+ Copyright(c) 2016 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.
+
+Tun/Tap Poll Mode Driver
+========================
+
+The ``rte_eth_tap.c`` PMD creates a device using TUN/TAP interfaces on the
+local host. The PMD allows for DPDK and the host to communicate using a raw
+device interface on the host and in the DPDK application.
+
+The device created is a TAP device, which sends/receives packet in a raw
+format with a L2 header. The usage for a TAP PMD is for connectivity to the
+local host using a TAP interface. When the TAP PMD is initialized it will
+create a number of tap devices in the host accessed via ``ifconfig -a`` or
+``ip`` command. The commands can be used to assign and query the virtual like
+device.
+
+These TAP interfaces can be used with Wireshark or tcpdump or Pktgen-DPDK
+along with being able to be used as a network connection to the DPDK
+application. The method enable one or more interfaces is to use the
+``--vdev=net_tap`` option on the DPDK application command line. Each
+``--vdev=net_tap`` option give will create an interface named dtap0, dtap1,
+and so on.
+
+The interfaced name can be changed by adding the ``iface=foo0``, for example::
+
+ --vdev=net_tap,iface=foo0 --vdev=net_tap,iface=foo1, ...
+
+Also the speed of the interface can be changed from 10G to whatever number
+needed, but the interface does not enforce that speed, for example::
+
+ --vdev=net_tap,iface=foo0,speed=25000
+
+After the DPDK application is started you can send and receive packets on the
+interface using the standard rx_burst/tx_burst APIs in DPDK. From the host
+point of view you can use any host tool like tcpdump, Wireshark, ping, Pktgen
+and others to communicate with the DPDK application. The DPDK application may
+not understand network protocols like IPv4/6, UDP or TCP unless the
+application has been written to understand these protocols.
+
+If you need the interface as a real network interface meaning running and has
+a valid IP address then you can do this with the following commands::
+
+ sudo ip link set dtap0 up; sudo ip addr add 192.168.0.250/24 dev dtap0
+ sudo ip link set dtap1 up; sudo ip addr add 192.168.1.250/24 dev dtap1
+
+Please change the IP addresses as you see fit.
+
+If routing is enabled on the host you can also communicate with the DPDK App
+over the internet via a standard socket layer application as long as you
+account for the protocol handing in the application.
+
+If you have a Network Stack in your DPDK application or something like it you
+can utilize that stack to handle the network protocols. Plus you would be able
+to address the interface using an IP address assigned to the internal
+interface.
+
+Example
+-------
+
+The following is a simple example of using the TUN/TAP PMD with the Pktgen
+packet generator. It requires that the ``socat`` utility is installed on the
+test system.
+
+Build DPDK, then pull down Pktgen and build pktgen using the DPDK SDK/Target
+used to build the dpdk you pulled down.
+
+Run pktgen from the pktgen directory in a terminal with a commandline like the
+following::
+
+ sudo ./app/app/x86_64-native-linuxapp-gcc/app/pktgen -l 1-5 -n 4 \
+ --proc-type auto --log-level 8 --socket-mem 512,512 --file-prefix pg \
+ --vdev=net_tap --vdev=net_tap -b 05:00.0 -b 05:00.1 \
+ -b 04:00.0 -b 04:00.1 -b 04:00.2 -b 04:00.3 \
+ -b 81:00.0 -b 81:00.1 -b 81:00.2 -b 81:00.3 \
+ -b 82:00.0 -b 83:00.0 -- -T -P -m [2:3].0 -m [4:5].1 \
+ -f themes/black-yellow.theme
+
+.. Note:
+
+ Change the ``-b`` options to blacklist all of your physical ports. The
+ following command line is all one line.
+
+ Also, ``-f themes/black-yellow.theme`` is optional if the default colors
+ work on your system configuration. See the Pktgen docs for more
+ information.
+
+Verify with ``ifconfig -a`` command in a different xterm window, should have a
+``dtap0`` and ``dtap1`` interfaces created.
+
+Next set the links for the two interfaces to up via the commands below::
+
+ sudo ip link set dtap0 up; sudo ip addr add 192.168.0.250/24 dev dtap0
+ sudo ip link set dtap1 up; sudo ip addr add 192.168.1.250/24 dev dtap1
+
+Then use socat to create a loopback for the two interfaces::
+
+ sudo socat interface:dtap0 interface:dtap1
+
+Then on the Pktgen command line interface you can start sending packets using
+the commands ``start 0`` and ``start 1`` or you can start both at the same
+time with ``start all``. The command ``str`` is an alias for ``start all`` and
+``stp`` is an alias for ``stop all``.
+
+While running you should see the 64 byte counters increasing to verify the
+traffic is being looped back. You can use ``set all size XXX`` to change the
+size of the packets after you stop the traffic. Use the pktgen ``help``
+command to see a list of all commands. You can also use the ``-f`` option to
+load commands at startup.
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index bc93230..e366a85 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -51,6 +51,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += pcap
DIRS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += qede
DIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += ring
DIRS-$(CONFIG_RTE_LIBRTE_PMD_SZEDATA2) += szedata2
+DIRS-$(CONFIG_RTE_LIBRTE_PMD_TAP) += tap
DIRS-$(CONFIG_RTE_LIBRTE_THUNDERX_NICVF_PMD) += thunderx
DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
diff --git a/drivers/net/tap/Makefile b/drivers/net/tap/Makefile
new file mode 100644
index 0000000..e18f30c
--- /dev/null
+++ b/drivers/net/tap/Makefile
@@ -0,0 +1,57 @@
+# BSD LICENSE
+#
+# Copyright(c) 2016 Intel Corporation. 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.
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+#
+# library name
+#
+LIB = librte_pmd_tap.a
+
+EXPORT_MAP := rte_pmd_tap_version.map
+
+LIBABIVER := 1
+
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+
+#
+# all source are stored in SRCS-y
+#
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_TAP) += rte_eth_tap.c
+
+# this lib depends upon:
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_TAP) += lib/librte_eal
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_TAP) += lib/librte_mbuf
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_TAP) += lib/librte_mempool
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_TAP) += lib/librte_ether
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_TAP) += lib/librte_kvargs
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
new file mode 100644
index 0000000..d5e2fc3
--- /dev/null
+++ b/drivers/net/tap/rte_eth_tap.c
@@ -0,0 +1,765 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 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.
+ */
+
+#include <rte_mbuf.h>
+#include <rte_ethdev.h>
+#include <rte_malloc.h>
+#include <rte_vdev.h>
+#include <rte_kvargs.h>
+
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <sys/socket.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
+#include <unistd.h>
+#include <poll.h>
+#include <arpa/inet.h>
+#include <linux/if.h>
+#include <linux/if_tun.h>
+#include <linux/if_ether.h>
+#include <fcntl.h>
+
+/* Linux based path to the TUN device */
+#define TUN_TAP_DEV_PATH "/dev/net/tun"
+#define DEFAULT_TAP_NAME "dtap"
+
+#define ETH_TAP_IFACE_ARG "iface"
+#define ETH_TAP_SPEED_ARG "speed"
+
+#define RTE_PMD_TAP_MAX_QUEUES 16
+
+static const char *valid_arguments[] = {
+ ETH_TAP_IFACE_ARG,
+ ETH_TAP_SPEED_ARG,
+ NULL
+};
+
+static const char *drivername = "Tap PMD";
+static int tap_unit;
+
+static struct rte_eth_link pmd_link = {
+ .link_speed = ETH_SPEED_NUM_10G,
+ .link_duplex = ETH_LINK_FULL_DUPLEX,
+ .link_status = ETH_LINK_DOWN,
+ .link_autoneg = ETH_LINK_SPEED_AUTONEG
+};
+
+struct pkt_stats {
+ uint64_t opackets; /* Number of output packets */
+ uint64_t ipackets; /* Number of input packets */
+ uint64_t obytes; /* Number of bytes on output */
+ uint64_t ibytes; /* Number of bytes on input */
+ uint64_t errs; /* Number of error packets */
+};
+
+struct rx_queue {
+ struct rte_mempool *mp; /* Mempool for RX packets */
+ uint16_t in_port; /* Port ID */
+ int fd;
+
+ struct pkt_stats stats; /* Stats for this RX queue */
+};
+
+struct tx_queue {
+ int fd;
+ struct pkt_stats stats; /* Stats for this TX queue */
+};
+
+struct pmd_internals {
+ char name[RTE_ETH_NAME_MAX_LEN]; /* Internal Tap device name */
+ uint16_t nb_queues; /* Number of queues supported */
+ struct ether_addr eth_addr; /* Mac address of the device port */
+
+ int if_index; /* IF_INDEX for the port */
+ int fds[RTE_PMD_TAP_MAX_QUEUES]; /* List of all file descriptors */
+
+ struct rx_queue rxq[RTE_PMD_TAP_MAX_QUEUES]; /* List of RX queues */
+ struct tx_queue txq[RTE_PMD_TAP_MAX_QUEUES]; /* List of TX queues */
+};
+
+/* Tun/Tap allocation routine
+ *
+ * name is the number of the interface to use, unless NULL to take the host
+ * supplied name.
+ */
+static int
+tun_alloc(char *name)
+{
+ struct ifreq ifr;
+ unsigned int features;
+ int fd;
+
+ memset(&ifr, 0, sizeof(struct ifreq));
+
+ ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
+ if (name && name[0])
+ strncpy(ifr.ifr_name, name, IFNAMSIZ);
+
+ fd = open(TUN_TAP_DEV_PATH, O_RDWR);
+ if (fd < 0) {
+ RTE_LOG(ERR, PMD, "Unable to create TAP interface");
+ goto error;
+ }
+
+ /* Grab the TUN features to verify we can work */
+ if (ioctl(fd, TUNGETFEATURES, &features) < 0) {
+ RTE_LOG(ERR, PMD, "Unable to get TUN/TAP features\n");
+ goto error;
+ }
+ RTE_LOG(DEBUG, PMD, "TUN/TAP Features %08x\n", features);
+
+ if (!(features & IFF_MULTI_QUEUE) && (RTE_PMD_TAP_MAX_QUEUES > 1)) {
+ RTE_LOG(DEBUG, PMD, "TUN/TAP device only one queue\n");
+ goto error;
+ } else if ((features & IFF_ONE_QUEUE) &&
+ (RTE_PMD_TAP_MAX_QUEUES == 1)) {
+ ifr.ifr_flags |= IFF_ONE_QUEUE;
+ RTE_LOG(DEBUG, PMD, "Single queue only support\n");
+ } else {
+ ifr.ifr_flags |= IFF_MULTI_QUEUE;
+ RTE_LOG(DEBUG, PMD, "Multi-queue support for %d queues\n",
+ RTE_PMD_TAP_MAX_QUEUES);
+ }
+
+ /* Set the TUN/TAP configuration and get the name if needed */
+ if (ioctl(fd, TUNSETIFF, (void *)&ifr) < 0) {
+ RTE_LOG(ERR, PMD, "Unable to set TUNSETIFF for %s\n",
+ ifr.ifr_name);
+ perror("TUNSETIFF");
+ goto error;
+ }
+
+ /* Always set the file descriptor to non-blocking */
+ if (fcntl(fd, F_SETFL, O_NONBLOCK) < 0) {
+ RTE_LOG(ERR, PMD, "Unable to set to nonblocking\n");
+ perror("F_SETFL, NONBLOCK");
+ goto error;
+ }
+
+ /* If the name is different that new name as default */
+ if (name && strcmp(name, ifr.ifr_name))
+ snprintf(name, RTE_ETH_NAME_MAX_LEN - 1, "%s", ifr.ifr_name);
+
+ return fd;
+
+error:
+ if (fd > 0)
+ close(fd);
+ return -1;
+}
+
+/* Callback to handle the rx burst of packets to the correct interface and
+ * file descriptor(s) in a multi-queue setup.
+ */
+static uint16_t
+pmd_rx_burst(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
+{
+ int len;
+ struct rte_mbuf *mbuf;
+ struct rx_queue *rxq = queue;
+ uint16_t num_rx;
+ unsigned long num_rx_bytes = 0;
+
+ for (num_rx = 0; num_rx < nb_pkts; ) {
+ /* allocate the next mbuf */
+ mbuf = rte_pktmbuf_alloc(rxq->mp);
+ if (unlikely(!mbuf)) {
+ RTE_LOG(WARNING, PMD, "Unable to allocate mbuf\n");
+ break;
+ }
+
+ len = read(rxq->fd, rte_pktmbuf_mtod(mbuf, char *),
+ rte_pktmbuf_tailroom(mbuf));
+ if (len <= 0) {
+ rte_pktmbuf_free(mbuf);
+ break;
+ }
+
+ mbuf->data_len = len;
+ mbuf->pkt_len = len;
+ mbuf->port = rxq->in_port;
+
+ /* account for the receive frame */
+ bufs[num_rx++] = mbuf;
+ num_rx_bytes += mbuf->pkt_len;
+ }
+ rxq->stats.ipackets += num_rx;
+ rxq->stats.ibytes += num_rx_bytes;
+
+ return num_rx;
+}
+
+/* Callback to handle sending packets from the tap interface
+ */
+static uint16_t
+pmd_tx_burst(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
+{
+ struct rte_mbuf *mbuf;
+ struct tx_queue *txq = queue;
+ struct pollfd pfd;
+ uint16_t num_tx = 0;
+ unsigned long num_tx_bytes = 0;
+ int i, n;
+
+ if (unlikely(nb_pkts == 0))
+ return 0;
+
+ pfd.events = POLLOUT;
+ pfd.fd = txq->fd;
+ for (i = 0; i < nb_pkts; i++) {
+ n = poll(&pfd, 1, 0);
+
+ if (n <= 0)
+ break;
+
+ if (pfd.revents & POLLOUT) {
+ /* copy the tx frame data */
+ mbuf = bufs[num_tx];
+ n = write(pfd.fd, rte_pktmbuf_mtod(mbuf, void*),
+ rte_pktmbuf_pkt_len(mbuf));
+ if (n <= 0)
+ break;
+
+ num_tx++;
+ num_tx_bytes += mbuf->pkt_len;
+ rte_pktmbuf_free(mbuf);
+ }
+ }
+
+ txq->stats.opackets += num_tx;
+ txq->stats.errs += nb_pkts - num_tx;
+ txq->stats.obytes += num_tx_bytes;
+
+ return num_tx;
+}
+
+static int
+tap_dev_start(struct rte_eth_dev *dev)
+{
+ /* Force the Link up */
+ dev->data->dev_link.link_status = ETH_LINK_UP;
+
+ return 0;
+}
+
+/* This function gets called when the current port gets stopped.
+ */
+static void
+tap_dev_stop(struct rte_eth_dev *dev)
+{
+ int i;
+ struct pmd_internals *internals = dev->data->dev_private;
+
+ for (i = 0; i < internals->nb_queues; i++)
+ if (internals->fds[i] != -1)
+ close(internals->fds[i]);
+
+ dev->data->dev_link.link_status = ETH_LINK_DOWN;
+}
+
+static int
+tap_dev_configure(struct rte_eth_dev *dev __rte_unused)
+{
+ return 0;
+}
+
+static void
+tap_dev_info(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
+{
+ struct pmd_internals *internals = dev->data->dev_private;
+
+ dev_info->driver_name = drivername;
+ dev_info->if_index = internals->if_index;
+ dev_info->max_mac_addrs = 1;
+ dev_info->max_rx_pktlen = (uint32_t)ETHER_MAX_VLAN_FRAME_LEN;
+ dev_info->max_rx_queues = internals->nb_queues;
+ dev_info->max_tx_queues = internals->nb_queues;
+ dev_info->min_rx_bufsize = 0;
+ dev_info->pci_dev = NULL;
+}
+
+static void
+tap_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *tap_stats)
+{
+ unsigned int i, imax;
+ unsigned long rx_total = 0, tx_total = 0, tx_err_total = 0;
+ unsigned long rx_bytes_total = 0, tx_bytes_total = 0;
+ const struct pmd_internals *pmd = dev->data->dev_private;
+
+ imax = (pmd->nb_queues < RTE_ETHDEV_QUEUE_STAT_CNTRS) ?
+ pmd->nb_queues : RTE_ETHDEV_QUEUE_STAT_CNTRS;
+
+ for (i = 0; i < imax; i++) {
+ tap_stats->q_ipackets[i] = pmd->rxq[i].stats.ipackets;
+ tap_stats->q_ibytes[i] = pmd->rxq[i].stats.ibytes;
+ rx_total += tap_stats->q_ipackets[i];
+ rx_bytes_total += tap_stats->q_ibytes[i];
+ }
+
+ for (i = 0; i < imax; i++) {
+ tap_stats->q_opackets[i] = pmd->txq[i].stats.opackets;
+ tap_stats->q_errors[i] = pmd->txq[i].stats.errs;
+ tap_stats->q_obytes[i] = pmd->txq[i].stats.obytes;
+ tx_total += tap_stats->q_opackets[i];
+ tx_err_total += tap_stats->q_errors[i];
+ tx_bytes_total += tap_stats->q_obytes[i];
+ }
+
+ tap_stats->ipackets = rx_total;
+ tap_stats->ibytes = rx_bytes_total;
+ tap_stats->opackets = tx_total;
+ tap_stats->oerrors = tx_err_total;
+ tap_stats->obytes = tx_bytes_total;
+}
+
+static void
+tap_stats_reset(struct rte_eth_dev *dev)
+{
+ int i;
+ struct pmd_internals *pmd = dev->data->dev_private;
+
+ for (i = 0; i < pmd->nb_queues; i++) {
+ pmd->rxq[i].stats.ipackets = 0;
+ pmd->rxq[i].stats.ibytes = 0;
+ }
+
+ for (i = 0; i < pmd->nb_queues; i++) {
+ pmd->txq[i].stats.opackets = 0;
+ pmd->txq[i].stats.errs = 0;
+ pmd->txq[i].stats.obytes = 0;
+ }
+}
+
+static void
+tap_dev_close(struct rte_eth_dev *dev __rte_unused)
+{
+}
+
+static void
+tap_rx_queue_release(void *queue)
+{
+ struct rx_queue *rxq = queue;
+
+ if (rxq && (rxq->fd > 0)) {
+ close(rxq->fd);
+ rxq->fd = -1;
+ }
+}
+
+static void
+tap_tx_queue_release(void *queue)
+{
+ struct tx_queue *txq = queue;
+
+ if (txq && (txq->fd > 0)) {
+ close(txq->fd);
+ txq->fd = -1;
+ }
+}
+
+static int
+tap_link_update(struct rte_eth_dev *dev __rte_unused,
+ int wait_to_complete __rte_unused)
+{
+ return 0;
+}
+
+static int
+tap_setup_queue(struct rte_eth_dev *dev,
+ struct pmd_internals *internals,
+ uint16_t qid)
+{
+ struct rx_queue *rx = &internals->rxq[qid];
+ struct tx_queue *tx = &internals->txq[qid];
+ int fd;
+
+ fd = rx->fd;
+ if (fd < 0) {
+ fd = tx->fd;
+ if (fd < 0) {
+ RTE_LOG(INFO, PMD, "Add queue to TAP %s for qid %d\n",
+ dev->data->name, qid);
+ fd = tun_alloc(dev->data->name);
+ if (fd < 0) {
+ RTE_LOG(ERR, PMD, "tun_alloc(%s) failed\n",
+ dev->data->name);
+ return -1;
+ }
+ }
+ }
+ dev->data->rx_queues[qid] = rx;
+ dev->data->tx_queues[qid] = tx;
+
+ rx->fd = fd;
+ tx->fd = fd;
+
+ return fd;
+}
+
+static int
+tap_rx_queue_setup(struct rte_eth_dev *dev,
+ uint16_t rx_queue_id,
+ uint16_t nb_rx_desc __rte_unused,
+ unsigned int socket_id __rte_unused,
+ const struct rte_eth_rxconf *rx_conf __rte_unused,
+ struct rte_mempool *mp)
+{
+ struct pmd_internals *internals = dev->data->dev_private;
+ uint16_t buf_size;
+ int fd;
+
+ if ((rx_queue_id >= internals->nb_queues) || !mp) {
+ RTE_LOG(ERR, PMD, "nb_queues %d mp %p\n",
+ internals->nb_queues, mp);
+ return -1;
+ }
+
+ internals->rxq[rx_queue_id].mp = mp;
+ internals->rxq[rx_queue_id].in_port = dev->data->port_id;
+
+ /* Now get the space available for data in the mbuf */
+ buf_size = (uint16_t)(rte_pktmbuf_data_room_size(mp) -
+ RTE_PKTMBUF_HEADROOM);
+
+ if (buf_size < ETH_FRAME_LEN) {
+ RTE_LOG(ERR, PMD,
+ "%s: %d bytes will not fit in mbuf (%d bytes)\n",
+ dev->data->name, ETH_FRAME_LEN, buf_size);
+ return -ENOMEM;
+ }
+
+ fd = tap_setup_queue(dev, internals, rx_queue_id);
+ if (fd == -1)
+ return -1;
+
+ internals->fds[rx_queue_id] = fd;
+ RTE_LOG(INFO, PMD, "RX TAP device name %s, qid %d on fd %d\n",
+ dev->data->name, rx_queue_id, internals->rxq[rx_queue_id].fd);
+
+ return 0;
+}
+
+static int
+tap_tx_queue_setup(struct rte_eth_dev *dev,
+ uint16_t tx_queue_id,
+ uint16_t nb_tx_desc __rte_unused,
+ unsigned int socket_id __rte_unused,
+ const struct rte_eth_txconf *tx_conf __rte_unused)
+{
+ struct pmd_internals *internals = dev->data->dev_private;
+ int ret;
+
+ if (tx_queue_id >= internals->nb_queues)
+ return -1;
+
+ ret = tap_setup_queue(dev, internals, tx_queue_id);
+ if (ret == -1)
+ return -1;
+
+ RTE_LOG(INFO, PMD, "TX TAP device name %s, qid %d on fd %d\n",
+ dev->data->name, tx_queue_id, internals->txq[tx_queue_id].fd);
+
+ return 0;
+}
+
+static const struct eth_dev_ops ops = {
+ .dev_start = tap_dev_start,
+ .dev_stop = tap_dev_stop,
+ .dev_close = tap_dev_close,
+ .dev_configure = tap_dev_configure,
+ .dev_infos_get = tap_dev_info,
+ .rx_queue_setup = tap_rx_queue_setup,
+ .tx_queue_setup = tap_tx_queue_setup,
+ .rx_queue_release = tap_rx_queue_release,
+ .tx_queue_release = tap_tx_queue_release,
+ .link_update = tap_link_update,
+ .stats_get = tap_stats_get,
+ .stats_reset = tap_stats_reset,
+};
+
+static int
+pmd_mac_address(int fd, struct rte_eth_dev *dev, struct ether_addr *addr)
+{
+ struct ifreq ifr;
+
+ if ((fd <= 0) || !dev || !addr)
+ return -1;
+
+ memset(&ifr, 0, sizeof(ifr));
+
+ if (ioctl(fd, SIOCGIFHWADDR, &ifr) == -1) {
+ RTE_LOG(ERR, PMD, "ioctl failed (SIOCGIFHWADDR) (%s)\n",
+ ifr.ifr_name);
+ return -1;
+ }
+
+ /* Set the host based MAC address to this special MAC format */
+ ifr.ifr_hwaddr.sa_data[0] = 'T';
+ ifr.ifr_hwaddr.sa_data[1] = 'a';
+ ifr.ifr_hwaddr.sa_data[2] = 'p';
+ ifr.ifr_hwaddr.sa_data[3] = '-';
+ ifr.ifr_hwaddr.sa_data[4] = dev->data->port_id;
+ ifr.ifr_hwaddr.sa_data[5] = dev->data->numa_node;
+ if (ioctl(fd, SIOCSIFHWADDR, &ifr) == -1) {
+ RTE_LOG(ERR, PMD, "%s: ioctl failed (SIOCSIFHWADDR) (%s)\n",
+ dev->data->name, ifr.ifr_name);
+ return -1;
+ }
+
+ /* Set the local application MAC address, needs to be different then
+ * the host based MAC address.
+ */
+ ifr.ifr_hwaddr.sa_data[0] = 'd';
+ ifr.ifr_hwaddr.sa_data[1] = 'n';
+ ifr.ifr_hwaddr.sa_data[2] = 'e';
+ ifr.ifr_hwaddr.sa_data[3] = 't';
+ ifr.ifr_hwaddr.sa_data[4] = dev->data->port_id;
+ ifr.ifr_hwaddr.sa_data[5] = dev->data->numa_node;
+ rte_memcpy(addr, ifr.ifr_hwaddr.sa_data, ETH_ALEN);
+
+ return 0;
+}
+
+static int
+eth_dev_tap_create(const char *name, char *tap_name)
+{
+ int numa_node = rte_socket_id();
+ struct rte_eth_dev *dev = NULL;
+ struct pmd_internals *pmd = NULL;
+ struct rte_eth_dev_data *data = NULL;
+ int i, fd = -1;
+
+ RTE_LOG(INFO, PMD,
+ "%s: Create TAP Ethernet device with %d queues on numa %u\n",
+ name, RTE_PMD_TAP_MAX_QUEUES, rte_socket_id());
+
+ data = rte_zmalloc_socket(tap_name, sizeof(*data), 0, numa_node);
+ if (!data) {
+ RTE_LOG(INFO, PMD, "Failed to allocate data\n");
+ goto error_exit;
+ }
+
+ pmd = rte_zmalloc_socket(tap_name, sizeof(*pmd), 0, numa_node);
+ if (!pmd) {
+ RTE_LOG(INFO, PMD, "Unable to allocate internal struct\n");
+ goto error_exit;
+ }
+
+ /* Use the name and not the tap_name */
+ dev = rte_eth_dev_allocate(tap_name);
+ if (!dev) {
+ RTE_LOG(INFO, PMD, "Unable to allocate device struct\n");
+ goto error_exit;
+ }
+
+ snprintf(pmd->name, sizeof(pmd->name), "%s", tap_name);
+
+ pmd->nb_queues = RTE_PMD_TAP_MAX_QUEUES;
+
+ /* Setup some default values */
+ data->dev_private = pmd;
+ data->port_id = dev->data->port_id;
+ data->dev_flags = RTE_ETH_DEV_DETACHABLE;
+ data->kdrv = RTE_KDRV_NONE;
+ data->drv_name = drivername;
+ data->numa_node = numa_node;
+
+ data->dev_link = pmd_link;
+ data->mac_addrs = &pmd->eth_addr;
+ data->nb_rx_queues = pmd->nb_queues;
+ data->nb_tx_queues = pmd->nb_queues;
+ data->drv_name = drivername;
+
+ dev->data = data;
+ dev->dev_ops = &ops;
+ dev->driver = NULL;
+ dev->rx_pkt_burst = pmd_rx_burst;
+ dev->tx_pkt_burst = pmd_tx_burst;
+ snprintf(dev->data->name, sizeof(dev->data->name), "%s", name);
+
+ /* Create the first Tap device */
+ fd = tun_alloc(tap_name);
+ if (fd < 0) {
+ RTE_LOG(INFO, PMD, "tun_alloc() failed\n");
+ goto error_exit;
+ }
+
+ /* Presetup the fds to -1 as being not working */
+ for (i = 0; i < RTE_PMD_TAP_MAX_QUEUES; i++) {
+ pmd->fds[i] = -1;
+ pmd->rxq[i].fd = -1;
+ pmd->txq[i].fd = -1;
+ }
+
+ /* Take the TUN/TAP fd and place in the first location */
+ pmd->rxq[0].fd = fd;
+ pmd->txq[0].fd = fd;
+ pmd->fds[0] = fd;
+
+ if (pmd_mac_address(fd, dev, &pmd->eth_addr) < 0) {
+ RTE_LOG(INFO, PMD, "Unable to get MAC address\n");
+ goto error_exit;
+ }
+
+ return 0;
+
+error_exit:
+ RTE_PMD_DEBUG_TRACE("Unable to initialize %s\n", name);
+
+ rte_free(data);
+ rte_free(pmd);
+
+ rte_eth_dev_release_port(dev);
+
+ return -EINVAL;
+}
+
+static int
+set_interface_name(const char *key __rte_unused,
+ const char *value,
+ void *extra_args)
+{
+ char *name = (char *)extra_args;
+
+ if (value)
+ snprintf(name, RTE_ETH_NAME_MAX_LEN - 1, "%s", value);
+ else
+ snprintf(name, RTE_ETH_NAME_MAX_LEN - 1, "%s%d",
+ DEFAULT_TAP_NAME, (tap_unit - 1));
+
+ return 0;
+}
+
+static int
+set_interface_speed(const char *key __rte_unused,
+ const char *value,
+ void *extra_args)
+{
+ *(int *)extra_args = (value) ? atoi(value) : ETH_SPEED_NUM_10G;
+
+ return 0;
+}
+
+/* Open a TAP interface device.
+ */
+static int
+rte_pmd_tap_probe(const char *name, const char *params)
+{
+ int ret;
+ struct rte_kvargs *kvlist = NULL;
+ int speed;
+ char tap_name[RTE_ETH_NAME_MAX_LEN];
+
+ speed = ETH_SPEED_NUM_10G;
+ snprintf(tap_name, sizeof(tap_name), "%s%d",
+ DEFAULT_TAP_NAME, tap_unit++);
+
+ RTE_LOG(INFO, PMD, "Initializing pmd_tap for %s as %s\n",
+ name, tap_name);
+
+ if (params && (params[0] != '\0')) {
+ RTE_LOG(INFO, PMD, "paramaters (%s)\n", params);
+
+ kvlist = rte_kvargs_parse(params, valid_arguments);
+ if (kvlist) {
+ if (rte_kvargs_count(kvlist, ETH_TAP_SPEED_ARG) == 1) {
+ ret = rte_kvargs_process(kvlist,
+ ETH_TAP_SPEED_ARG,
+ &set_interface_speed,
+ &speed);
+ if (ret == -1)
+ goto leave;
+ }
+
+ if (rte_kvargs_count(kvlist, ETH_TAP_IFACE_ARG) == 1) {
+ ret = rte_kvargs_process(kvlist,
+ ETH_TAP_IFACE_ARG,
+ &set_interface_name,
+ tap_name);
+ if (ret == -1)
+ goto leave;
+ }
+ }
+ }
+ pmd_link.link_speed = speed;
+
+ ret = eth_dev_tap_create(name, tap_name);
+
+leave:
+ if (ret == -1) {
+ RTE_LOG(INFO, PMD, "Failed to create pmd for %s as %s\n",
+ name, tap_name);
+ tap_unit--; /* Restore the unit number */
+ }
+ rte_kvargs_free(kvlist);
+
+ return ret;
+}
+
+/* detach a TAP device.
+ */
+static int
+rte_pmd_tap_remove(const char *name)
+{
+ struct rte_eth_dev *eth_dev = NULL;
+ struct pmd_internals *internals;
+ int i;
+
+ RTE_LOG(INFO, PMD, "Closing TUN/TAP Ethernet device on numa %u\n",
+ rte_socket_id());
+
+ /* find the ethdev entry */
+ eth_dev = rte_eth_dev_allocated(name);
+ if (!eth_dev)
+ return 0;
+
+ internals = eth_dev->data->dev_private;
+ for (i = 0; i < internals->nb_queues; i++)
+ if (internals->fds[i] != -1)
+ close(internals->fds[i]);
+
+ rte_free(eth_dev->data->dev_private);
+ rte_free(eth_dev->data);
+
+ rte_eth_dev_release_port(eth_dev);
+
+ return 0;
+}
+
+static struct rte_vdev_driver pmd_tap_drv = {
+ .probe = rte_pmd_tap_probe,
+ .remove = rte_pmd_tap_remove,
+};
+RTE_PMD_REGISTER_VDEV(net_tap, pmd_tap_drv);
+RTE_PMD_REGISTER_PARAM_STRING(net_tap, "iface=<string>,speed=N");
diff --git a/drivers/net/tap/rte_pmd_tap_version.map b/drivers/net/tap/rte_pmd_tap_version.map
new file mode 100644
index 0000000..61463bf
--- /dev/null
+++ b/drivers/net/tap/rte_pmd_tap_version.map
@@ -0,0 +1,4 @@
+DPDK_16.11 {
+
+ local: *;
+};
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index f75f0e2..02c32ae 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -124,6 +124,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += -lrte_pmd_pcap -lpcap
_LDLIBS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += -lrte_pmd_qede
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_RING) += -lrte_pmd_ring
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_SZEDATA2) += -lrte_pmd_szedata2 -lsze2
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_TAP) += -lrte_pmd_tap
_LDLIBS-$(CONFIG_RTE_LIBRTE_THUNDERX_NICVF_PMD) += -lrte_pmd_thunderx_nicvf -lm
_LDLIBS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += -lrte_pmd_virtio
ifeq ($(CONFIG_RTE_LIBRTE_VHOST),y)
--
2.8.0.GIT
^ permalink raw reply related
* [PATCH v2] maintainers: update for qede PMD and bnx2x PMD
From: Rasesh Mody @ 2016-12-07 19:22 UTC (permalink / raw)
To: thomas.monjalon; +Cc: dev, Dept-EngDPDKDev, Rasesh Mody
In-Reply-To: <2145401.aVkHXD7hpm@xps13>
Following Cavium's acquisition of QLogic we need to update all the
qlogic PMD maintainer's entries to point to our new e-mail addresses.
Update driver's maintainers as they are no longer working for Cavium.
Thanks to Sony Chacko for his support and development of our various
dpdk drivers.
Signed-off-by: Rasesh Mody <Rasesh.Mody@cavium.com>
---
MAINTAINERS | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index d915426..1c170d7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -351,16 +351,14 @@ F: drivers/net/nfp/
F: doc/guides/nics/nfp.rst
QLogic bnx2x
-M: Sony Chacko <sony.chacko@qlogic.com>
-M: Harish Patil <harish.patil@qlogic.com>
-M: Rasesh Mody <rasesh.mody@qlogic.com>
+M: Harish Patil <harish.patil@cavium.com>
+M: Rasesh Mody <rasesh.mody@cavium.com>
F: drivers/net/bnx2x/
F: doc/guides/nics/bnx2x.rst
QLogic qede PMD
-M: Harish Patil <harish.patil@qlogic.com>
-M: Rasesh Mody <rasesh.mody@qlogic.com>
-M: Sony Chacko <sony.chacko@qlogic.com>
+M: Rasesh Mody <rasesh.mody@cavium.com>
+M: Harish Patil <harish.patil@cavium.com>
F: drivers/net/qede/
F: doc/guides/nics/qede.rst
--
1.7.10.3
^ permalink raw reply related
* Re: [PATCH v2 02/12] lib: add cryptodev type for the upcoming ARMv8 PMD
From: Zbigniew Bodek @ 2016-12-07 19:04 UTC (permalink / raw)
To: Thomas Monjalon, dev
Cc: zbigniew.bodek, pablo.de.lara.guarch, jerin.jacob, declan.doherty
In-Reply-To: <4126251.ynkckbu1rM@xps13>
On 06.12.2016 21:27, Thomas Monjalon wrote:
> 2016-12-06 18:32, zbigniew.bodek@caviumnetworks.com:
>> From: Zbigniew Bodek <zbigniew.bodek@caviumnetworks.com>
>>
>> Add type and name for ARMv8 crypto PMD
>>
>> Signed-off-by: Zbigniew Bodek <zbigniew.bodek@caviumnetworks.com>
> [...]
>> --- a/lib/librte_cryptodev/rte_cryptodev.h
>> +++ b/lib/librte_cryptodev/rte_cryptodev.h
>> @@ -66,6 +66,8 @@
>> /**< KASUMI PMD device name */
>> #define CRYPTODEV_NAME_ZUC_PMD crypto_zuc
>> /**< KASUMI PMD device name */
>> +#define CRYPTODEV_NAME_ARMV8_PMD crypto_armv8
>> +/**< ARMv8 CM device name */
>>
>> /** Crypto device type */
>> enum rte_cryptodev_type {
>> @@ -77,6 +79,7 @@ enum rte_cryptodev_type {
>> RTE_CRYPTODEV_KASUMI_PMD, /**< KASUMI PMD */
>> RTE_CRYPTODEV_ZUC_PMD, /**< ZUC PMD */
>> RTE_CRYPTODEV_OPENSSL_PMD, /**< OpenSSL PMD */
>> + RTE_CRYPTODEV_ARMV8_PMD, /**< ARMv8 crypto PMD */
>> };
>
> Can we remove all these types and names in the generic crypto API?
>
Hello Thomas,
I added another PMD type and therefore we need new, unique number for
it. I'm not sure if I understand correctly what you mean here, so please
elaborate.
Kind regards
Zbigniew
^ permalink raw reply
* Re: [RFC] ethdev: abstraction layer for QoS hierarchical scheduler
From: Dumitrescu, Cristian @ 2016-12-07 19:03 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev@dpdk.org
In-Reply-To: <20161206115124.67ccc0c7@xeon-e3>
Hi Steve,
Thanks for your comments!
> This seems to be more of an abstraction of existing QoS.
Really? Why exactly do you say this, any particular examples?
I think the current proposal provides an abstraction for far more features than librte_sched provides. The goal for this API is to be able to describe virtually any hierarchy that could be implemented in HW and/or SW, not just what is currently provided by librte_sched.
If your statement is true, then I failed in my mission, and hopefully I didn't :)
> Why not something like Linux Qdisc or FreeBSD DummyNet/PF/ALTQ where the Qos components are stackable objects?
After designing Packet Framework, I don't think anybody could suspect me of not being a fan of stackable objects ;). Not sure why you say this either, as basically current proposal builds the hierarchy out of inter-connected nodes sitting on top of shapers and WRED contexts. To me, this is a decent stack?
I don't think this proposal is that far away from Linux qdisc: qdisc classes are nodes, shapers are present, WRED contexts as well. Any particular qdisc feature you see missing?
Of course, Linux qdisc also includes classification, policing, marking, etc which are outside of the hierarchical scheduling that is targeted by this proposal. But this is an interesting thought: designing a qdisc-like layer within DPDK that binds together classification, policing, filters, scheduling.
> And why not make it the same as existing OS abstractions?
Do you mean using the Linux qdisc API and implementation as is? Of course, this is GPL licensed code and we cannot do this in DPDK.
Do you mean having a Linux qdisc-like API? I largely agree with this, and I think the current proposal is very much inline with this; if you think otherwise, again, specific examples of what's missing would help a lot. I can also take a look at DummyNet to make sure there is nothing left behind.
> Rather than reinventing wheel which seems to be DPDK Standard Procedure, could an existing abstraction be used?
I thought we are just trying to create a car instead of a faster horse :)
Regards,
Cristian
^ permalink raw reply
* Re: [PATCH v2 1/6] eventdev: introduce event driven programming model
From: Jerin Jacob @ 2016-12-07 18:53 UTC (permalink / raw)
To: Bruce Richardson
Cc: dev, thomas.monjalon, hemant.agrawal, gage.eads, harry.van.haaren
In-Reply-To: <20161206165119.GB22224@bricha3-MOBL3.ger.corp.intel.com>
On Tue, Dec 06, 2016 at 04:51:19PM +0000, Bruce Richardson wrote:
> On Tue, Dec 06, 2016 at 09:22:15AM +0530, Jerin Jacob wrote:
> > In a polling model, lcores poll ethdev ports and associated
> > rx queues directly to look for packet. In an event driven model,
> > by contrast, lcores call the scheduler that selects packets for
> > them based on programmer-specified criteria. Eventdev library
> > adds support for event driven programming model, which offer
> > applications automatic multicore scaling, dynamic load balancing,
> > pipelining, packet ingress order maintenance and
> > synchronization services to simplify application packet processing.
> >
> > By introducing event driven programming model, DPDK can support
> > both polling and event driven programming models for packet processing,
> > and applications are free to choose whatever model
> > (or combination of the two) that best suits their needs.
> >
> > This patch adds the eventdev specification header file.
> >
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > ---
> > + /** WORD1 */
> > + RTE_STD_C11
> > + union {
> > + uint64_t u64;
> > + /**< Opaque 64-bit value */
> > + uintptr_t event_ptr;
> > + /**< Opaque event pointer */
>
> Since we have a uint64_t member of the union, might this be better as a
> void * rather than uintptr_t?
No strong opinion here. For me, uintptr_t looks clean.
But, It is OK to change to void* as per your input.
>
> > + struct rte_mbuf *mbuf;
> > + /**< mbuf pointer if dequeued event is associated with mbuf */
> > + };
> > +};
> > +
> <snip>
> > +/**
> > + * Link multiple source event queues supplied in *rte_event_queue_link*
> > + * structure as *queue_id* to the destination event port designated by its
> > + * *port_id* on the event device designated by its *dev_id*.
> > + *
> > + * The link establishment shall enable the event port *port_id* from
> > + * receiving events from the specified event queue *queue_id*
> > + *
> > + * An event queue may link to one or more event ports.
> > + * The number of links can be established from an event queue to event port is
> > + * implementation defined.
> > + *
> > + * Event queue(s) to event port link establishment can be changed at runtime
> > + * without re-configuring the device to support scaling and to reduce the
> > + * latency of critical work by establishing the link with more event ports
> > + * at runtime.
>
> I think this might need to be clarified. The device doesn't need to be
> reconfigured, but does it need to be stopped? In SW implementation, this
> affects how much we have to make things thread-safe. At minimum I think
> we should limit this to having only one thread call the function at a
> time, but we may allow enqueue dequeue ops from the data plane to run
> in parallel.
Cavium implementation can change it at runtime without re-configuring or stopping
the device to support runtime load balancing from the application perspective.
AFAIK, link establishment is _NOT_ fast path API. But the application
can invoke it from worker thread whenever there is a need for re-wiring
the queue to port connection for better explicit load balancing. IMO, A
software implementation with lock is fine here as we don't use this in
fastpath.
Thoughts?
>
> > + *
> > + * @param dev_id
> > + * The identifier of the device.
> > + *
> > + *
> > + */
> > +int
> > +rte_event_port_link(uint8_t dev_id, uint8_t port_id,
> > + const struct rte_event_queue_link link[],
> > + uint16_t nb_links);
> > +
> > +/**
> > + * Unlink multiple source event queues supplied in *queues* from the destination
> > + * event port designated by its *port_id* on the event device designated
> > + * by its *dev_id*.
> > + *
> > + * The unlink establishment shall disable the event port *port_id* from
> > + * receiving events from the specified event queue *queue_id*
> > + *
> > + * Event queue(s) to event port unlink establishment can be changed at runtime
> > + * without re-configuring the device.
>
> Clarify, as above with link call.
Same as above.
>
> > + *
^ permalink raw reply
* Re: [PATCH v3] net/i40evf: fix reporting of imissed packets
From: Ferruh Yigit @ 2016-12-07 18:29 UTC (permalink / raw)
To: Tom Crugnale, jingjing.wu, helin.zhang; +Cc: dev
In-Reply-To: <1481055381-14243-1-git-send-email-tcrugnale@sandvine.com>
On 12/6/2016 8:16 PM, Tom Crugnale wrote:
> Missed packets on RX were erroneously being assigned to the ierrors
> struct member. Change it to be assigned to imissed.
>
> Fixes: 4861cde4 ("i40e: new poll mode driver")
>
> Signed-off-by: Tom Crugnale <tcrugnale@sandvine.com>
> ---
> v3:
> * Fixed coding style issues
> v2:
> * Fixed line breaks in original patch submission
> ---
>
> drivers/net/i40e/i40e_ethdev_vf.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c
> index aa306d6..90876c8 100644
> --- a/drivers/net/i40e/i40e_ethdev_vf.c
> +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> @@ -952,7 +952,7 @@ struct rte_i40evf_xstats_name_off {
> }
>
> static int
> -i40evf_get_statics(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
> +i40evf_get_stats(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
I aware this is simple modification, but if you can, can you please make
this separate patch?
Stable trees may not interested in internal function name changes but
may want to get stats counter fix.
> {
> int ret;
> struct i40e_eth_stats *pstats = NULL;
> @@ -965,7 +965,7 @@ struct rte_i40evf_xstats_name_off {
> pstats->rx_broadcast;
> stats->opackets = pstats->tx_broadcast + pstats->tx_multicast +
> pstats->tx_unicast;
> - stats->ierrors = pstats->rx_discards;
> + stats->imissed = pstats->rx_discards;
so won't VF driver report any rx_error?
> stats->oerrors = pstats->tx_errors + pstats->tx_discards;
This line is not part of the patch, but what do you think about this
one, should oerrors contain tx_discards values?
> stats->ibytes = pstats->rx_bytes;
> stats->obytes = pstats->tx_bytes;
> @@ -2277,8 +2277,8 @@ static int i40evf_dev_xstats_get(struct rte_eth_dev *dev,
> static void
> i40evf_dev_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
> {
> - if (i40evf_get_statics(dev, stats))
> - PMD_DRV_LOG(ERR, "Get statics failed");
> + if (i40evf_get_stats(dev, stats))
> + PMD_DRV_LOG(ERR, "Get stats failed");
> }
>
> static void
>
^ permalink raw reply
* Re: [PATCH] ethdev: don't look for devices if none were found
From: Thomas Monjalon @ 2016-12-07 18:08 UTC (permalink / raw)
To: Anatoly Burakov; +Cc: dev
In-Reply-To: <3a9d86aa005a8f8abc82349ee2a100ce464b7d0d.1479560838.git.anatoly.burakov@intel.com>
2016-11-19 13:10, Anatoly Burakov:
> Aside from avoiding doing useless work, this also fixes a segfault
> when calling rte_eth_dev_get_port_by_name() whenever no devices
> were found yet, and therefore rte_eth_dev_data wasn't yet allocated.
>
> Fixes: 9c5b8d8b9feb ("ethdev: clean port id retrieval when attaching")
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Title reworded: "ethdev: fix port lookup if none"
Applied, thanks
PS: your patches are not in patchwork because a strange character in
an email header and a bug in patchwork that I thought was fixed.
^ permalink raw reply
* [RFC] pci: remove unused UNBIND support
From: Stephen Hemminger @ 2016-12-07 18:04 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
No device driver sets the unbind flag in current public code base.
Therefore it is good time to remove the unused dead code.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/bsdapp/eal/eal_pci.c | 9 --------
lib/librte_eal/common/eal_common_pci.c | 5 -----
lib/librte_eal/common/include/rte_pci.h | 2 --
lib/librte_eal/linuxapp/eal/eal_pci.c | 39 ---------------------------------
4 files changed, 55 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c b/lib/librte_eal/bsdapp/eal/eal_pci.c
index 8b3ed88..3a5c315 100644
--- a/lib/librte_eal/bsdapp/eal/eal_pci.c
+++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
@@ -87,15 +87,6 @@
* enabling bus master.
*/
-/* unbind kernel driver for this device */
-int
-pci_unbind_kernel_driver(struct rte_pci_device *dev __rte_unused)
-{
- RTE_LOG(ERR, EAL, "RTE_PCI_DRV_FORCE_UNBIND flag is not implemented "
- "for BSD\n");
- return -ENOTSUP;
-}
-
/* Map pci device */
int
rte_eal_pci_map_device(struct rte_pci_device *dev)
diff --git a/lib/librte_eal/common/eal_common_pci.c b/lib/librte_eal/common/eal_common_pci.c
index 6bff675..33485bc 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -203,11 +203,6 @@ rte_eal_pci_probe_one_driver(struct rte_pci_driver *dr, struct rte_pci_device *d
ret = rte_eal_pci_map_device(dev);
if (ret != 0)
return ret;
- } else if (dr->drv_flags & RTE_PCI_DRV_FORCE_UNBIND &&
- rte_eal_process_type() == RTE_PROC_PRIMARY) {
- /* unbind current driver */
- if (pci_unbind_kernel_driver(dev) < 0)
- return -1;
}
/* reference driver structure */
diff --git a/lib/librte_eal/common/include/rte_pci.h b/lib/librte_eal/common/include/rte_pci.h
index 9ce8847..fbc4311 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -208,8 +208,6 @@ struct rte_pci_driver {
/** Device needs PCI BAR mapping (done with either IGB_UIO or VFIO) */
#define RTE_PCI_DRV_NEED_MAPPING 0x0001
-/** Device needs to be unbound even if no module is provided */
-#define RTE_PCI_DRV_FORCE_UNBIND 0x0004
/** Device driver supports link state interrupt */
#define RTE_PCI_DRV_INTR_LSC 0x0008
/** Device driver supports detaching capability */
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c b/lib/librte_eal/linuxapp/eal/eal_pci.c
index 876ba38..4350134 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -54,45 +54,6 @@
* IGB_UIO driver (or doesn't initialize, if the device wasn't bound to it).
*/
-/* unbind kernel driver for this device */
-int
-pci_unbind_kernel_driver(struct rte_pci_device *dev)
-{
- int n;
- FILE *f;
- char filename[PATH_MAX];
- char buf[BUFSIZ];
- struct rte_pci_addr *loc = &dev->addr;
-
- /* open /sys/bus/pci/devices/AAAA:BB:CC.D/driver */
- snprintf(filename, sizeof(filename),
- "%s/" PCI_PRI_FMT "/driver/unbind", pci_get_sysfs_path(),
- loc->domain, loc->bus, loc->devid, loc->function);
-
- f = fopen(filename, "w");
- if (f == NULL) /* device was not bound */
- return 0;
-
- n = snprintf(buf, sizeof(buf), PCI_PRI_FMT "\n",
- loc->domain, loc->bus, loc->devid, loc->function);
- if ((n < 0) || (n >= (int)sizeof(buf))) {
- RTE_LOG(ERR, EAL, "%s(): snprintf failed\n", __func__);
- goto error;
- }
- if (fwrite(buf, n, 1, f) == 0) {
- RTE_LOG(ERR, EAL, "%s(): could not write to %s\n", __func__,
- filename);
- goto error;
- }
-
- fclose(f);
- return 0;
-
-error:
- fclose(f);
- return -1;
-}
-
static int
pci_get_kernel_driver_by_path(const char *filename, char *dri_name)
{
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v2 19/32] net/i40e: set VF VLAN filter from PF
From: Iremonger, Bernard @ 2016-12-07 17:41 UTC (permalink / raw)
To: Yigit, Ferruh, Lu, Wenzhuo, dev@dpdk.org
In-Reply-To: <bfd52043-69d9-2b73-00a1-6a65dad81474@intel.com>
Hi Ferruh,
> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Wednesday, December 7, 2016 2:46 PM
> To: Lu, Wenzhuo <wenzhuo.lu@intel.com>; dev@dpdk.org
> Cc: Iremonger, Bernard <bernard.iremonger@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v2 19/32] net/i40e: set VF VLAN filter from
> PF
>
> On 12/7/2016 3:32 AM, Wenzhuo Lu wrote:
> > add rte_pmd_i40e_set_vf_vlan_filter API.
> > User can call the API on PF to enable/disable a set of VF's VLAN
> > filters.
> >
> > Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
> > ---
> > drivers/net/i40e/i40e_ethdev.c | 50
> +++++++++++++++++++++++++++++++
> > drivers/net/i40e/rte_pmd_i40e.h | 22 ++++++++++++++
> > drivers/net/i40e/rte_pmd_i40e_version.map | 1 +
> > 3 files changed, 73 insertions(+)
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > b/drivers/net/i40e/i40e_ethdev.c index 601e933..bc96698 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -10516,3 +10516,53 @@ int rte_pmd_i40e_set_vf_vlan_tag(uint8_t
> > port, uint16_t vf_id, uint8_t on)
> >
> > return ret;
> > }
> > +
> > +int rte_pmd_i40e_set_vf_vlan_filter(uint8_t port, uint16_t vlan_id,
> > + uint64_t vf_mask, uint8_t on) {
> <...>
> > +
> > + for (pool_idx = 0;
> > + pool_idx < ETH_64_POOLS && pool_idx < pf->nb_cfg_vmdq_vsi;
> > + pool_idx++) {
> > + if (vf_mask & ((uint64_t)(1ULL << pool_idx))) {
> > + if (on)
> > + ret = i40e_vsi_add_vlan(pf-
> >vmdq[pool_idx].vsi,
> > + vlan_id);
> > + else
> > + ret = i40e_vsi_delete_vlan(
> > + pf->vmdq[pool_idx].vsi, vlan_id);
> > + }
> > + }
> > +
> > + if (ret != I40E_SUCCESS)
> > + PMD_DRV_LOG(ERR, "Failed to set VF VLAN filter, on = %d",
> on);
>
> Since loop not break on error, this will only log the last one, if the error is in
> the middle, it is missed.
It would be better to break out of the loop on error.
>
> <...>
Regards,
Bernard.
^ permalink raw reply
* Re: [PATCH v3] kni: avoid using lsb_release script
From: Thomas Monjalon @ 2016-12-07 17:37 UTC (permalink / raw)
To: Robin Jarry; +Cc: dev, Ferruh Yigit
In-Reply-To: <fdfa1853-880a-4e57-1fec-b5d4745ebad0@intel.com>
2016-11-25 12:24, Ferruh Yigit:
> On 11/25/2016 12:22 PM, Robin Jarry wrote:
> > The lsb_release script is part of an optional package which is not
> > always installed. On the other hand, /etc/lsb-release is always present
> > even on minimal Ubuntu installations.
> >
> > root@ubuntu1604:~# dpkg -S /etc/lsb-release
> > base-files: /etc/lsb-release
> >
> > Read the file if present and use the variables defined in it.
> >
> > Signed-off-by: Robin Jarry <robin.jarry@6wind.com>
>
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH v2 16/32] net/i40e: add set VF VLAN insert function
From: Iremonger, Bernard @ 2016-12-07 17:36 UTC (permalink / raw)
To: Yigit, Ferruh, Lu, Wenzhuo, dev@dpdk.org
In-Reply-To: <a0331cec-719d-ac15-c833-eaab7f09ba90@intel.com>
Hi Ferruh,
> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Wednesday, December 7, 2016 2:26 PM
> To: Lu, Wenzhuo <wenzhuo.lu@intel.com>; dev@dpdk.org
> Cc: Iremonger, Bernard <bernard.iremonger@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v2 16/32] net/i40e: add set VF VLAN insert
> function
>
> On 12/7/2016 3:31 AM, Wenzhuo Lu wrote:
> > Support inserting VF VLAN id from PF.
> > User can call the API on PF to insert a VLAN id to a specific VF.
>
> Same comment with prev patch, does it make sense to insert " from PF" to
> patch title?
Consistency in the patch titles makes sense.
"set VF VLAN filter from PF" might be better.
> >
> > Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
> > ---
> > drivers/net/i40e/i40e_ethdev.c | 53
> +++++++++++++++++++++++++++++++
> > drivers/net/i40e/rte_pmd_i40e.h | 19 +++++++++++
> > drivers/net/i40e/rte_pmd_i40e_version.map | 1 +
> > 3 files changed, 73 insertions(+)
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > b/drivers/net/i40e/i40e_ethdev.c index 253209b..c571d8b 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -10361,3 +10361,56 @@ static void i40e_set_default_mac_addr(struct
> rte_eth_dev *dev,
> > else
> > return -EINVAL;
> > }
> > +
> > +int rte_pmd_i40e_set_vf_vlan_insert(uint8_t port, uint16_t vf_id,
> > + uint16_t vlan_id)
> > +{
> > + struct rte_eth_dev *dev;
> > + struct rte_eth_dev_info dev_info;
> > + struct i40e_pf *pf;
> > + struct i40e_pf_vf *vf;
> > + struct i40e_hw *hw;
> > + struct i40e_vsi *vsi;
> > + struct i40e_vsi_context ctxt;
> > + int ret;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port];
> > + rte_eth_dev_info_get(port, &dev_info);
> > +
> > + pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> > + hw = I40E_PF_TO_HW(pf);
> > +
> > + /**
> > + * return -ENODEV if SRIOV not enabled, VF number not configured
> > + * or no queue assigned.
> > + */
> > + if (!hw->func_caps.sr_iov_1_1 || pf->vf_num == 0 ||
> > + pf->vf_nb_qps == 0)
> > + return -ENODEV;
> > +
> > + if (vf_id > pf->vf_num)
if (vf_id >= pf->vf_num)
would be better.
> This check was [1] in prev patches:
> [1]
> if (vf_id > pf->vf_num - 1 || !pf->vfs)
if (vf_id >= pf->vf_num || !pf->vfs)
would be better.
>
> > + return -EINVAL;
> > +
> > + if (vlan_id > 4095)
>
> Can there be any define in base driver for this? Or ETH_VLAN_ID_MAX
> perhaps?
ETHER_MAX_VLAN_ID in rte_ether.h should be used .
> > + return -EINVAL;
> > +
> > + vf = &pf->vfs[vf_id];
> > + vsi = vf->vsi;
> > +
> > + vsi->info.valid_sections =
> cpu_to_le16(I40E_AQ_VSI_PROP_VLAN_VALID);
> > + vsi->info.port_vlan_flags |= I40E_AQ_VSI_PVLAN_INSERT_PVID;
> > + vsi->info.pvid = vlan_id;
> > +
>
> --->
> > + memset(&ctxt, 0, sizeof(ctxt));
> > + (void)rte_memcpy(&ctxt.info, &vsi->info, sizeof(vsi->info));
> > + ctxt.seid = vsi->seid;
> > +
> > + hw = I40E_VSI_TO_HW(vsi);
> > + ret = i40e_aq_update_vsi_params(hw, &ctxt, NULL);
> > + if (ret != I40E_SUCCESS)
> > + PMD_DRV_LOG(ERR, "Failed to update VSI params");
> <-----
>
> If Wenzhuo prefers to extract this part into a function, it can be re-used here
> too.
>
> <...>
^ permalink raw reply
* Re: [PATCH] config: remove insecure warnings
From: Thomas Monjalon @ 2016-12-07 17:34 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev
In-Reply-To: <20161205102745.GB329904@bricha3-MOBL3.ger.corp.intel.com>
2016-12-05 10:27, Bruce Richardson:
> On Sun, Dec 04, 2016 at 11:17:06PM +0100, Thomas Monjalon wrote:
> > There was an option CONFIG_RTE_INSECURE_FUNCTION_WARNING (disabled by
> > default), which prevents from using some libc functions:
> > sprintf, snprintf, vsnprintf, strcpy, strncpy, strcat, strncat, sscanf,
> > strtok, strsep and strlen.
> >
> > It's all about using them at the right place with the right precautions.
> > However, it is neither really possible nor a good advice to disable them.
> >
> > Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
>
> Agreed. That option has been in DPDK a long time and I suspect is never
> used.
>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Applied
^ permalink raw reply
* [PATCH] net/ixgbe: fix typo in comment
From: Ferruh Yigit @ 2016-12-07 17:19 UTC (permalink / raw)
To: dev; +Cc: Helin Zhang
Fixes: c03fcee9abbd ("ixgbe: remove CRC size from byte counters")
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
CC: stable@dpdk.org
---
drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index edc9b22..4626d01 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2564,9 +2564,9 @@ ixgbe_read_stats_registers(struct ixgbe_hw *hw,
uint32_t delta_gprc = 0;
unsigned i;
/* Workaround for RX byte count not including CRC bytes when CRC
-+ * strip is enabled. CRC bytes are removed from counters when crc_strip
+ * strip is enabled. CRC bytes are removed from counters when crc_strip
* is disabled.
-+ */
+ */
int crc_strip = (IXGBE_READ_REG(hw, IXGBE_HLREG0) &
IXGBE_HLREG0_RXCRCSTRP);
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v2 3/6] eventdev: implement the northbound APIs
From: Jerin Jacob @ 2016-12-07 17:02 UTC (permalink / raw)
To: Bruce Richardson
Cc: dev, thomas.monjalon, hemant.agrawal, gage.eads, harry.van.haaren
In-Reply-To: <20161206171712.GC22224@bricha3-MOBL3.ger.corp.intel.com>
On Tue, Dec 06, 2016 at 05:17:12PM +0000, Bruce Richardson wrote:
> On Tue, Dec 06, 2016 at 09:22:17AM +0530, Jerin Jacob wrote:
> > This patch implements northbound eventdev API interface using
> > southbond driver interface
> >
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > ---
> > + /* Re allocate memory to store queue priority */
> > + queues_prio = dev->data->queues_prio;
> > + queues_prio = rte_realloc(queues_prio,
> > + sizeof(queues_prio[0]) * nb_queues,
> > + RTE_CACHE_LINE_SIZE);
> > + if (queues_prio == NULL) {
> > + RTE_EDEV_LOG_ERR("failed to realloc queue priority,"
> > + " nb_queues %u", nb_queues);
> > + return -(ENOMEM);
> > + }
> > + dev->data->queues_prio = queues_prio;
> > +
> > + if (nb_queues > old_nb_queues) {
> > + uint8_t new_qs = nb_queues - old_nb_queues;
> > +
> > + memset(queues + old_nb_queues, 0,
> > + sizeof(queues[0]) * new_qs);
> > + memset(queues_prio + old_nb_queues, 0,
> > + sizeof(queues_prio[0]) * new_qs);
> > + }
> > + } else if (dev->data->queues != NULL && nb_queues == 0) {
> > + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->queue_release, -ENOTSUP);
> > +
> > + queues = dev->data->queues;
> > + for (i = nb_queues; i < old_nb_queues; i++)
> > + (*dev->dev_ops->queue_release)(queues[i]);
> > + }
> > +
> > + dev->data->nb_queues = nb_queues;
> > + return 0;
> > +}
> > +
> While the ports array makes sense to have available at the top level of
> the API and allocated from rte_eventdev.c, I'm not seeing what the value
> of having the queues allocated at that level is. The only time the queue
> array is indexed by eventdev layer is when releasing a queue. Therefore,
> I suggest just saving the number of queues for sanity checking and let
> the queue array allocation and freeing be handled entirely in the
> drivers themselves.
I thought it would be useful for other drivers. I agree, If something is not
common across all the driver lets remove it from common code.
I will remove it in v3
>
> /Bruce
^ permalink raw reply
* Re: [PATCH v2 26/32] app/testpmd: initialize receive mode for VMDq
From: Iremonger, Bernard @ 2016-12-07 17:00 UTC (permalink / raw)
To: Yigit, Ferruh, Lu, Wenzhuo, dev@dpdk.org
In-Reply-To: <1aa1ef1a-e823-8cc6-9b8f-06febdbd19ff@intel.com>
Hi Ferruh,
> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Wednesday, December 7, 2016 3:07 PM
> To: Lu, Wenzhuo <wenzhuo.lu@intel.com>; dev@dpdk.org
> Cc: Iremonger, Bernard <bernard.iremonger@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v2 26/32] app/testpmd: initialize receive
> mode for VMDq
>
> On 12/7/2016 3:32 AM, Wenzhuo Lu wrote:
> > Initialise VMDq in the init_port_config function in a similar way to
> > how it is done in the VMDq sample application.
>
> What is the effect of doing existing initialization?
This patch results in the function i40e_vmdq_setup() function being called in i40e_ethdev.c at
Line 1307: ret = i40e_vmdq_setup(dev);
We are seeing unexpected side effects from this patch.
It will be dropped from the v3 of this patch set, pending further investigation.
Regards,
Bernard.
^ permalink raw reply
* Re: [PATCH v2 03/12] crypto/armv8: Add core crypto operations for ARMv8
From: Jerin Jacob @ 2016-12-07 16:30 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: zbigniew.bodek, dev, pablo.de.lara.guarch, Emery Davis
In-Reply-To: <2244872.kAKz40o8xq@xps13>
On Wed, Dec 07, 2016 at 04:00:07PM +0100, Thomas Monjalon wrote:
> 2016-12-07 04:54, Jerin Jacob:
> > On Tue, Dec 06, 2016 at 02:41:01PM -0800, Thomas Monjalon wrote:
> > > 2016-12-07 03:35, Jerin Jacob:
> > > > On Tue, Dec 06, 2016 at 10:42:51PM +0100, Thomas Monjalon wrote:
> > > > > 2016-12-07 02:48, Jerin Jacob:
> > > > > > On Tue, Dec 06, 2016 at 09:29:25PM +0100, Thomas Monjalon wrote:
> > > > > > > 2016-12-06 18:32, zbigniew.bodek@caviumnetworks.com:
> > > > > > > > From: Zbigniew Bodek <zbigniew.bodek@caviumnetworks.com>
> > > > > > > >
> > > > > > > > This patch adds core low-level crypto operations
> > > > > > > > for ARMv8 processors. The assembly code is a base
> > > > > > > > for an optimized PMD and is currently excluded
> > > > > > > > from the build.
> > > > > > >
> > > > > > > It's a bit sad that you cannot achieve the same performance with
> > > > > > > C code and a good compiler.
> > > > > > > Have you tried it? How much is the difference?
> > > > > >
> > > > > > Like AES-NI on IA side(exposed as separate PMD in dpdk),
> > > > > > armv8 has special dedicated instructions for crypto operation using SIMD.
> > > > > > This patch is using the "dedicated" armv8 crypto instructions and SIMD
> > > > > > operation to achieve better performance.
> > > > >
> > > > > It does not justify to have all the code in asm.
> > > >
> > > > Why ? if we can have separate dpdk pmd for AES-NI on IA . Why not for ARM?
> > >
> > > Jerin, you or me is not understanding the other.
> > > It is perfectly fine to have a separate PMD.
> > > I am just talking about the language C vs ASM.
> >
> > Hmm. Both are bit connected topic :-)
> >
> > If you check the AES-NI PMD installation guide, We need to download the
> > "ASM" optimized AES-NI library and build with yasm.
> > We all uses fine grained ASM code such work.
> > So AES-NI case those are still ASM code but reside in some other
> > library.
>
> Yes
>
> > http://dpdk.org/doc/guides/cryptodevs/aesni_mb.html(Check Installation section)
> > https://downloadcenter.intel.com/download/22972
> >
> > Even linux kernel use, hardcore ASM for crypto work.
> > https://github.com/torvalds/linux/blob/master/arch/arm/crypto/aes-ce-core.S
>
> Yes
>
> > > > > > We had compared with openssl implementation.Here is the performance
> > > > > > improvement for chained crypto operations case WRT openssl pmd
> > > > > >
> > > > > > Buffer
> > > > > > Size(B) OPS(M) Throughput(Gbps)
> > > > > > 64 729 % 742 %
> > > > > > 128 577 % 592 %
> > > > > > 256 483 % 476 %
> > > > > > 512 336 % 351 %
> > > > > > 768 300 % 286 %
> > > > > > 1024 263 % 250 %
> > > > > > 1280 225 % 229 %
> > > > > > 1536 214 % 213 %
> > > > > > 1792 186 % 203 %
> > > > > > 2048 200 % 193 %
> > > > >
> > > > > OK but what is the performance difference between this asm code
> > > > > and a C equivalent?
> > > >
> > > > Do you you want compare against the scalar version of C code? its not
> > > > even worth to think about it. The vector version will use
> > > > dedicated armv8 instruction for crypto so its not portable anyway.
> > > > We would like to asm code so that we can have better control on what we do
> > > > and we cant rely compiler for that.
> > >
> > > No I'm talking about comparing a PMD written in C vs this one in ASM.
> >
> > Only fast stuff written in ASM. Remaining pmd is written in C.
> > Look "crypto/armv8: add PMD optimized for ARMv8 processors"
> >
> > > It"s just harder to read ASM. Most of DPDK code is in C.
> > > And only some small functions are written in ASM.
> > > The vector instructions use some C intrinsics.
> > > Do you mean that the instructions that you are using have no intrinsics
> > > equivalent? Nobody made it into GCC?
> >
> > There is intrinsic equivalent for crypto but that will work only on
> > armv8. If we start using the arch specific intrinsic then it better to
> > plain ASM code, it is clean and we all do similar scheme for core crypto
> > work(like AES-NI library, linux etc)
> >
> > We did a lot of effort to make clean armv8 ASM code _optimized_ for DPDK workload.
> > Just because someone doesn't familiar with armv8 Assembly its not fair to
> > say write it in C.
>
> I'm just saying it is sad, as it is sad for AES-NI or Linux code.
> Please read again my questions:
> Have you tried it? How much is the difference?
We haven't tried due to following reasons,
1) It is a norm in the industry to write such things in ASM.So we have to do it anyway.
2) It really takes a lot of R&D cycles first to write it in C and then ASM. So
skipped the R&D part and moved to ASM directly as we need to write in
ASM anyway.
> I'm not saying it should not enter in DPDK, I'm just asking some basic
> questions to better understand the motivations and the status of ARM crypto
> in general.
OK
> You did not answer for comparing with a C implementation, so I guess you
> have implemented it in ASM without even trying to do it in C.
> The conclusion: we will never know what is the real gain of coding this in ASM.
^ permalink raw reply
* Re: [PATCH] Scheduler: add driver for scheduler crypto pmd
From: Declan Doherty @ 2016-12-07 16:04 UTC (permalink / raw)
To: Richardson, Bruce, Neil Horman
Cc: Thomas Monjalon, Zhang, Roy Fan, dev@dpdk.org
In-Reply-To: <59AF69C657FD0841A61C55336867B5B035B54481@IRSMSX103.ger.corp.intel.com>
On 07/12/16 14:46, Richardson, Bruce wrote:
>
>
>> -----Original Message-----
>> From: Neil Horman [mailto:nhorman@tuxdriver.com]
>> Sent: Wednesday, December 7, 2016 2:17 PM
>> To: Doherty, Declan <declan.doherty@intel.com>
>> Cc: Richardson, Bruce <bruce.richardson@intel.com>; Thomas Monjalon
>> <thomas.monjalon@6wind.com>; Zhang, Roy Fan <roy.fan.zhang@intel.com>;
>> dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] Scheduler: add driver for scheduler crypto
>> pmd
>>
>> On Wed, Dec 07, 2016 at 12:42:15PM +0000, Declan Doherty wrote:
>>> On 05/12/16 15:12, Neil Horman wrote:
>>>> On Fri, Dec 02, 2016 at 04:22:16PM +0000, Declan Doherty wrote:
>>>>> On 02/12/16 14:57, Bruce Richardson wrote:
>>>>>> On Fri, Dec 02, 2016 at 03:31:24PM +0100, Thomas Monjalon wrote:
>>>>>>> 2016-12-02 14:15, Fan Zhang:
>>>>>>>> This patch provides the initial implementation of the
>>>>>>>> scheduler poll mode driver using DPDK cryptodev framework.
>>>>>>>>
>>>>>>>> Scheduler PMD is used to schedule and enqueue the crypto ops
>>>>>>>> to the hardware and/or software crypto devices attached to
>>>>>>>> it (slaves). The dequeue operation from the slave(s), and
>>>>>>>> the possible dequeued crypto op reordering, are then carried
>> out by the scheduler.
>>>>>>>>
>>>>>>>> The scheduler PMD can be used to fill the throughput gap
>>>>>>>> between the physical core and the existing cryptodevs to
>>>>>>>> increase the overall performance. For example, if a physical
>>>>>>>> core has higher crypto op processing rate than a cryptodev,
>>>>>>>> the scheduler PMD can be introduced to attach more than one
>> cryptodevs.
>>>>>>>>
>>>>>>>> This initial implementation is limited to supporting the
>>>>>>>> following scheduling modes:
>>>>>>>>
>>>>>>>> - CRYPTO_SCHED_SW_ROUND_ROBIN_MODE (round robin amongst
>> attached software
>>>>>>>> slave cryptodevs, to set this mode, the scheduler should
>> have been
>>>>>>>> attached 1 or more software cryptodevs.
>>>>>>>>
>>>>>>>> - CRYPTO_SCHED_HW_ROUND_ROBIN_MODE (round robin amongst
>> attached hardware
>>>>>>>> slave cryptodevs (QAT), to set this mode, the scheduler
>> should have
>>>>>>>> been attached 1 or more QATs.
>>>>>>>
>>>>>>> Could it be implemented on top of the eventdev API?
>>>>>>>
>>>>>> Not really. The eventdev API is for different types of
>>>>>> scheduling between multiple sources that are all polling for
>>>>>> packets, compared to this, which is more analgous - as I
>>>>>> understand it - to the bonding PMD for ethdev.
>>>>>>
>>>>>> To make something like this work with an eventdev API you would
>>>>>> need to use one of the following models:
>>>>>> * have worker cores for offloading packets to the different crypto
>>>>>> blocks pulling from the eventdev APIs. This would make it
>> difficult to
>>>>>> do any "smart" scheduling of crypto operations between the
>> blocks,
>>>>>> e.g. that one crypto instance may be better at certain types of
>>>>>> operations than another.
>>>>>> * move the logic in this driver into an existing eventdev
>> instance,
>>>>>> which uses the eventdev api rather than the crypto APIs and so
>> has an
>>>>>> extra level of "structure abstraction" that has to be worked
>> though.
>>>>>> It's just not really a good fit.
>>>>>>
>>>>>> So for this workload, I believe the pseudo-cryptodev instance is
>>>>>> the best way to go.
>>>>>>
>>>>>> /Bruce
>>>>>>
>>>>>
>>>>>
>>>>> As Bruce says this is much more analogous to the ethdev bonding
>>>>> driver, the main idea is to allow different crypto op scheduling
>>>>> mechanisms to be defined transparently to an application. This
>>>>> could be load-balancing across multiple hw crypto devices, or
>>>>> having a software crypto device to act as a backup device for a hw
>>>>> accelerator if it becomes oversubscribed. I think the main
>>>>> advantage of a crypto-scheduler approach means that the data path
>>>>> of the application doesn't need to have any knowledge that
>>>>> scheduling is happening at all, it is just using a different crypto
>> device id, which is then manages the distribution of crypto work.
>>>>>
>>>>>
>>>>>
>>>> This is a good deal like the bonding pmd, and so from a certain
>>>> standpoint it makes sense to do this, but whereas the bonding pmd is
>>>> meant to create a single path to a logical network over several
>>>> physical networks, this pmd really only focuses on maximizing
>>>> througput, and for that we already have tools. As Thomas mentions,
>>>> there is the eventdev library, but from my view the distributor
>>>> library already fits this bill. It already is a basic framework to
>>>> process mbufs in parallel according to whatever policy you want to
>> implement, which sounds like exactly what the goal of this pmd is.
>>>>
>>>> Neil
>>>>
>>>>
>>>
>>> Hey Neil,
>>>
>>> this is actually intended to act and look a good deal like the
>>> ethernet bonding device but to handling the crypto scheduling use cases.
>>>
>>> For example, take the case where multiple hw accelerators may be
>> available.
>>> We want to provide user applications with a mechanism to transparently
>>> balance work across all devices without having to manage the load
>>> balancing details or the guaranteeing of ordering of the processed ops
>>> on the dequeue_burst side. In this case the application would just use
>>> the crypto dev_id of the scheduler and it would look after balancing
>>> the workload across the available hw accelerators.
>>>
>>>
>>> +-------------------+
>>> | Crypto Sch PMD |
>>> | |
>>> | ORDERING / RR SCH |
>>> +-------------------+
>>> ^ ^ ^
>>> | | |
>>> +-+ | +-------------------------------+
>>> | +---------------+ |
>>> | | |
>>> V V V
>>> +---------------+ +---------------+ +---------------+
>>> | Crypto HW PMD | | Crypto HW PMD | | Crypto HW PMD |
>>> +---------------+ +---------------+ +---------------+
>>>
>>> Another use case we hope to support is migration of processing from
>>> one device to another where a hw and sw crypto pmd can be bound to the
>>> same crypto scheduler and the crypto processing could be
>>> transparently migrated from the hw to sw pmd. This would allow for hw
>>> accelerators to be hot-plugged attached/detached in a Guess VM
>>>
>>> +----------------+
>>> | Crypto Sch PMD |
>>> | |
>>> | MIGRATION SCH |
>>> +----------------+
>>> | |
>>> | +-----------------+
>>> | |
>>> V V
>>> +---------------+ +---------------+
>>> | Crypto HW PMD | | Crypto SW PMD |
>>> | (Active) | | (Inactive) |
>>> +---------------+ +---------------+
>>>
>>> The main point is that isn't envisaged as just a mechanism for
>>> scheduling crypto work loads across multiple cores, but a framework
>>> for allowing different scheduling mechanisms to be introduced, to
>>> handle different crypto scheduling problems, and done so in a way
>>> which is completely transparent to the data path of an application.
>>> Like the eth bonding driver we want to support creating the crypto
>>> scheduler from EAL options, which allow specification of the
>>> scheduling mode and the crypto pmds which are to be bound to that crypto
>> scheduler.
>>>
>>>
>> I get what its for, that much is pretty clear. But whereas the bonding
>> driver benefits from creating a single device interface for the purposes
>> of properly routing traffic through the network stack without exposing
>> that complexity to the using application, this pmd provides only
>> aggregation accoring to various policies. This is exactly what the
>> distributor library was built for, and it seems like a re-invention of the
>> wheel to ignore that. At the very least, you should implement this pmd on
>> top of the distributor library. If that is impracitcal, then I somewhat
>> question why we have the distributor library at all.
>>
>> Neil
>>
>
> Hi Neil,
>
> The distributor library, and the eventdev framework are not the solution here, as, firstly, the crypto devices are not cores, in the same way that ethdev's are not cores, and the distributor library is for evenly distributing work among cores. Sure, some crypto implementations may be software only, but many aren't, and those that are software still appear as a device to software that must be used like they were a HW device. In the same way that to use distributor to load balance traffic between various TX ports is not a suitable solution - because you need to use cores to do the work "bridging" between the distributor/eventdev and the ethdev device, similarly here, if we distribute traffic using the distributor, you need cores to pull those packets from the distributor and offload them to the crypto devices. To use the distributor library in place of this vpmd, we'd need crypto devices which are aware of how to talk to the distributor, and use it's protocols for pushing/pulling packets, or else we are pulling in extra core cycles to do bridging work.
>
> Secondly, the distributor and eventdev libraries are designed for doing flow based (generally atomic) packet distribution. Load balancing between crypto devices is not generally based on flows, but rather on other factors like packet size, offload cost per device, etc. To distributor/eventdev, all workers are equal, but for working with devices, for crypto offload or nic transmission, that is plainly not the case. In short the distribution problems that are being solved by distributor and eventdev libraries are fundamentally different than those being solved by this vpmd. They would be the wrong tool for the job.
>
> I would agree with the previous statements that this driver is far closer in functionality to the bonded ethdev driver than anything else. It makes multiple devices appear as a single one while hiding the complexity of the multiple devices to the using application. In the same way as the bonded ethdev driver has different modes for active-backup, and for active-active for increased throughput, this vpmd for crypto can have the exact same modes - multiple active bonded devices for higher performance operation, or two devices in active backup to enable migration when using SR-IOV as described by Declan above.
>
> Regards,
> /Bruce
>
I think that having scheduler in the pmd name here may be somewhat of a
loaded term and is muddying the waters of the problem we are trying to
address and I think if we were to rename this to crypto_bond_pmd it may
make our intent for what we want this pmd to achieve clearer.
Neil, in most of the initial scheduling use cases we want to address
with this pmd initially, we are looking to schedule within the context
of a single lcore on multiple hw accelerators or a mix of hw
accelerators and sw pmds and therefore using the distributor or the
eventdev wouldn't add a lot of value.
Declan
^ permalink raw reply
* Re: [PATCH v2 32/32] app/testpmd: fix invalid port ID
From: Ferruh Yigit @ 2016-12-07 15:48 UTC (permalink / raw)
To: Wenzhuo Lu, dev; +Cc: Chen Jing D(Mark)
In-Reply-To: <1481081535-37448-33-git-send-email-wenzhuo.lu@intel.com>
On 12/7/2016 3:32 AM, Wenzhuo Lu wrote:
> Some CLIs don't check the input port ID, it
> may cause segmentation fault (core dumped).
Are these functions (that we are adding extra check) added with this
patchset? If so why not add these checks where function implemented.
If these functions are already implemented before this patchset, this
patch can be standalone patch, instead of being part of this patchset,
and can be before this patchset so that it can be easily backported to
stable trees.
>
> Fixes: 425781ff5afe ("app/testpmd: add ixgbe VF management")
>
> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> Signed-off-by: Chen Jing D(Mark) <jing.d.chen@intel.com>
> ---
<...>
^ 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