* Re: [PATCH v2 02/25] doc: add rte_flow prog guide
From: Adrien Mazarguil @ 2016-12-19 11:10 UTC (permalink / raw)
To: Mcnamara, John; +Cc: dev@dpdk.org
In-Reply-To: <B27915DBBA3421428155699D51E4CFE202688A53@IRSMSX103.ger.corp.intel.com>
Hi John,
On Mon, Dec 19, 2016 at 10:45:32AM +0000, Mcnamara, John wrote:
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Adrien Mazarguil
> > Sent: Friday, December 16, 2016 4:25 PM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] [PATCH v2 02/25] doc: add rte_flow prog guide
> >
> > This documentation is based on the latest RFC submission, subsequently
> > updated according to feedback from the community.
>
> Hi,
>
> Thanks. That is a very good doc.
>
> A few RST comments.
>
> Section headers should use the use the following underline formats:
>
> Level 1 Heading
> ===============
>
>
> Level 2 Heading
> ---------------
>
>
> Level 3 Heading
> ~~~~~~~~~~~~~~~
>
>
> Level 4 Heading
> ^^^^^^^^^^^^^^^
>
> See: http://dpdk.org/doc/guides/contributing/documentation.html#rst-guidelines
OK, although I do not see any mistake regarding this?
> Also, some of the section headers for Attributes, Patterns, Match and Action
> are a bit short and it isn't clear what section you are in, especially in the
> PDF doc. It might be clearer to add the section name before each item like:
>
>
> Attribute: Group
> ~~~~~~~~~~~~~~~~
>
> Match: VOID
> ~~~~~~~~~~~
>
>
> Tables should have a reference link and a caption, like this:
>
> .. _table_qos_pipes:
>
> .. table:: Sample configuration for QOS pipes.
>
> +----------+----------+----------+
> | Header 1 | Header 2 | Header 3 |
> | | | |
> +==========+==========+==========+
> | Text | Text | Text |
> +----------+----------+----------+
> | ... | ... | ... |
> +----------+----------+----------+
>
>
> See: http://dpdk.org/doc/guides/contributing/documentation.html#tables
>
> This will make the tables clearer when there are several in a row and will allow
> the text to refer to them with :numref:.
>
> Also, there is one typo:
>
> s/unpractically/impractically/
>
>
> Otherwise, very good work. A good clear document.
Thanks, I will fix these and re-submit.
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* Re: [PATCH v5 19/29] app/testpmd: use unicast promiscuous mode on i40e
From: Ferruh Yigit @ 2016-12-19 11:05 UTC (permalink / raw)
To: Vincent JARDIN, dev; +Cc: Jingjing Wu, Helin Zhang, Wenzhuo Lu
In-Reply-To: <e50661f8-0909-1fd4-5cb4-ac30e23ffdd2@6wind.com>
On 12/16/2016 8:28 PM, Vincent JARDIN wrote:
> Le 16/12/2016 à 20:02, Ferruh Yigit a écrit :
>> +#ifdef RTE_LIBRTE_I40E_PMD
>> + ret = rte_pmd_i40e_set_vf_unicast_promisc(res->port_id,
>> + res->vf_id, is_on);
>> +#endif
>
> Why is an ifdef used here? It won't scale to all PMDs.
As explained in previous e-mail, because these are PMD specific APIs.
And it is not expected to scale to all PMDs.
>
> I means that you are missing an abstraction layer.
>
Yes, intentionally.
^ permalink raw reply
* Re: [PATCH v5 18/29] app/testpmd: use VFD APIs on i40e
From: Ferruh Yigit @ 2016-12-19 11:03 UTC (permalink / raw)
To: Vincent JARDIN, dev
Cc: Jingjing Wu, Helin Zhang, Wenzhuo Lu, Chen Jing D,
Bernard Iremonger
In-Reply-To: <716260c7-4120-9984-3c46-02ad50b11a94@6wind.com>
On 12/16/2016 8:30 PM, Vincent JARDIN wrote:
> Le 16/12/2016 à 20:02, Ferruh Yigit a écrit :
>> +#ifdef RTE_LIBRTE_IXGBE_PMD
>> "set all queues drop (port_id) (on|off)\n"
>> " Set drop enable bit for all queues.\n\n"
>>
>> "set vf split drop (port_id) (vf_id) (on|off)\n"
>> " Set split drop enable bit for a VF from the PF.\n\n"
>> +#endif
>
> it is not related to i40e. This serie should only be for i40e.
Please check the patch a little wider, it doesn't introduce the ifdef,
instead patch narrows down the scope of ifdef [1], because now some
functions are not just for ixgbe, but used both with i40e and ixgbe, so
the ifdef moved into the function itself [2].
[1]
-#ifdef RTE_LIBRTE_IXGBE_PMD
"set tx loopback (port_id) (on|off)\n"
" Enable or disable tx loopback.\n\n"
+#ifdef RTE_LIBRTE_IXGBE_PMD
"set all queues drop (port_id) (on|off)\n"
" Set drop enable bit for all queues.\n\n"
"set vf split drop (port_id) (vf_id) (on|off)\n"
" Set split drop enable bit for a VF from the PF.\n\n"
+#endif
"set vf mac antispoof (port_id) (vf_id) (on|off).\n"
" Set MAC antispoof for a VF from the PF.\n\n"
-#endif
[2]
@@ -11187,10 +11242,21 @@ cmd_set_tx_loopback_parsed(
...
+#ifdef RTE_LIBRTE_IXGBE_PMD
+ if (strstr(dev_info.driver_name, "ixgbe") != NULL)
+ ret = rte_pmd_ixgbe_set_tx_loopback(res->port_id, is_on);
+#endif
+#ifdef RTE_LIBRTE_I40E_PMD
+ if (strstr(dev_info.driver_name, "i40e") != NULL)
+ ret = rte_pmd_i40e_set_tx_loopback(res->port_id, is_on);
+#endif
>
> Moreover, it is a strange logic: how will it scale for all PMDs?
It won't.
That is why they are in ifdef.
These are PMD specific APIs, as naming convention shows "rte_pmd_i40e_..."
For the PMD features, which are not generic enough, but hardware is
capable and user may want to benefit from, PMD specific APIs exists.
Instead of these functions bloat the eth_dev layer, and give a fake
sense of abstraction, these APIs moved into PMDs.
And it is always possible to move these into ethdev layer, when multiple
PMDs supports same feature.
I agree this is something that needs to keep an eye on it, and be sure
if an API is generic, move it into eth_dev layer.
The application that use the PMD specific API, needs to be conditionally
compiled because that API may not always exits.
Thanks,
ferruh
^ permalink raw reply
* Re: [PATCH v2 03/25] doc: announce depreciation of legacy filter types
From: Mcnamara, John @ 2016-12-19 10:47 UTC (permalink / raw)
To: Adrien Mazarguil, dev@dpdk.org
In-Reply-To: <0bb1ee6fb4f4f4193658a71275ec1e2027282f05.1481903839.git.adrien.mazarguil@6wind.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Adrien Mazarguil
> Sent: Friday, December 16, 2016 4:25 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v2 03/25] doc: announce depreciation of legacy
> filter types
>
> They are superseded by the generic flow API (rte_flow). Target release is
> not defined yet.
>
> Suggested-by: Kevin Traynor <ktraynor@redhat.com>
> Signed-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 2d17bc6..4819078 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -71,3 +71,10 @@ Deprecation Notices
> * mempool: The functions for single/multi producer/consumer are
> deprecated
> and will be removed in 17.02.
> It is replaced by ``rte_mempool_generic_get/put`` functions.
> +
> +* ethdev: the legacy filter API, including
> +rte_eth_dev_filter_supported(),
> + rte_eth_dev_filter_ctrl() as well as filter types MACVLAN, ETHERTYPE,
> + FLEXIBLE, SYN, NTUPLE, TUNNEL, FDIR, HASH and L2_TUNNEL, is
> +superseded by
> + the generic flow API (rte_flow) in PMDs that implement the latter.
> + Target release for removal of the legacy API will be defined once
> +most
> + PMDs have switched to rte_flow.
All the function names and constants should be fixed width quoted:
``rte_eth_dev_filter_supported()``.
^ permalink raw reply
* Re: [PATCH v2 02/25] doc: add rte_flow prog guide
From: Mcnamara, John @ 2016-12-19 10:45 UTC (permalink / raw)
To: Adrien Mazarguil, dev@dpdk.org
In-Reply-To: <049b57d5216d8703bc5f2cdd29eabe40c2f09138.1481903839.git.adrien.mazarguil@6wind.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Adrien Mazarguil
> Sent: Friday, December 16, 2016 4:25 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v2 02/25] doc: add rte_flow prog guide
>
> This documentation is based on the latest RFC submission, subsequently
> updated according to feedback from the community.
Hi,
Thanks. That is a very good doc.
A few RST comments.
Section headers should use the use the following underline formats:
Level 1 Heading
===============
Level 2 Heading
---------------
Level 3 Heading
~~~~~~~~~~~~~~~
Level 4 Heading
^^^^^^^^^^^^^^^
See: http://dpdk.org/doc/guides/contributing/documentation.html#rst-guidelines
Also, some of the section headers for Attributes, Patterns, Match and Action
are a bit short and it isn't clear what section you are in, especially in the
PDF doc. It might be clearer to add the section name before each item like:
Attribute: Group
~~~~~~~~~~~~~~~~
Match: VOID
~~~~~~~~~~~
Tables should have a reference link and a caption, like this:
.. _table_qos_pipes:
.. table:: Sample configuration for QOS pipes.
+----------+----------+----------+
| Header 1 | Header 2 | Header 3 |
| | | |
+==========+==========+==========+
| Text | Text | Text |
+----------+----------+----------+
| ... | ... | ... |
+----------+----------+----------+
See: http://dpdk.org/doc/guides/contributing/documentation.html#tables
This will make the tables clearer when there are several in a row and will allow
the text to refer to them with :numref:.
Also, there is one typo:
s/unpractically/impractically/
Otherwise, very good work. A good clear document.
John
^ permalink raw reply
* Re: [PATCH v4] vmxnet3: fix Rx deadlock
From: Ferruh Yigit @ 2016-12-19 10:41 UTC (permalink / raw)
To: Stefan Puiu, dev; +Cc: yongwang, mac_leehk
In-Reply-To: <1482140453-49649-1-git-send-email-stefan.puiu@gmail.com>
On 12/19/2016 9:40 AM, Stefan Puiu wrote:
> Our use case is that we have an app that needs to keep mbufs around
> for a while. We've seen cases when calling vmxnet3_post_rx_bufs() from
> vmxet3_recv_pkts(), it might not succeed to add any mbufs to any RX
> descriptors (where it returns -err). Since there are no mbufs that the
> virtual hardware can use, no packets will be received after this; the
> driver won't refill the mbuf after this so it gets stuck in this
> state. I call this a deadlock for lack of a better term - the virtual
> HW waits for free mbufs, while the app waits for the hardware to
> notify it for data (by flipping the generation bit on the used Rx
> descriptors). Note that after this, the app can't recover.
>
> This fix is a rework of this patch by Marco Lee:
> http://dpdk.org/dev/patchwork/patch/6575/. I had to forward port
> it, address review comments and also reverted the allocation
> failure handling to the first version of the patch
> (http://dpdk.org/ml/archives/dev/2015-July/022079.html), since
> that's the only approach that seems to work, and seems to be what
> other drivers are doing (I checked ixgbe and em). Reusing the mbuf
> that's getting passed to the application doesn't seem to make
> sense, and it was causing weird issues in our app. Also, reusing
> rxm without checking if it's NULL could cause the code to crash.
>
> Signed-off-by: Stefan Puiu <stefan.puiu@gmail.com>
Applied to dpdk-next-net/master, thanks.
^ permalink raw reply
* Re: [PATCH v4] nfp: report link speed using hardware info
From: Alejandro Lucero @ 2016-12-19 10:32 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev
In-Reply-To: <724e9785-3499-ac5a-bf7a-8093a649780c@intel.com>
On Mon, Dec 19, 2016 at 10:24 AM, Ferruh Yigit <ferruh.yigit@intel.com>
wrote:
> On 12/16/2016 5:10 PM, Alejandro Lucero wrote:
> > Previous reported speed was hardcoded because there was not firmware
> > support for getting this information. This change needs to support old
> > firmware versions, keeping with the hardcoded report, and the new
> > versions, where the firmware makes that information available.
> >
> > v4: Make conditional simple and more ellaborated commit comment.
> > v3: remove unsed macro
> > v2: use RTE_DIM instead of own macro
> >
> > Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
> > ---
> > drivers/net/nfp/nfp_net.c | 27 +++++++++++++++++++++++++--
> > drivers/net/nfp/nfp_net_ctrl.h | 11 +++++++++++
> > 2 files changed, 36 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
> <...>
> > @@ -831,8 +842,20 @@ static void nfp_net_read_mac(struct nfp_net_hw *hw)
> > link.link_status = ETH_LINK_UP;
> >
> > link.link_duplex = ETH_LINK_FULL_DUPLEX;
> > - /* Other cards can limit the tx and rx rate per VF */
> > - link.link_speed = ETH_SPEED_NUM_40G;
> > +
> > + nn_link_status = (nn_link_status >> NFP_NET_CFG_STS_LINK_RATE_SHIFT)
> &
> > + NFP_NET_CFG_STS_LINK_RATE_MASK;
> > +
> > + if ((NFD_CFG_MAJOR_VERSION_of(hw->ver) < 4) ||
> > + ((NFD_CFG_MINOR_VERSION_of(hw->ver) == 4) &&
> > + (NFD_CFG_MINOR_VERSION_of(hw->ver) == 0)))
> > + link.link_speed = ETH_SPEED_NUM_40G;
> > + else {
> > + if (nn_link_status >= RTE_DIM(ls_to_ethtool)
>
> This is not compiling fine, missing parenthesis.
>
Sorry about that. It was so simple the change I did not do any test.
>
> > + link.link_speed = ETH_SPEED_NUM_NONE;
> > + else
> > + link.link_speed = ls_to_ethtool[nn_link_status];
> > + }
> >
> > if (old.link_status != link.link_status) {
> > nfp_net_dev_atomic_write_link_status(dev, &link);
> <...>
>
>
^ permalink raw reply
* Re: No packets received if burst is too small in rte_eth_rx_burst
From: Bruce Richardson @ 2016-12-19 10:25 UTC (permalink / raw)
To: tom.barbette; +Cc: dev
In-Reply-To: <1289578237.19546607.1481971405418.JavaMail.zimbra@ulg.ac.be>
On Sat, Dec 17, 2016 at 11:43:25AM +0100, tom.barbette@ulg.ac.be wrote:
> Hi,
>
> Your comments made me saw the line "PMD: i40e_set_rx_function(): Vector rx enabled, please make sure RX burst size no less than 4 (port=0)."
>
> The problem was probably that I was under this limit... Is there a way to get that limit through a function or something?
>
> With 16.04 I received sometimes 5 or 7 packets with a burst_size of 4 which respects this limit. I see that "[dpdk-dev] net/i40e: fix out-of-bounds writes during vector Rx" fixed that, as the limit was in fact 32 no matter the message.
>
> At the end, what should be the minimal rx burst size? How to find it at runtime for any NIC? I imagine that vector rx will create a problem if I give a burst size of 1 even with a recent DPDK version, right?
>
Sadly, there doesn't appear to be any way to discover this, and the i40e
driver requires at least a burst size of 4 even with the latest DPDK.
>From i40e_rxtx_vec_sse.c:
243 /* nb_pkts has to be floor-aligned to RTE_I40E_DESCS_PER_LOOP */
244 nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_I40E_DESCS_PER_LOOP);
245
I think in this case the gap is not so much having a discovery mechanism
to determine min burst size, but rather a driver gap so as to allow some
form of slower-path fallback when we get below min-size bursts for the
vector driver.
/Bruce
> Thanks,
> Tom
>
> Tom Barbette
> PhD Student @ Université de Liège
>
> Office 1/13
> Bâtiment B37
> Quartier Polytech
> Allée de la découverte, 12
> 4000 Liège
>
> 04/366 91 75
> 0479/60 94 63
>
>
> ----- Mail original -----
> De: "Bruce Richardson" <bruce.richardson@intel.com>
> À: "tom barbette" <tom.barbette@ulg.ac.be>
> Cc: dev@dpdk.org
> Envoyé: Mercredi 14 Décembre 2016 17:52:21
> Objet: Re: [dpdk-dev] No packets received if burst is too small in rte_eth_rx_burst
>
> On Wed, Dec 14, 2016 at 04:13:53PM +0100, tom.barbette@ulg.ac.be wrote:
> > Hi list,
> >
> > Between 2.2.0 and 16.04 (up to at least 16.07.2 if not current), with the XL710 controller I do not get any packet when calling rte_eth_rx_burst if nb_pkts is too small. I would say smaller than 32. The input rate is not big, if that helps. But It should definitely get at least one packet per second.
> >
> > Any ideas? Is that a bug or expected behaviour? Could be caused by other ABI changes?
> >
> Does this issue still occur even if you disable the vector driver in
> your build-time configuration?
>
> /Bruce
^ permalink raw reply
* Re: [PATCH v4] nfp: report link speed using hardware info
From: Ferruh Yigit @ 2016-12-19 10:24 UTC (permalink / raw)
To: Alejandro Lucero, dev
In-Reply-To: <1481908242-845-1-git-send-email-alejandro.lucero@netronome.com>
On 12/16/2016 5:10 PM, Alejandro Lucero wrote:
> Previous reported speed was hardcoded because there was not firmware
> support for getting this information. This change needs to support old
> firmware versions, keeping with the hardcoded report, and the new
> versions, where the firmware makes that information available.
>
> v4: Make conditional simple and more ellaborated commit comment.
> v3: remove unsed macro
> v2: use RTE_DIM instead of own macro
>
> Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
> ---
> drivers/net/nfp/nfp_net.c | 27 +++++++++++++++++++++++++--
> drivers/net/nfp/nfp_net_ctrl.h | 11 +++++++++++
> 2 files changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
<...>
> @@ -831,8 +842,20 @@ static void nfp_net_read_mac(struct nfp_net_hw *hw)
> link.link_status = ETH_LINK_UP;
>
> link.link_duplex = ETH_LINK_FULL_DUPLEX;
> - /* Other cards can limit the tx and rx rate per VF */
> - link.link_speed = ETH_SPEED_NUM_40G;
> +
> + nn_link_status = (nn_link_status >> NFP_NET_CFG_STS_LINK_RATE_SHIFT) &
> + NFP_NET_CFG_STS_LINK_RATE_MASK;
> +
> + if ((NFD_CFG_MAJOR_VERSION_of(hw->ver) < 4) ||
> + ((NFD_CFG_MINOR_VERSION_of(hw->ver) == 4) &&
> + (NFD_CFG_MINOR_VERSION_of(hw->ver) == 0)))
> + link.link_speed = ETH_SPEED_NUM_40G;
> + else {
> + if (nn_link_status >= RTE_DIM(ls_to_ethtool)
This is not compiling fine, missing parenthesis.
> + link.link_speed = ETH_SPEED_NUM_NONE;
> + else
> + link.link_speed = ls_to_ethtool[nn_link_status];
> + }
>
> if (old.link_status != link.link_status) {
> nfp_net_dev_atomic_write_link_status(dev, &link);
<...>
^ permalink raw reply
* Re: [PATCH v2 06/25] app/testpmd: implement basic support for rte_flow
From: Adrien Mazarguil @ 2016-12-19 10:19 UTC (permalink / raw)
To: Xing, Beilei; +Cc: dev@dpdk.org, Pei, Yulong
In-Reply-To: <94479800C636CB44BD422CB454846E013157433C@SHSMSX101.ccr.corp.intel.com>
Hi Beilei,
On Mon, Dec 19, 2016 at 08:37:20AM +0000, Xing, Beilei wrote:
> Hi Adrien,
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Adrien Mazarguil
> > Sent: Saturday, December 17, 2016 12:25 AM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] [PATCH v2 06/25] app/testpmd: implement basic
> > support for rte_flow
> >
> > Add basic management functions for the generic flow API (validate, create,
> > destroy, flush, query and list). Flow rule objects and properties are arranged
> > in lists associated with each port.
> >
> > Signed-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> > +/** Create flow rule. */
> > +int
> > +port_flow_create(portid_t port_id,
> > + const struct rte_flow_attr *attr,
> > + const struct rte_flow_item *pattern,
> > + const struct rte_flow_action *actions) {
> > + struct rte_flow *flow;
> > + struct rte_port *port;
> > + struct port_flow *pf;
> > + uint32_t id;
> > + struct rte_flow_error error;
> > +
>
> I think there should be memset for error here, e.g. memset(&error, 0, sizeof(struct rte_flow_error));
> Since both cause and message may be NULL regardless of the error type, if there's no error.cause and error.message returned from PMD, Segmentation fault will happen in port_flow_complain.
> PS: This issue doesn't happen if add "export EXTRA_CFLAGS=' -g O0'" when compiling.
Actually, PMDs must fill the error structure only in case of error if the
application provides one, it's not optional. I didn't initialize this
structure for this reason.
I suggest we initialize it with a known poisoning value for debugging
purposes though, to make it fail every time. Does it sound reasonable?
> > + flow = rte_flow_create(port_id, attr, pattern, actions, &error);
> > + if (!flow)
> > + return port_flow_complain(&error);
> > + port = &ports[port_id];
> > + if (port->flow_list) {
> > + if (port->flow_list->id == UINT32_MAX) {
> > + printf("Highest rule ID is already assigned, delete"
> > + " it first");
> > + rte_flow_destroy(port_id, flow, NULL);
> > + return -ENOMEM;
> > + }
> > + id = port->flow_list->id + 1;
> > + } else
> > + id = 0;
> > + pf = port_flow_new(attr, pattern, actions);
> > + if (!pf) {
> > + int err = rte_errno;
> > +
> > + printf("Cannot allocate flow: %s\n", rte_strerror(err));
> > + rte_flow_destroy(port_id, flow, NULL);
> > + return -err;
> > + }
> > + pf->next = port->flow_list;
> > + pf->id = id;
> > + pf->flow = flow;
> > + port->flow_list = pf;
> > + printf("Flow rule #%u created\n", pf->id);
> > + return 0;
> > +}
> > +
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* [PATCH v4] vmxnet3: fix Rx deadlock
From: Stefan Puiu @ 2016-12-19 9:40 UTC (permalink / raw)
To: dev; +Cc: yongwang, mac_leehk, Stefan Puiu
In-Reply-To: <1481902617-16050-1-git-send-email-stefan.puiu@gmail.com>
Our use case is that we have an app that needs to keep mbufs around
for a while. We've seen cases when calling vmxnet3_post_rx_bufs() from
vmxet3_recv_pkts(), it might not succeed to add any mbufs to any RX
descriptors (where it returns -err). Since there are no mbufs that the
virtual hardware can use, no packets will be received after this; the
driver won't refill the mbuf after this so it gets stuck in this
state. I call this a deadlock for lack of a better term - the virtual
HW waits for free mbufs, while the app waits for the hardware to
notify it for data (by flipping the generation bit on the used Rx
descriptors). Note that after this, the app can't recover.
This fix is a rework of this patch by Marco Lee:
http://dpdk.org/dev/patchwork/patch/6575/. I had to forward port
it, address review comments and also reverted the allocation
failure handling to the first version of the patch
(http://dpdk.org/ml/archives/dev/2015-July/022079.html), since
that's the only approach that seems to work, and seems to be what
other drivers are doing (I checked ixgbe and em). Reusing the mbuf
that's getting passed to the application doesn't seem to make
sense, and it was causing weird issues in our app. Also, reusing
rxm without checking if it's NULL could cause the code to crash.
Signed-off-by: Stefan Puiu <stefan.puiu@gmail.com>
---
v4:
* no change, just added sign-off
v3:
* rework description after review, explain how HW signals receipt of
packets
v2:
* address review comments, reworded description a bit
drivers/net/vmxnet3/vmxnet3_rxtx.c | 39 ++++++++++++++++++++++++++++++++++++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c b/drivers/net/vmxnet3/vmxnet3_rxtx.c
index b109168..93db10f 100644
--- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
+++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
@@ -518,6 +518,32 @@
return nb_tx;
}
+static inline void
+vmxnet3_renew_desc(vmxnet3_rx_queue_t *rxq, uint8_t ring_id,
+ struct rte_mbuf *mbuf)
+{
+ uint32_t val = 0;
+ struct vmxnet3_cmd_ring *ring = &rxq->cmd_ring[ring_id];
+ struct Vmxnet3_RxDesc *rxd =
+ (struct Vmxnet3_RxDesc *)(ring->base + ring->next2fill);
+ vmxnet3_buf_info_t *buf_info = &ring->buf_info[ring->next2fill];
+
+ if (ring_id == 0)
+ val = VMXNET3_RXD_BTYPE_HEAD;
+ else
+ val = VMXNET3_RXD_BTYPE_BODY;
+
+ buf_info->m = mbuf;
+ buf_info->len = (uint16_t)(mbuf->buf_len - RTE_PKTMBUF_HEADROOM);
+ buf_info->bufPA = rte_mbuf_data_dma_addr_default(mbuf);
+
+ rxd->addr = buf_info->bufPA;
+ rxd->btype = val;
+ rxd->len = buf_info->len;
+ rxd->gen = ring->gen;
+
+ vmxnet3_cmd_ring_adv_next2fill(ring);
+}
/*
* Allocates mbufs and clusters. Post rx descriptors with buffer details
* so that device can receive packets in those buffers.
@@ -657,9 +683,18 @@
}
while (rcd->gen == rxq->comp_ring.gen) {
+ struct rte_mbuf *newm;
+
if (nb_rx >= nb_pkts)
break;
+ newm = rte_mbuf_raw_alloc(rxq->mp);
+ if (unlikely(newm == NULL)) {
+ PMD_RX_LOG(ERR, "Error allocating mbuf");
+ rxq->stats.rx_buf_alloc_failure++;
+ break;
+ }
+
idx = rcd->rxdIdx;
ring_idx = (uint8_t)((rcd->rqID == rxq->qid1) ? 0 : 1);
rxd = (Vmxnet3_RxDesc *)rxq->cmd_ring[ring_idx].base + idx;
@@ -759,8 +794,8 @@
VMXNET3_INC_RING_IDX_ONLY(rxq->cmd_ring[ring_idx].next2comp,
rxq->cmd_ring[ring_idx].size);
- /* It's time to allocate some new buf and renew descriptors */
- vmxnet3_post_rx_bufs(rxq, ring_idx);
+ /* It's time to renew descriptors */
+ vmxnet3_renew_desc(rxq, ring_idx, newm);
if (unlikely(rxq->shared->ctrl.updateRxProd)) {
VMXNET3_WRITE_BAR0_REG(hw, rxprod_reg[ring_idx] + (rxq->queue_id * VMXNET3_REG_ALIGN),
rxq->cmd_ring[ring_idx].next2fill);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF on i40e
From: Chen, Jing D @ 2016-12-19 9:01 UTC (permalink / raw)
To: Vincent JARDIN, Yigit, Ferruh, dev@dpdk.org; +Cc: Wu, Jingjing, Zhang, Helin
In-Reply-To: <5846f66b-9a83-faa6-3de1-c7ae12236201@6wind.com>
Hi, Vincent,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Vincent JARDIN
> Sent: Saturday, December 17, 2016 4:36 AM
> To: Yigit, Ferruh <ferruh.yigit@intel.com>; dev@dpdk.org
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Zhang, Helin <helin.zhang@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF on
> i40e
>
> Le 16/12/2016 à 20:02, Ferruh Yigit a écrit :
> > As we need to support the scenario kernel PF + DPDK VF,
> > DPDK follows the interface between kernel PF + kernel VF.
>
> Please, it has to be proven that DPDK provides the same interface that
> the kernel. It seems insane to duplicate kernel's PF into the DPDK
> without a strong guarantee that it is a strict same behaviour. For instance,
> - what will happen when the DPDK's PF will have a new feature which
> is not into the kernel?
> - what will happen when the Kernel's PF will have a feature with
> different capabilities that the kernel?
>
> Please, make it clear before. Currently, for me it is a nack of this serie.
>
Let me try to explain.
When we DPDK developed i40e drivers several years ago, we found the API and
data structures defined in shared code for VF and PF device communication can
satisfy DPDK's requirements, so we just followed that API. At that time, we'll try
to satisfy 3 scenarios.
1. Linux PF + Linux VF : it's not our scope.
2. Linux PF + DPDK VF: there is no problems observed since we use same API.
3. DPDK PF + DPDK VF: that's fully under control.
The only scenario was not considered is DPDK PF + Linux VF.
Since then, both Linux and DPDK keep developing code. Then, we found it's
necessary to extend VF capability (Like promiscuous mode). It will be hard to
ask Linux PF to support that service considering upstream effort in Linux world.
So, supporting it in scenario of DPDK PF + DPDK VF became best candidate. But
how can VF identify who is serving it then decide if extended request can be dispatched?
So, DPDK PF will send a special version number for this purpose.
As time passed by, we realized there some use case for DPDK PF + Linux VF and it's not
supported yet. Then, we found our implementation in DPDK PF is not complete since we
only had considered how to serve DPDK VF at that time. So, we need some improvement
on the PF host driver. Besides that, 'send a special version' to VF doesn't work now since
Linux VF can't interpret the version info. So, we behave the same as Linux PF driver with
sacrifice of extended function in DPDK VF.
Let me summary the chang here.
1. We shared the same interface with Linux driver from beginning.
2. This change will support both Linux VF and DPDK VF.
3. We'll find a way for DPDK VF identifying who is serving it so it can use extended function
in future release.
^ permalink raw reply
* Re: [PATCH v2 06/25] app/testpmd: implement basic support for rte_flow
From: Xing, Beilei @ 2016-12-19 8:37 UTC (permalink / raw)
To: Adrien Mazarguil, dev@dpdk.org; +Cc: Pei, Yulong
In-Reply-To: <3318a43c9e105caaf4d5b13d6e4fcce774fb522f.1481903839.git.adrien.mazarguil@6wind.com>
Hi Adrien,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Adrien Mazarguil
> Sent: Saturday, December 17, 2016 12:25 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v2 06/25] app/testpmd: implement basic
> support for rte_flow
>
> Add basic management functions for the generic flow API (validate, create,
> destroy, flush, query and list). Flow rule objects and properties are arranged
> in lists associated with each port.
>
> Signed-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> +/** Create flow rule. */
> +int
> +port_flow_create(portid_t port_id,
> + const struct rte_flow_attr *attr,
> + const struct rte_flow_item *pattern,
> + const struct rte_flow_action *actions) {
> + struct rte_flow *flow;
> + struct rte_port *port;
> + struct port_flow *pf;
> + uint32_t id;
> + struct rte_flow_error error;
> +
I think there should be memset for error here, e.g. memset(&error, 0, sizeof(struct rte_flow_error));
Since both cause and message may be NULL regardless of the error type, if there's no error.cause and error.message returned from PMD, Segmentation fault will happen in port_flow_complain.
PS: This issue doesn't happen if add "export EXTRA_CFLAGS=' -g O0'" when compiling.
Thanks
Beilei
> + flow = rte_flow_create(port_id, attr, pattern, actions, &error);
> + if (!flow)
> + return port_flow_complain(&error);
> + port = &ports[port_id];
> + if (port->flow_list) {
> + if (port->flow_list->id == UINT32_MAX) {
> + printf("Highest rule ID is already assigned, delete"
> + " it first");
> + rte_flow_destroy(port_id, flow, NULL);
> + return -ENOMEM;
> + }
> + id = port->flow_list->id + 1;
> + } else
> + id = 0;
> + pf = port_flow_new(attr, pattern, actions);
> + if (!pf) {
> + int err = rte_errno;
> +
> + printf("Cannot allocate flow: %s\n", rte_strerror(err));
> + rte_flow_destroy(port_id, flow, NULL);
> + return -err;
> + }
> + pf->next = port->flow_list;
> + pf->id = id;
> + pf->flow = flow;
> + port->flow_list = pf;
> + printf("Flow rule #%u created\n", pf->id);
> + return 0;
> +}
> +
^ permalink raw reply
* Re: Virtio driver lockup in KVM
From: Maxime Coquelin @ 2016-12-19 8:29 UTC (permalink / raw)
To: Sreenaath Vasudevan, dev
In-Reply-To: <CANNY8mk5XM1tRyPyEpo4ogypaQKCArqCLjDDK6pK2-DpCDnMdA@mail.gmail.com>
Hi Sreenaath,
On 12/19/2016 09:21 AM, Sreenaath Vasudevan wrote:
> Hi
> I am running a DPDK application with virtio driver and ran in to driver rx
> lockup issue.
Are you running vhost-user DPDK backend on host or Kernel backend?
> The application seems to be running fine for couple of hours before it
> stops receiving packets on the interface. Transmission of packets seems to
> work fine on the same interface while reception of packets stop.
> Has anyone run in to anything similar?
Not that I am aware, I would suggest you recompile DPDK with debug,
attach to the DPDK process when it happens and check what PMd threads
are doing.
>
> Following is the environment
> Application runnign dpdk-2.2
> VM running on KVM hypervisor using VIRTIO driver
>
Cheers,
Maxime
^ permalink raw reply
* Virtio driver lockup in KVM
From: Sreenaath Vasudevan @ 2016-12-19 8:21 UTC (permalink / raw)
To: dev
Hi
I am running a DPDK application with virtio driver and ran in to driver rx
lockup issue.
The application seems to be running fine for couple of hours before it
stops receiving packets on the interface. Transmission of packets seems to
work fine on the same interface while reception of packets stop.
Has anyone run in to anything similar?
Following is the environment
Application runnign dpdk-2.2
VM running on KVM hypervisor using VIRTIO driver
--
regards
sreenaath
^ permalink raw reply
* Re: [PATCH 1/4] eal/common: introduce rte_memset on IA platform
From: Yuanhan Liu @ 2016-12-19 6:27 UTC (permalink / raw)
To: Yang, Zhiyong
Cc: Richardson, Bruce, Ananyev, Konstantin, Thomas Monjalon,
dev@dpdk.org, De Lara Guarch, Pablo, Wang, Zhihong
In-Reply-To: <E182254E98A5DA4EB1E657AC7CB9BD2A3EB59F21@BGSMSX101.gar.corp.intel.com>
On Fri, Dec 16, 2016 at 10:19:43AM +0000, Yang, Zhiyong wrote:
> > > I run the same virtio/vhost loopback tests without NIC.
> > > I can see the throughput drop when running choosing functions at run
> > > time compared to original code as following on the same platform(my
> > machine is haswell)
> > > Packet size perf drop
> > > 64 -4%
> > > 256 -5.4%
> > > 1024 -5%
> > > 1500 -2.5%
> > > Another thing, I run the memcpy_perf_autotest, when N= <128, the
> > > rte_memcpy perf gains almost disappears When choosing functions at run
> > > time. For N=other numbers, the perf gains will become narrow.
> > >
> > How narrow. How significant is the improvement that we gain from having to
> > maintain our own copy of memcpy. If the libc version is nearly as good we
> > should just use that.
> >
> > /Bruce
>
> Zhihong sent a patch about rte_memcpy, From the patch,
> we can see the optimization job for memcpy will bring obvious perf improvements
> than glibc for DPDK.
Just a clarification: it's better than the __original DPDK__ rte_memcpy
but not the glibc one. That makes me think have any one tested the memcpy
with big packets? Does the one from DPDK outweigh the one from glibc,
even for big packets?
--yliu
> http://www.dpdk.org/dev/patchwork/patch/17753/
> git log as following:
> This patch is tested on Ivy Bridge, Haswell and Skylake, it provides
> up to 20% gain for Virtio Vhost PVP traffic, with packet size ranging
> from 64 to 1500 bytes.
>
> thanks
> Zhiyong
^ permalink raw reply
* [PATCH 2/2] net/ixgbe: calculate correct number of received packets for ARM NEON-version vPMD
From: Jianbo Liu @ 2016-12-19 6:09 UTC (permalink / raw)
To: dev, helin.zhang, konstantin.ananyev, jerin.jacob; +Cc: Jianbo Liu
In-Reply-To: <1482127758-4904-1-git-send-email-jianbo.liu@linaro.org>
vPMD will check 4 descriptors in one time, but the statuses are not consistent
because the memory allocated for RX descriptors is cacheable huagepage.
This patch is to calculate the number of received packets by scanning DD bit
sequentially, and stops when meeting the first packet with DD bit unset.
Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
---
drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c b/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
index f96cc85..0b1338d 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
@@ -196,7 +196,6 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct rte_mbuf **rx_pkts,
struct ixgbe_rx_entry *sw_ring;
uint16_t nb_pkts_recd;
int pos;
- uint64_t var;
uint8x16_t shuf_msk = {
0xFF, 0xFF,
0xFF, 0xFF, /* skip 32 bits pkt_type */
@@ -255,6 +254,7 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct rte_mbuf **rx_pkts,
uint64x2_t mbp1, mbp2;
uint8x16_t staterr;
uint16x8_t tmp;
+ uint32_t var = 0;
uint32_t stat;
/* B.1 load 1 mbuf point */
@@ -349,11 +349,19 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct rte_mbuf **rx_pkts,
vst1q_u8((uint8_t *)&rx_pkts[pos]->rx_descriptor_fields1,
pkt_mb1);
+ stat &= IXGBE_VPMD_DESC_DD_MASK;
+
/* C.4 calc avaialbe number of desc */
- var = __builtin_popcount(stat & IXGBE_VPMD_DESC_DD_MASK);
- nb_pkts_recd += var;
- if (likely(var != RTE_IXGBE_DESCS_PER_LOOP))
+ if (likely(var != IXGBE_VPMD_DESC_DD_MASK)) {
+ while (stat & 0x01) {
+ ++var;
+ stat = stat >> 8;
+ }
+ nb_pkts_recd += var;
break;
+ } else {
+ nb_pkts_recd += RTE_IXGBE_DESCS_PER_LOOP;
+ }
}
/* Update our internal tail pointer */
--
2.4.11
^ permalink raw reply related
* [PATCH 1/2] net/ixgbe: calculate the correct number of received packets in bulk alloc function
From: Jianbo Liu @ 2016-12-19 6:09 UTC (permalink / raw)
To: dev, helin.zhang, konstantin.ananyev, jerin.jacob; +Cc: Jianbo Liu
To get better performance, Rx bulk alloc recv function will scan 8 descriptors
in one time, but the statuses are not consistent on ARM platform because
the memory allocated for Rx descriptors is cacheable hugepages.
This patch is to calculate the number of received packets by scanning DD bit
sequentially, and stops when meeting the first packet with DD bit unset.
Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
---
drivers/net/ixgbe/ixgbe_rxtx.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index b2d9f45..2866bdb 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -1402,17 +1402,21 @@ ixgbe_rx_scan_hw_ring(struct ixgbe_rx_queue *rxq)
for (i = 0; i < RTE_PMD_IXGBE_RX_MAX_BURST;
i += LOOK_AHEAD, rxdp += LOOK_AHEAD, rxep += LOOK_AHEAD) {
/* Read desc statuses backwards to avoid race condition */
- for (j = LOOK_AHEAD-1; j >= 0; --j)
+ for (j = LOOK_AHEAD - 1; j >= 0; --j) {
s[j] = rte_le_to_cpu_32(rxdp[j].wb.upper.status_error);
-
- for (j = LOOK_AHEAD - 1; j >= 0; --j)
pkt_info[j] = rte_le_to_cpu_32(rxdp[j].wb.lower.
lo_dword.data);
+ }
+
+ rte_smp_rmb();
/* Compute how many status bits were set */
nb_dd = 0;
for (j = 0; j < LOOK_AHEAD; ++j)
- nb_dd += s[j] & IXGBE_RXDADV_STAT_DD;
+ if (s[j] & IXGBE_RXDADV_STAT_DD)
+ ++nb_dd;
+ else
+ break;
nb_rx += nb_dd;
--
2.4.11
^ permalink raw reply related
* Re: [PATCH 09/32] lib/ether: add rte_device in rte_eth_dev
From: Hemant Agrawal @ 2016-12-19 5:30 UTC (permalink / raw)
To: Ferruh Yigit, dev@dpdk.org
Cc: thomas.monjalon@6wind.com, Richardson, Bruce,
shreyansh.jain@nxp.com
In-Reply-To: <4ced5dc6-c2d7-a4d9-b7a1-29476efd9791@intel.com>
On 12/15/2016 8:11 PM, Ferruh Yigit wrote:
> On 12/7/2016 6:41 AM, Hemant Agrawal wrote:
>> On 12/7/2016 1:18 AM, Ferruh Yigit wrote:
>>> On 12/4/2016 6:17 PM, Hemant Agrawal wrote:
>>>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>>>> ---
>>>> lib/librte_ether/rte_ethdev.h | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
>>>> index 3c45a1f..6f5673f 100644
>>>> --- a/lib/librte_ether/rte_ethdev.h
>>>> +++ b/lib/librte_ether/rte_ethdev.h
>>>> @@ -1626,6 +1626,7 @@ struct rte_eth_dev {
>>>> eth_rx_burst_t rx_pkt_burst; /**< Pointer to PMD receive function. */
>>>> eth_tx_burst_t tx_pkt_burst; /**< Pointer to PMD transmit function. */
>>>> struct rte_eth_dev_data *data; /**< Pointer to device data */
>>>> + struct rte_device *device;
>>>
>>> I believe this change should not be part of a PMD patchset. This change
>>> is more generic than the PMD.
>>>
>>> Won't Shreyansh's patch already do this?
>>
>> I agree that this patch is not a fit for this PMD patchset, Shreyansh's
>> patch is not yet doing it. He will be taking care of it next.
>>
>> So till Shreyansh provide the support, we need it.
>
> If you need it, what do you think sending this as a separate patch? And
> when accepted, your driver can use it?
>
I will prefer to keep this patch as the first patch in my patchset. If
Shreyansh's patch come on time, we can easily remove it.
>>
>>>
>>>> const struct eth_driver *driver;/**< Driver for this device */
>>>> const struct eth_dev_ops *dev_ops; /**< Functions exported by PMD */
>>>> struct rte_pci_device *pci_dev; /**< PCI info. supplied by probing */
>>>>
>>>
>>>
>>
>>
>
>
^ permalink raw reply
* Re: [PATCH 02/32] drivers/common: introducing dpaa2 mc driver
From: Hemant Agrawal @ 2016-12-19 5:27 UTC (permalink / raw)
To: Jerin Jacob
Cc: dev, thomas.monjalon, bruce.richardson, shreyansh.jain,
Cristian Sovaiala
In-Reply-To: <20161215060453.GA19354@localhost.localdomain>
On 12/15/2016 11:34 AM, Jerin Jacob wrote:
> On Sun, Dec 04, 2016 at 11:46:57PM +0530, Hemant Agrawal wrote:
>> This patch intoduces the DPAA2 MC(Management complex Driver)
>>
>> This driver is common to be used by various DPAA2 net, crypto
>> and other drivers
>>
>> Signed-off-by: Cristian Sovaiala <cristian.sovaiala@nxp.com>
>> [Hemant:rebase and conversion to library for DPDK]
>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>> +#ifndef _FSL_MC_SYS_H
>> +#define _FSL_MC_SYS_H
>> +
>> +#ifdef __linux_driver__
>> +
>> +#include <linux/errno.h>
>> +#include <asm/io.h>
>> +#include <linux/slab.h>
>> +
>> +struct fsl_mc_io {
>> + void *regs;
>> +};
>> +
>> +#ifndef ENOTSUP
>> +#define ENOTSUP 95
>> +#endif
>> +
>> +#define ioread64(_p) readq(_p)
>> +#define iowrite64(_v, _p) writeq(_v, _p)
>> +
>> +#else /* __linux_driver__ */
>> +
>> +#include <stdio.h>
>> +#include <libio.h>
>> +#include <stdint.h>
>> +#include <errno.h>
>> +#include <sys/uio.h>
>> +#include <linux/byteorder/little_endian.h>
>> +
>> +#define cpu_to_le64(x) __cpu_to_le64(x)
>> +#ifndef dmb
>> +#define dmb() {__asm__ __volatile__("" : : : "memory"); }
>> +#endif
>
> Better to use DPDK macros here.
>
>> +#define __iormb() dmb()
>> +#define __iowmb() dmb()
>> +#define __arch_getq(a) (*(volatile unsigned long *)(a))
>> +#define __arch_putq(v, a) (*(volatile unsigned long *)(a) = (v))
>> +#define __arch_putq32(v, a) (*(volatile unsigned int *)(a) = (v))
>> +#define readq(c) \
>> + ({ uint64_t __v = __arch_getq(c); __iormb(); __v; })
>> +#define writeq(v, c) \
>> + ({ uint64_t __v = v; __iowmb(); __arch_putq(__v, c); __v; })
>> +#define writeq32(v, c) \
>> + ({ uint32_t __v = v; __iowmb(); __arch_putq32(__v, c); __v; })
>> +#define ioread64(_p) readq(_p)
>> +#define iowrite64(_v, _p) writeq(_v, _p)
>> +#define iowrite32(_v, _p) writeq32(_v, _p)
>
> Hopefully, we can clean all this once rte_read32 and rte_write32 becomes
> mainline
>
> http://dpdk.org/dev/patchwork/patch/17935/
I agree, We will update it as your other patch progresses.
>> +#define __iomem
>> +
>> +struct fsl_mc_io {
>> + void *regs;
>> +};
>> +
>> +#ifndef ENOTSUP
>> +#define ENOTSUP 95
>> +#endif
>> +
>> +/*GPP is supposed to use MC commands with low priority*/
>> +#define CMD_PRI_LOW 0 /*!< Low Priority command indication */
>> +
>> +struct mc_command;
>> +
>> +int mc_send_command(struct fsl_mc_io *mc_io, struct mc_command *cmd);
>> +
>> +#endif /* __linux_driver__ */
>> +
>> +#endif /* _FSL_MC_SYS_H */
>> +
>> +/** User space framework uses MC Portal in shared mode. Following change
>> +* introduces lock in MC FLIB
>> +*/
>> +
>> +/**
>> +* The mc_spinlock_t type.
>> +*/
>> +typedef struct {
>> + volatile int locked; /**< lock status 0 = unlocked, 1 = locked */
>> +} mc_spinlock_t;
>> +
>> +/**
>> +* A static spinlock initializer.
>> +*/
>> +static mc_spinlock_t mc_portal_lock = { 0 };
>> +
>> +static inline void mc_pause(void) {}
>> +
>> +static inline void mc_spinlock_lock(mc_spinlock_t *sl)
>> +{
>> + while (__sync_lock_test_and_set(&sl->locked, 1))
>> + while (sl->locked)
>> + mc_pause();
>> +}
>> +
>> +static inline void mc_spinlock_unlock(mc_spinlock_t *sl)
>> +{
>> + __sync_lock_release(&sl->locked);
>> +}
>> +
>
> DPDK spinlock can be used here.
>
Yes!
^ permalink raw reply
* Re: [PATCH v3 0/6] libeventdev API and northbound implementation
From: Shreyansh Jain @ 2016-12-19 5:16 UTC (permalink / raw)
To: Jerin Jacob
Cc: dev, thomas.monjalon, bruce.richardson, hemant.agrawal, gage.eads,
harry.van.haaren
In-Reply-To: <1482070895-32491-1-git-send-email-jerin.jacob@caviumnetworks.com>
My mail reader (thunderbird) is showing this series as a thread of "eal:
postpone vdev initialization" patch series. Is it just me?
If it is a wrong 'in-reply-to', I think it should be corrected or people
might not be able to search for this under right thread.
On Sunday 18 December 2016 07:51 PM, Jerin Jacob wrote:
> As previously discussed in RFC v1 [1], RFC v2 [2], with changes
> described in [3] (also pasted below), here is the first non-draft series
> for this new API.
>
> [1] http://dpdk.org/ml/archives/dev/2016-August/045181.html
> [2] http://dpdk.org/ml/archives/dev/2016-October/048592.html
> [3] http://dpdk.org/ml/archives/dev/2016-October/048196.html
>
> v2..v3:
>
> 1) Changed struct rte_event layout more aligment balanced(Harry, Jerin)
> 2) Changed event_ptr type to void* from uintptr_t(Bruce)
> 3) Changed ev[] as const in rte_event_enqueue_burst to disallow
> drivers from modifying the events passed in(Bruce)
> 4) Removed queue memory allocation from common code as some drivers may not need
> it(Bruce)
> 5) Removed "struct rte_event_queue_link" and replaced with queues and priorities
> in the link and link_get API to avoid one redirection to use the API(Bruce)
>
> v1..v2:
> 1) Remove unnecessary header files from rte_eventdev.h(Thomas)
> 2) Removed PMD driver name(EVENTDEV_NAME_SKELETON_PMD) from rte_eventdev.h(Thomas)
> 3) Removed different #define for different priority schemes. Changed to
> one event device RTE_EVENT_DEV_PRIORITY_* priority (Bruce)
> 4) add const to rte_event_dev_configure(), rte_event_queue_setup(),
> rte_event_port_setup(), rte_event_port_link()(Bruce)
> 5) Fixed missing dev argument in dev->schedule() function(Bruce)
> 6) Changed \see to @see in doxgen comments(Thomas)
> 7) Added additional text in specification to clarify the queue depth(Thomas)
> 8) Changed wait to timeout across the specification(Thomas)
> 9) Added longer explanation for RTE_EVENT_OP_NEW and RTE_EVENT_OP_FORWARD(Thomas)
> 10) Fixed issue with RTE_EVENT_OP_RELEASE doxgen formatting(Thomas)
> 11) Changed to RTE_EVENT_DEV_CFG_FLAG_ from RTE_EVENT_DEV_CFG_(Thomas)
> 12) Changed to EVENT_QUEUE_CFG_FLAG_ from EVENT_QUEUE_CFG_(Thomas)
> 13) s/RTE_EVENT_TYPE_CORE/RTE_EVENT_TYPE_CPU/(Thomas, Gage)
> 14) Removed non burst API and kept only the burst API in the API specification
> (Thomas, Bruce, Harry, Jerin)
> -- Driver interface has non burst API, selection of the non burst API is based
> on num_objects == 1
> 15) sizeeof(struct rte_event) was not 16 in v1. Fixed it in v2
> -- reduced the width of event_type to 4bit to save space for future change
> -- introduced impl_opaque for implementation specific opaque data(Harry),
> Something useful for HW driver too, in the context of removal the need for sepeare
> release API.
> -- squashed other element size and provided enough space to impl_opaque(Jerin)
> -- added RTE_BUILD_BUG_ON(sizeof(struct rte_event) != 16); check
> 16) add union of uint64_t in the second element in struct rte_event to
> make sure the structure has 16byte address all arch(Thomas)
> 17) Fixed invalid check of nb_atomic_order_sequences in implementation(Gage)
> 18) s/EDEV_LOG_ERR/RTE_EDEV_LOG_ERR(Thomas)
> 19) s/rte_eventdev_pmd_/rte_event_pmd_/(Bruce)
> 20) added fine details of distributed vs centralized scheduling information
> in the specification and introduced RTE_EVENT_DEV_CAP_FLAG_DISTRIBUTED_SCHED
> flag(Gage)
> 21)s/RTE_EVENT_QUEUE_CFG_FLAG_SINGLE_CONSUMER/RTE_EVENT_QUEUE_CFG_FLAG_SINGLE_LINK (Jerin)
> to remove the confusion to between another producer and consumer in sw eventdev driver
> 22) Northbound api implementation patch spited to more logical patches(Thomas)
>
> Changes since RFC v2:
>
> - Updated the documentation to define the need for this library[Jerin]
> - Added RTE_EVENT_QUEUE_CFG_*_ONLY configuration parameters in
> struct rte_event_queue_conf to enable optimized sw implementation [Bruce]
> - Introduced RTE_EVENT_OP* ops [Bruce]
> - Added nb_event_queue_flows,nb_event_port_dequeue_depth, nb_event_port_enqueue_depth
> in rte_event_dev_configure() like ethdev and crypto library[Jerin]
> - Removed rte_event_release() and replaced with RTE_EVENT_OP_RELEASE ops to
> reduce fast path APIs and it is redundant too[Jerin]
> - In the view of better application portability, Removed pin_event
> from rte_event_enqueue as it is just hint and Intel/NXP can not support it[Jerin]
> - Added rte_event_port_links_get()[Jerin]
> - Added rte_event_dev_dump[Harry]
>
> Notes:
>
> - This patch set is check-patch clean with an exception that
> 03/06 has one WARNING:MACRO_WITH_FLOW_CONTROL
> - Looking forward to getting additional maintainers for libeventdev
>
> TODO:
> 1) Create user guide
>
> Jerin Jacob (6):
> eventdev: introduce event driven programming model
> eventdev: define southbound driver interface
> eventdev: implement the northbound APIs
> eventdev: implement PMD registration functions
> event/skeleton: add skeleton eventdev driver
> app/test: unit test case for eventdev APIs
>
> MAINTAINERS | 5 +
> app/test/Makefile | 2 +
> app/test/test_eventdev.c | 778 +++++++++++
> config/common_base | 14 +
> doc/api/doxy-api-index.md | 1 +
> doc/api/doxy-api.conf | 1 +
> drivers/Makefile | 1 +
> drivers/event/Makefile | 36 +
> drivers/event/skeleton/Makefile | 55 +
> .../skeleton/rte_pmd_skeleton_event_version.map | 4 +
> drivers/event/skeleton/skeleton_eventdev.c | 518 +++++++
> drivers/event/skeleton/skeleton_eventdev.h | 68 +
> lib/Makefile | 1 +
> lib/librte_eal/common/include/rte_log.h | 1 +
> lib/librte_eventdev/Makefile | 57 +
> lib/librte_eventdev/rte_eventdev.c | 1220 +++++++++++++++++
> lib/librte_eventdev/rte_eventdev.h | 1407 ++++++++++++++++++++
> lib/librte_eventdev/rte_eventdev_pmd.h | 511 +++++++
> lib/librte_eventdev/rte_eventdev_version.map | 39 +
> mk/rte.app.mk | 5 +
> 20 files changed, 4724 insertions(+)
> create mode 100644 app/test/test_eventdev.c
> create mode 100644 drivers/event/Makefile
> create mode 100644 drivers/event/skeleton/Makefile
> create mode 100644 drivers/event/skeleton/rte_pmd_skeleton_event_version.map
> create mode 100644 drivers/event/skeleton/skeleton_eventdev.c
> create mode 100644 drivers/event/skeleton/skeleton_eventdev.h
> create mode 100644 lib/librte_eventdev/Makefile
> create mode 100644 lib/librte_eventdev/rte_eventdev.c
> create mode 100644 lib/librte_eventdev/rte_eventdev.h
> create mode 100644 lib/librte_eventdev/rte_eventdev_pmd.h
> create mode 100644 lib/librte_eventdev/rte_eventdev_version.map
>
^ permalink raw reply
* Re: [PATCH] app/testpmd: fix invalid port ID
From: Wu, Jingjing @ 2016-12-19 1:24 UTC (permalink / raw)
To: Lu, Wenzhuo, dev@dpdk.org; +Cc: Lu, Wenzhuo, Chen, Jing D, stable@dpdk.org
In-Reply-To: <1481613068-92744-1-git-send-email-wenzhuo.lu@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Tuesday, December 13, 2016 3:11 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo <wenzhuo.lu@intel.com>; Chen, Jing D
> <jing.d.chen@intel.com>; stable@dpdk.org
> Subject: [dpdk-dev] [PATCH] app/testpmd: fix invalid port ID
>
> Some CLIs don't check the input port ID, it may cause segmentation fault
> (core dumped).
>
> 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>
> ---
> CC: stable@dpdk.org
Acked-by: Jingjing Wu <jingjing.wu@intel.com>
^ permalink raw reply
* Re: ConnectX4 100GbE - Compilation problem
From: Olga Shern @ 2016-12-18 21:00 UTC (permalink / raw)
To: george.dit@gmail.com; +Cc: dev@dpdk.org
In-Reply-To: <CAN9HtFDbmtCZ1=2EUCG4BqLcSSmaFVZG4DRU7YNnWex4TdECBg@mail.gmail.com>
Hi George,
You are right, this is the expected behavior.
Every new DPDK version that is released supported on top of latest available MLNX_OFED and this is documented in the RN.
For DPDK 16.07 you will need to use MLNX_OFED 3.3
Best Regards,
Olga
From: george.dit@gmail.com [mailto:george.dit@gmail.com]
Sent: Sunday, December 18, 2016 6:06 PM
To: Olga Shern <olgas@mellanox.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] ConnectX4 100GbE - Compilation problem
Hi again,
I have a follow up question. I noticed that when I compile DPDK with CONFIG_RTE_LIBRTE_MLX5_PMD=y, the compilation fate depends upon the OFED version that I have.
To become more clear, with DPDK 16.11 and OFED 3.4-2.0.0.0 it compiles, but DPDK 16.07 and the same OFED fails with:
== Build drivers/net/mlx5
CC mlx5.o
PMDINFO mlx5.o.pmd.c
CC mlx5.o.pmd.o
LD mlx5.o
CC mlx5_rxq.o
CC mlx5_txq.o
CC mlx5_rxtx.o
In file included from /opt/dpdk/drivers/net/mlx5/mlx5.h:41:0,
from /opt/dpdk/drivers/net/mlx5/mlx5_rxtx.c:65:
/opt/dpdk/drivers/net/mlx5/mlx5_rxtx.c: In function ‘mlx5_mpw_new’:
/opt/dpdk/drivers/net/mlx5/mlx5_rxtx.c:911:9: error: ‘MLX5_OPCODE_LSO_MPW’ undeclared (first use in this function)
MLX5_OPCODE_LSO_MPW);
^
/opt/dpdk/drivers/net/mlx5/mlx5_rxtx.c:911:9: note: each undeclared identifier is reported only once for each function it appears in
/opt/dpdk/drivers/net/mlx5/mlx5_rxtx.c: In function ‘mlx5_mpw_inline_new’:
/opt/dpdk/drivers/net/mlx5/mlx5_rxtx.c:1110:13: error: ‘MLX5_OPCODE_LSO_MPW’ undeclared (first use in this function)
MLX5_OPCODE_LSO_MPW);
^
/opt/dpdk/mk/internal/rte.compile-pre.mk:138<http://rte.compile-pre.mk:138>: recipe for target 'mlx5_rxtx.o' failed
make[6]: *** [mlx5_rxtx.o] Error 1
/opt/dpdk/mk/rte.subdir.mk:61<http://rte.subdir.mk:61>: recipe for target 'mlx5' failed
make[5]: *** [mlx5] Error 2
/opt/dpdk/mk/rte.subdir.mk:61<http://rte.subdir.mk:61>: recipe for target 'net' failed
make[4]: *** [net] Error 2
/opt/dpdk/mk/rte.sdkbuild.mk:78<http://rte.sdkbuild.mk:78>: recipe for target 'drivers' failed
make[3]: *** [drivers] Error 2
/opt/dpdk/mk/rte.sdkroot.mk:123<http://rte.sdkroot.mk:123>: recipe for target 'all' failed
make[2]: *** [all] Error 2
/opt/dpdk/mk/rte.sdkinstall.mk:84<http://rte.sdkinstall.mk:84>: recipe for target 'pre_install' failed
make[1]: *** [pre_install] Error 2
/opt/dpdk/mk/rte.sdkroot.mk:98<http://rte.sdkroot.mk:98>: recipe for target 'install' failed
make: *** [install] Error 2
Is there a way to have DPDK compiled with MLX5 support across a variety of DPDK versions (i.e, from 2.2.0 up to 16.11)?
Thanks in advance and best regards,
Georgios
On Sun, Dec 18, 2016 at 8:58 AM, <george.dit@gmail.com<mailto:george.dit@gmail.com>> wrote:
Hi Olga,
That was the issue indeed, thank you very much!
Best regards,
Georgios
On Sat, Dec 17, 2016 at 10:26 PM, Olga Shern <olgas@mellanox.com<mailto:olgas@mellanox.com>> wrote:
Hi Georgios,
Did you install MLNX_OFED?
You probably missing libmlx5-devel package
Best Regards,
Olga
-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org<mailto:dev-bounces@dpdk.org>] On Behalf Of george.dit@gmail.com<mailto:george.dit@gmail.com>
Sent: Friday, December 16, 2016 4:46 PM
To: Georgios Katsikas <george.dit@gmail.com<mailto:george.dit@gmail.com>>; dev@dpdk.org<mailto:dev@dpdk.org>
Subject: Re: [dpdk-dev] ConnectX4 100GbE - Compilation problem
Hi all,
I am coming back to you regarding the Mellanox Connectx4 100Gbps DPDK driver.
We exchanged some e-mails last summer and I managed to compile the DPDK-based Mellanox driver using DPDK 16.07 on top of Ubuntu server 16.04.01.
A few days ago, I installed a fresh Ubuntu server 16.04.1 on my machine and attempted to re-install DPDK.
This time, DPDK does not compile because of the following error:
\== Build drivers/net/mlx5
CC mlx5.o
In file included from /opt/dpdk/drivers/net/mlx5/mlx5.h:67:0,
from /opt/dpdk/drivers/net/mlx5/mlx5.c:66:
/opt/dpdk/drivers/net/mlx5/mlx5_rxtx.h:46:32: fatal error:
infiniband/mlx5_hw.h: No such file or directory compilation terminated.
/opt/dpdk/mk/internal/rte.compile-pre.mk:138<http://rte.compile-pre.mk:138>: recipe for target 'mlx5.o'
failed
make[6]: *** [mlx5.o] Error 1
/opt/dpdk/mk/rte.subdir.mk:61<http://rte.subdir.mk:61>: recipe for target 'mlx5' failed
make[5]: *** [mlx5] Error 2
/opt/dpdk/mk/rte.subdir.mk:61<http://rte.subdir.mk:61>: recipe for target 'net' failed
make[4]: *** [net] Error 2
/opt/dpdk/mk/rte.sdkbuild.mk:78<http://rte.sdkbuild.mk:78>: recipe for target 'drivers' failed
make[3]: *** [drivers] Error 2
/opt/dpdk/mk/rte.sdkroot.mk:126<http://rte.sdkroot.mk:126>: recipe for target 'all' failed
make[2]: *** [all] Error 2
/opt/dpdk/mk/rte.sdkinstall.mk:85<http://rte.sdkinstall.mk:85>: recipe for target 'pre_install' failed
make[1]: *** [pre_install] Error 2
/opt/dpdk/mk/rte.sdkroot.mk:101<http://rte.sdkroot.mk:101>: recipe for target 'install' failed
make: *** [install] Error 2
[ ERROR] [ CheckStatus] Command make install failed
I tried 2 different kernels (4.4 and 4.8) both compiled from sources and I also tried 3 different DPDk versions (16.04/07/11) but they all get stuck to this point.
The way I configure DPDK is via config/common_base, where I set CONFIG_RTE_LIBRTE_MLX5_PMD=y.
The file infiniband/mlx5_hw.h does not exist in my system although I have installed libmlx5.
Do you know why does this happen now?
Thanks in advance and best regards,
Georgios
On Thu, Aug 18, 2016 at 7:35 PM, <george.dit@gmail.com<mailto:george.dit@gmail.com>> wrote:
> Hi Adrien,
>
> Thanks for the prompt reply!
> You are right, I didn't go via the DPDK route, in the hope that
> Mellanox will provide the exact source and configuration.
> DPDK 16.07 from dpdk.org<http://dpdk.org> works like a charm and my NIC is in PMD mode,
> thanks a lot for your guidance!
>
> Best regards,
> Georgios
>
> On Thu, Aug 18, 2016 at 6:05 PM, Adrien Mazarguil <
> adrien.mazarguil@6wind.com<mailto:adrien.mazarguil@6wind.com>> wrote:
>
>> Hi George,
>>
>> On Thu, Aug 18, 2016 at 05:41:38PM +0200, george.dit@gmail.com<mailto:george.dit@gmail.com> wrote:
>> > Hi,
>> >
>> > I have a single port Mellanox ConnectX 4 100GbE NIC and I want to
>> > test
>> its
>> > Rx/Tx capabilites using DPDK.
>> > My system runs a Linux kernel 4.4 compiled from sources.
>> >
>> > I found the PMD driver for this NIC as provided by Mellanox here
>> > <http://www.mellanox.com/page/products_dyn?product_family=20
>> 9&mtag=pmd_for_dpdk>
>> > .
>> > Following this
>> > <http://www.mellanox.com/related-docs/prod_software/MLNX_
>> DPDK_Quick_Start_Guide_v2.2_2.7.pdf>
>> > guideline, I put my NIC in Ethernet mode, configured the 3 options
>> > regarding mlx5 in the config/common_linuxapp file and applied 'make
>> install
>> > T=x86_64-native-linuxapp-gcc'.
>>
>> Please note this is a third party package maintained by Mellanox,
>> therefore this mailing list is not the right place to discuss related
>> errors, unless they can be reproduced with a version downloaded from
>> dpdk.org<http://dpdk.org>.
>>
>> > Then, I stumbled upon a compilation problem in the mlx4 module.
>> > The compiler's output is as follows:
>> >
>> > == Build drivers/net/mlx4
>> > CC mlx4.o
>> > In file included from /usr/include/linux/if.h:31:0,
>> > from /opt/MLNX_DPDK_2.2_2.7/drivers
>> /net/mlx4/mlx4.c:57:
>> > /usr/include/linux/hdlc/ioctl.h:73:14: error: ‘IFNAMSIZ’ undeclared
>> here
>> > (not in a function)
>> > char master[IFNAMSIZ]; /* Name of master FRAD device */
>> > ^
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:612:53: error:
>> > ‘struct ifreq’ declared inside parameter list [-Werror]
>> > priv_ifreq(const struct priv *priv, int req, struct ifreq *ifr)
>> > ^
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:612:53: error: its
>> scope is
>> > only this definition or declaration, which is probably not what you
>> > want [-Werror]
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c: In function
>> ‘priv_ifreq’:
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:619:32: error:
>> dereferencing
>> > pointer to incomplete type ‘struct ifreq’
>> > if (priv_get_ifname(priv, &ifr->ifr_name) == 0)
>> > ^
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c: In function
>> ‘rxq_setup’:
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:3735:29: error:
>> > unused parameter ‘inactive’ [-Werror=unused-parameter]
>> > unsigned int socket, int inactive, const struct rte_eth_rxconf
>> *conf,
>> > ^
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c: In function
>> > ‘mlx4_link_update_unlocked’:
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:4712:15: error:
>> > storage
>> size
>> > of ‘ifr’ isn’t known
>> > struct ifreq ifr;
>> > ^
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:4724:43: error: ‘IFF_UP’
>> > undeclared (first use in this function)
>> > dev_link.link_status = ((ifr.ifr_flags & IFF_UP) &&
>> > ^
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:4724:43: note: each
>> > undeclared identifier is reported only once for each function it
>> appears in
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:4725:22: error:
>> > ‘IFF_RUNNING’ undeclared (first use in this function)
>> > (ifr.ifr_flags & IFF_RUNNING));
>> > ^
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:4712:15: error:
>> > unused variable ‘ifr’ [-Werror=unused-variable]
>> > struct ifreq ifr;
>> > ^
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c: In function
>> > ‘mlx4_dev_get_flow_ctrl’:
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:4880:15: error:
>> > storage
>> size
>> > of ‘ifr’ isn’t known
>> > struct ifreq ifr;
>> > ^
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:4880:15: error:
>> > unused variable ‘ifr’ [-Werror=unused-variable]
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c: In function
>> > ‘mlx4_dev_set_flow_ctrl’:
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:4930:15: error:
>> > storage
>> size
>> > of ‘ifr’ isn’t known
>> > struct ifreq ifr;
>> > ^
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:4930:15: error:
>> > unused variable ‘ifr’ [-Werror=unused-variable]
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c: In function
>> ‘priv_get_mac’:
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:5184:15: error:
>> > storage
>> size
>> > of ‘request’ isn’t known
>> > struct ifreq request;
>> > ^
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:5184:15: error:
>> > unused variable ‘request’ [-Werror=unused-variable]
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c: In function
>> > ‘mlx4_pci_devinit’:
>> > /opt/MLNX_DPDK_2.2_2.7/drivers/net/mlx4/mlx4.c:5725:25: error: ‘IFF_UP’
>> > undeclared (first use in this function)
>> > priv_set_flags(priv, ~IFF_UP, IFF_UP);
>> > ^
>> > cc1: all warnings being treated as errors
>> > /opt/MLNX_DPDK_2.2_2.7/mk/internal/rte.compile-pre.mk:126<http://rte.compile-pre.mk:126>: recipe
>> > for target 'mlx4.o' failed
>> >
>> > Iwould appreciate any suggestions and guidance.
>>
>> Well fortunately these errors are also present in v2.2.0 and should
>> have been addressed since v16.07 by the following commit:
>>
>> http://dpdk.org/browse/dpdk/commit/?id=d06c608c013c36711e7a
>> 693b3fece68a93ae4369
>>
>> You can either upgrade to v16.07, back-port this commit yourself or
>> wait for an update from Mellanox.
>>
>> --
>> Adrien Mazarguil
>> 6WIND
>>
>
>
>
> --
> Georgios Katsikas
> Ph.D. Student and Research Assistant
> Network Systems Lab (NSL)
>
>
>
> *E-Mail:* george <george.katsikas@imdea.org<mailto:george.katsikas@imdea.org>>.dit@gmail.com<mailto:dit@gmail.com>
> *Web Site:* http://www.di.uoa.gr/~katsikas/
> <http://people.networks.imdea.org/~george_katsikas/index.html>
>
--
Georgios Katsikas
Ph.D. Student and Research Assistant
Network Systems Lab (NSL)
*E-Mail:* george <george.katsikas@imdea.org<mailto:george.katsikas@imdea.org>>.dit@gmail.com<mailto:dit@gmail.com>
*Web Site:* http://www.di.uoa.gr/~katsikas/ <http://people.networks.imdea.org/~george_katsikas/index.html>
--
Georgios Katsikas
Ph.D. Student and Research Assistant
Network Systems Lab (NSL)
[http://www.kth.se/polopoly_fs/1.77259!/image/logo-main-2013.png]
E-Mail: george<mailto:george.katsikas@imdea.org>.dit@gmail.com<mailto:dit@gmail.com>
Web Site: http://www.di.uoa.gr/~katsikas/<http://people.networks.imdea.org/~george_katsikas/index.html>
--
Georgios Katsikas
Ph.D. Student and Research Assistant
Network Systems Lab (NSL)
[http://www.kth.se/polopoly_fs/1.77259!/image/logo-main-2013.png]
E-Mail: george<mailto:george.katsikas@imdea.org>.dit@gmail.com<mailto:dit@gmail.com>
Web Site: http://www.di.uoa.gr/~katsikas/<http://people.networks.imdea.org/~george_katsikas/index.html>
^ permalink raw reply
* Re: [PATCH] doc: fix required tools list layout
From: Mcnamara, John @ 2016-12-18 20:50 UTC (permalink / raw)
To: Baruch Siach; +Cc: dev@dpdk.org
In-Reply-To: <20161218191100.nzgn2w7465qnk26v@tarshish>
> -----Original Message-----
> From: Baruch Siach [mailto:baruch@tkos.co.il]
> Sent: Sunday, December 18, 2016 7:11 PM
> To: Mcnamara, John <john.mcnamara@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] doc: fix required tools list layout
>
> Hi John,
>
> On Thu, Dec 15, 2016 at 03:09:32PM +0000, Mcnamara, John wrote:
> > > -----Original Message-----
> > > From: Baruch Siach [mailto:baruch at tkos.co.il]
> > > Sent: Tuesday, December 13, 2016 10:04 AM
> > > To: dev at dpdk.org
> > > Cc: Mcnamara, John <john.mcnamara at intel.com>; David Marchand
> > > <david.marchand at 6wind.com>; Baruch Siach <baruch at tkos.co.il>
> > > Subject: [PATCH] doc: fix required tools list layout
> > >
> > > The Python requirement should appear in the bullet list.
> > >
> > > Signed-off-by: Baruch Siach <baruch at tkos.co.il>
> > > ---
> > > doc/guides/linux_gsg/sys_reqs.rst | 4 +---
> > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > >
> > > diff --git a/doc/guides/linux_gsg/sys_reqs.rst
> > > b/doc/guides/linux_gsg/sys_reqs.rst
> > > index 3d743421595a..621cc9ddaef6 100644
> > > --- a/doc/guides/linux_gsg/sys_reqs.rst
> > > +++ b/doc/guides/linux_gsg/sys_reqs.rst
> > > @@ -84,9 +84,7 @@ Compilation of the DPDK
> > > x86_x32 ABI is currently supported with distribution packages
> > > only on Ubuntu
> > > higher than 13.10 or recent Debian distribution. The only
> > > supported compiler is gcc 4.9+.
> > >
> > > -.. note::
> > > -
> > > - Python, version 2.6 or 2.7, to use various helper scripts
> included in
> > > the DPDK package.
> > > +* Python, version 2.6 or 2.7, to use various helper scripts
> included in
> > > the DPDK package.
> >
> > In addition to this change the note on the previous item should be
> > indented to the level of the bullet item. It is probably worth making
> > that change at the same time.
>
> All items are equally aligned as far as I can see. The 32bit on 64bit
> requirement bullets are sub-items of the previous item. Am I missing
> anything?
Hi Baruch,
The note should be indented to the level of the first level bullet item text rather
than the margin since it is a note on that particular item and not a general note.
Like this:
* Additional packages required for 32-bit compilation on 64-bit systems are:
* glibc.i686, libgcc.i686, libstdc++.i686 and glibc-devel.i686 for Intel i686/x86_64;
* glibc.ppc64, libgcc.ppc64, libstdc++.ppc64 and glibc-devel.ppc64 for IBM ppc_64;
.. note::
x86_x32 ABI is currently supported with distribution packages only on Ubuntu
higher than 13.10 or recent Debian distribution. The only supported compiler is gcc 4.9+.
If you generate the html before and after you will see the difference.
>
> > Also, the Python version should probably say 2.7+ and 3.2+ if this
> > patch is
> > accepted:
> >
> > http://dpdk.org/dev/patchwork/patch/17775/
> >
> > However, since that change hasn't been acked/merged yet you can leave
> > that part of your patch as it is and I'll fix the version numbers in
> > the other patch.
>
> Note that your updated patch[1] conflicts with this one.
>
Yes. :-)
It also conflicts with Thomas' patch to move the directories. I'll rebase based
on whatever order the patches are applied in.
John
^ permalink raw reply
* Re: [PATCH] doc: fix required tools list layout
From: Baruch Siach @ 2016-12-18 19:11 UTC (permalink / raw)
To: Mcnamara, John; +Cc: dev
In-Reply-To: <B27915DBBA3421428155699D51E4CFE202686088@IRSMSX103.ger.corp.intel.com>
Hi John,
On Thu, Dec 15, 2016 at 03:09:32PM +0000, Mcnamara, John wrote:
> > -----Original Message-----
> > From: Baruch Siach [mailto:baruch at tkos.co.il]
> > Sent: Tuesday, December 13, 2016 10:04 AM
> > To: dev at dpdk.org
> > Cc: Mcnamara, John <john.mcnamara at intel.com>; David Marchand
> > <david.marchand at 6wind.com>; Baruch Siach <baruch at tkos.co.il>
> > Subject: [PATCH] doc: fix required tools list layout
> >
> > The Python requirement should appear in the bullet list.
> >
> > Signed-off-by: Baruch Siach <baruch at tkos.co.il>
> > ---
> > doc/guides/linux_gsg/sys_reqs.rst | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/doc/guides/linux_gsg/sys_reqs.rst
> > b/doc/guides/linux_gsg/sys_reqs.rst
> > index 3d743421595a..621cc9ddaef6 100644
> > --- a/doc/guides/linux_gsg/sys_reqs.rst
> > +++ b/doc/guides/linux_gsg/sys_reqs.rst
> > @@ -84,9 +84,7 @@ Compilation of the DPDK
> > x86_x32 ABI is currently supported with distribution packages only on
> > Ubuntu
> > higher than 13.10 or recent Debian distribution. The only supported
> > compiler is gcc 4.9+.
> >
> > -.. note::
> > -
> > - Python, version 2.6 or 2.7, to use various helper scripts included in
> > the DPDK package.
> > +* Python, version 2.6 or 2.7, to use various helper scripts included in
> > the DPDK package.
>
> In addition to this change the note on the previous item should be indented
> to the level of the bullet item. It is probably worth making that change at
> the same time.
All items are equally aligned as far as I can see. The 32bit on 64bit
requirement bullets are sub-items of the previous item. Am I missing anything?
> Also, the Python version should probably say 2.7+ and 3.2+ if this patch is
> accepted:
>
> http://dpdk.org/dev/patchwork/patch/17775/
>
> However, since that change hasn't been acked/merged yet you can leave that
> part of your patch as it is and I'll fix the version numbers in the other
> patch.
Note that your updated patch[1] conflicts with this one.
[1] http://dpdk.org/dev/patchwork/patch/18152/
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
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