Re: [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add target queues in flow actions
HI Boris,
On 12/20/2017 09:49 PM, Boris Pismenny wrote:
Hi,
On Wed, Dec 13, 2017 at 07:14:19PM, Nelio Laranjeiro wrote:
Hi,
On Wed, Dec 13, 2017 at 07:23:19PM +0530, Anoob Joseph wrote:
Hi Nelio,
On 12/13/2017 06:23 PM, Nelio Laranjeiro wrote:
Hi Anoob,
On Wed, Dec 13, 2017 at 05:08:19PM +0530, Anoob Joseph wrote:
Hi Nelio,
On 12/13/2017 03:32 PM, Nelio Laranjeiro wrote:
Hi Anoob,
On Wed, Dec 13, 2017 at 12:11:18PM +0530, Anoob Joseph wrote:
Hi Nelio,
On 12/12/2017 08:08 PM, Nelio Laranjeiro wrote:
Hi Anoob,
On Tue, Dec 12, 2017 at 07:34:31PM +0530, Anoob Joseph wrote:
Hi Nelio,
On 12/12/2017 07:14 PM, Nelio Laranjeiro wrote:
Hi Anoob,
On Tue, Dec 12, 2017 at 06:13:08PM +0530, Anoob Joseph
wrote:
Hi Nelio,
On 12/11/2017 07:34 PM, Nelio Laranjeiro wrote:
Mellanox INNOVA NIC needs to have final target queue
actions to perform inline crypto.
Signed-off-by: Nelio Laranjeiro
---
Changes in v3:
* removed PASSTHRU test for ingress.
* removed check on configured queues for the queue
action.
Changes in v2:
* Test the rule by PASSTHRU/RSS/QUEUE and apply the
first one validated.
---
examples/ipsec-secgw/ipsec.c | 57
++--
examples/ipsec-secgw/ipsec.h | 2 +-
2 files changed, 56 insertions(+), 3
deletions(-)
diff --git a/examples/ipsec-secgw/ipsec.c
b/examples/ipsec-secgw/ipsec.c index
17bd7620d..1b8b251c8 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -142,6 +142,7 @@ create_session(struct ipsec_ctx
*ipsec_ctx, struct ipsec_sa *sa)
rte_eth_dev_get_sec_ctx(
sa-
portid);
const struct rte_security_capability
*sec_cap;
+ int ret = 0;
sa->sec_session =
rte_security_session_create(ctx,
&sess_conf,
ipsec_ctx->session_pool); @@
-201,15 +202,67 @@ create_session(struct ipsec_ctx
*ipsec_ctx, struct ipsec_sa *sa)
sa->action[0].type =
RTE_FLOW_ACTION_TYPE_SECURITY;
sa->action[0].conf = sa->sec_session;
- sa->action[1].type =
RTE_FLOW_ACTION_TYPE_END;
-
sa->attr.egress = (sa->direction ==
RTE_SECURITY_IPSEC_SA_DIR_EGRESS);
sa->attr.ingress = (sa->direction ==
RTE_SECURITY_IPSEC_SA_DIR_INGRESS);
+ if (sa->attr.ingress) {
+ uint8_t rss_key[40];
+ struct rte_eth_rss_conf
rss_conf = {
+ .rss_key = rss_key,
+ .rss_key_len = 40,
+ };
+ struct rte_eth_dev
*eth_dev;
+ union {
+ struct
rte_flow_action_rss rss;
+ struct {
+ const struct
rte_eth_rss_conf *rss_conf;
+ uint16_t num;
+ uint16_t
queue[RTE_MAX_QUEUES_PER_PORT];
+ } local;
+ } action_rss;
+ unsigned int i;
+ unsigned int j;
+
+ sa->action[2].type =
RTE_FLOW_ACTION_TYPE_END;
+ /* Try RSS. */
+ sa->action[1].type =
RTE_FLOW_ACTION_TYPE_RSS;
+ sa->action[1].conf =
&action_rss;
+ eth_dev = ctx->device;
+
rte_eth_dev_rss_hash_conf_get(sa->portid,
+
&rss_conf);
+ for (i = 0, j = 0;
+i < eth_dev->data-
nb_rx_queues; ++i)
+ if (eth_dev->data-
rx_queues[i])
+
action_rss.local.queue[j++] = i;
+ action_rss.local.num = j;
+ action_rss.local.rss_conf =
&rss_conf;
+ ret = rte_flow_validate(sa-
portid, &sa->attr,
+ sa-
pattern, sa->action,
+ &err);
+ if (!ret)
+ goto flow_create;
+ /* Try Queue. */
+ sa->action[1].type =
RTE_FLOW_ACTION_TYPE_QUEUE;
+ sa->action[1].conf =
+ &(struct
rte_flow_action_queue){
+ .index = 0,
+ };
+ ret = rte_flow_validate(sa-
portid, &sa->attr,
+
Re: [dpdk-dev] [PATCH 00/11] net/vhostpci: A new vhostpci PMD supporting VM2VM scenario
On 12/21/2017 07:26 AM, Yang, Zhiyong wrote: -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yang, Zhiyong Sent: Thursday, December 21, 2017 2:21 PM To: Tan, Jianfeng ; Maxime Coquelin ; dev@dpdk.org; y...@fridaylinux.org Cc: Wang, Wei W Subject: Re: [dpdk-dev] [PATCH 00/11] net/vhostpci: A new vhostpci PMD supporting VM2VM scenario Hi Jianfeng, -Original Message- From: Tan, Jianfeng Sent: Thursday, December 21, 2017 1:52 PM To: Yang, Zhiyong ; Maxime Coquelin ; dev@dpdk.org; y...@fridaylinux.org Cc: Wang, Wei W Subject: RE: [PATCH 00/11] net/vhostpci: A new vhostpci PMD supporting VM2VM scenario Hi, -Original Message- From: Yang, Zhiyong Sent: Wednesday, December 20, 2017 9:52 AM To: Maxime Coquelin; dev@dpdk.org; y...@fridaylinux.org Cc: Wang, Wei W; Tan, Jianfeng Subject: RE: [PATCH 00/11] net/vhostpci: A new vhostpci PMD supporting VM2VM scenario Hi Maxime, -Original Message- From: Maxime Coquelin [mailto:maxime.coque...@redhat.com] Sent: Tuesday, December 19, 2017 7:15 PM To: Yang, Zhiyong ; dev@dpdk.org; y...@fridaylinux.org Cc: Wang, Wei W ; Tan, Jianfeng Subject: Re: [PATCH 00/11] net/vhostpci: A new vhostpci PMD supporting VM2VM scenario Thanks for the RFC. It seems there is a lot of code duplication between this series and libvhost- user. Does the non-RFC would make reuse of libvhost-user? I'm thinking of all the code copied from virtio-net.c for example. If not, I think this is problematic as it will double the maintenance cost. Thank you for paying attention to the patchset . TX/RX logic basically comes from vhost user code. but some function interfaces and data structures are different, So can not reuse them directly, code duplicate should be removed, I'm aware of this point too, when I was writing the vhostpci PMD. But We should modify the libvhost-user firstly, let libvhostuser become more generic. It looks like that more and more PMDs are becoming the member of virtio family or are on the road. Trying to draw a conclusion here, there are two kinds of code duplication in net/vhost-pci. - For pci operations in guest driver, it has some duplicated code with virtio-net pmd. - For the enqueue/dequeuer operations, it has some duplicated code with vhost- user lib. Right? Right. If the existing code in DPDK can become more generic, we can avoid the duplication. BTW, wonder why vhost user enqueue/dequeue are put in lib layer,not in driver/net/vhost like virtio PMD? Because Vhost PMD is not its only user, it exports an API that can be used directly by the application (e.g. ovs-dpdk). Regards, Maxime Thanks Zhiyong Thanks, Jianfeng Cheers, Maxime
Re: [dpdk-dev] [PATCH 00/11] net/vhostpci: A new vhostpci PMD supporting VM2VM scenario
> -Original Message- > From: Maxime Coquelin [mailto:maxime.coque...@redhat.com] > Sent: Thursday, December 21, 2017 4:26 PM > To: Yang, Zhiyong ; Tan, Jianfeng > ; dev@dpdk.org; y...@fridaylinux.org > Cc: Wang, Wei W > Subject: Re: [PATCH 00/11] net/vhostpci: A new vhostpci PMD supporting > VM2VM scenario > > > > On 12/21/2017 07:26 AM, Yang, Zhiyong wrote: > > > > > >> -Original Message- > >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yang, Zhiyong > >> Sent: Thursday, December 21, 2017 2:21 PM > >> To: Tan, Jianfeng ; Maxime Coquelin > >> ; dev@dpdk.org; y...@fridaylinux.org > >> Cc: Wang, Wei W > >> Subject: Re: [dpdk-dev] [PATCH 00/11] net/vhostpci: A new vhostpci > >> PMD supporting VM2VM scenario > >> > >> Hi Jianfeng, > >> > >>> -Original Message- > >>> From: Tan, Jianfeng > >>> Sent: Thursday, December 21, 2017 1:52 PM > >>> To: Yang, Zhiyong ; Maxime Coquelin > >>> ; dev@dpdk.org; y...@fridaylinux.org > >>> Cc: Wang, Wei W > >>> Subject: RE: [PATCH 00/11] net/vhostpci: A new vhostpci PMD > >>> supporting VM2VM scenario > >>> > >>> Hi, > >>> > -Original Message- > From: Yang, Zhiyong > Sent: Wednesday, December 20, 2017 9:52 AM > To: Maxime Coquelin; dev@dpdk.org; y...@fridaylinux.org > Cc: Wang, Wei W; Tan, Jianfeng > Subject: RE: [PATCH 00/11] net/vhostpci: A new vhostpci PMD > supporting VM2VM scenario > > Hi Maxime, > > > -Original Message- > > From: Maxime Coquelin [mailto:maxime.coque...@redhat.com] > > Sent: Tuesday, December 19, 2017 7:15 PM > > To: Yang, Zhiyong ; dev@dpdk.org; > > y...@fridaylinux.org > > Cc: Wang, Wei W ; Tan, Jianfeng > > > > Subject: Re: [PATCH 00/11] net/vhostpci: A new vhostpci PMD > > supporting VM2VM scenario > > > > > > > Thanks for the RFC. > > It seems there is a lot of code duplication between this series > > and > > libvhost- > user. > > > > Does the non-RFC would make reuse of libvhost-user? I'm thinking > > of all > the > > code copied from virtio-net.c for example. > > > > If not, I think this is problematic as it will double the maintenance > > cost. > > Thank you for paying attention to the patchset . TX/RX logic > basically comes from vhost user code. > but some function interfaces and data structures are different, So > can not reuse them directly, code duplicate should be removed, I'm > aware of this point too, when I was writing the vhostpci PMD. > But We should modify the libvhost-user firstly, let > libvhostuser become more generic. > It looks like that more and more PMDs are becoming the member of > virtio family or are on the road. > >>> > >>> Trying to draw a conclusion here, there are two kinds of code > >>> duplication in net/vhost-pci. > >>> - For pci operations in guest driver, it has some duplicated code > >>> with virtio-net pmd. > >>> - For the enqueue/dequeuer operations, it has some duplicated code > >>> with vhost- user lib. > >>> > >>> Right? > >> > >> Right. If the existing code in DPDK can become more generic, we can > >> avoid the duplication. > >> > > > > BTW, wonder why vhost user enqueue/dequeue are put in lib layer,not in > driver/net/vhost like virtio PMD? > > Because Vhost PMD is not its only user, it exports an API that can be used > directly by the application (e.g. ovs-dpdk). > Thanks for your detailed clarification. Maxime. Zhiyong > Regards, > Maxime >
Re: [dpdk-dev] [RFC 1/5] version: 17.11.0
Hi Qi, > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qi Zhang > Sent: Wednesday, December 20, 2017 9:35 PM > To: adrien.mazarg...@6wind.com > Cc: dev@dpdk.org; Doherty, Declan ; Thomas > Monjalon > Subject: [dpdk-dev] [RFC 1/5] version: 17.11.0 > > From: Thomas Monjalon > > Signed-off-by: Thomas Monjalon > --- > lib/librte_eal/common/include/rte_version.h | 4 ++-- > pkg/dpdk.spec | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) Your patchset should not change these files. Regards, Pablo
Re: [dpdk-dev] [RFC 1/5] version: 17.11.0
Sorry, there is some mistake Please ignore, I will resend everything as v2 Regards Qi > -Original Message- > From: De Lara Guarch, Pablo > Sent: Thursday, December 21, 2017 5:07 PM > To: Zhang, Qi Z ; adrien.mazarg...@6wind.com > Cc: dev@dpdk.org; Doherty, Declan ; Thomas > Monjalon > Subject: RE: [dpdk-dev] [RFC 1/5] version: 17.11.0 > > Hi Qi, > > > -Original Message- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qi Zhang > > Sent: Wednesday, December 20, 2017 9:35 PM > > To: adrien.mazarg...@6wind.com > > Cc: dev@dpdk.org; Doherty, Declan ; Thomas > > Monjalon > > Subject: [dpdk-dev] [RFC 1/5] version: 17.11.0 > > > > From: Thomas Monjalon > > > > Signed-off-by: Thomas Monjalon > > --- > > lib/librte_eal/common/include/rte_version.h | 4 ++-- > > pkg/dpdk.spec | 2 +- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > Your patchset should not change these files. > > Regards, > Pablo
[dpdk-dev] [PATCH] reset src fd field to -1 in fdset_move of vhost
In the fdset_move, after copying the fd&rwfds from the src to the dst, the fd
should be set to -1. Or else in some cases, there will be a fault missing. E.g:
Before: 1 -1 3 4 -1 6 7 -1 9 10
After: 1 10 3 4 9 6 7 -1 9 10
Then the index7 will be returned correctly for the first time, but if another
fd is to be added, it will fail.
Signed-off-by: Bing Zhao
---
lib/librte_vhost/fd_man.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_vhost/fd_man.c b/lib/librte_vhost/fd_man.c
index 4c6fed418..48594dd7f 100644
--- a/lib/librte_vhost/fd_man.c
+++ b/lib/librte_vhost/fd_man.c
@@ -63,6 +63,7 @@ fdset_move(struct fdset *pfdset, int dst, int src)
{
pfdset->fd[dst]= pfdset->fd[src];
pfdset->rwfds[dst] = pfdset->rwfds[src];
+ pfdset->fd[src].fd = -1;
}
static void
--
2.11.0.windows.1
[dpdk-dev] [RFC v2 0/5] rte_flow extension for vSwitch acceleration
This patch extend rte_flow API. The purpose is to provide comfortable programming interface for virtual switch software (such as OVS) to take advantage of incoming device's vSwitch acceleration capability when using DPDK as data plane. Below is summary of changes: 1. Support to specify flow's destination as an ethdev interface. Add action RTE_FLOW_ACTION_TYPE_ETHDEV_PORT, use port_id as the identification of the destitation. A typical use case is, with a smart NIC used for vSwitch acceleration, flow is defined to redirect packet between switch port that is managed by a Port Representor. See patch for Port Representor: http://dpdk.org/dev/patchwork/patch/31458/ 2. Enhanced flow statistics query. Enhanced action RTE_FLOW_ACTION_COUNT by adding last hit timestamp tracking which is the requirement from OVS. 3. Add flow timeout support as the requirement from OVS Application is able to a) Setup the time duration of a flow, the flow is expected to be deleted automatically when timeout. b) Ping a flow to check if it is active or not. c) Register a callback function when a flow is deleted due to timeout. 4. Add protocol headers which will be supported by incoming device. New protocal headers include IPV4 ARP, IPV6 ICMP , IPV6 extent header. 5. Add packet modification actions which will be supported by incoming device. Add new actions that be used to modify packet content with generic semantic: RTE_FLOW_ACTION_TYPE_FIELD_UPDATE: update specific field of packet RTE_FLWO_ACTION_TYPE_FIELD_INCREMENT: increament specific field of packet RTE_FLWO_ACTION_TYPE_FIELD_DECREMENT: decreament specific field of packet RTE_FLWO_ACTION_TYPE_FIELD_COPY: copy data from one field to another in packet. All action use struct rte_flow_item parameter to match the pattern that going to be modified, if no pattern match, the action just be skipped. These action are non-terminating action. they will not impact the fate of the packets, since pattern match is expected to be performed before packet be modified. Note: The RFC patch is based on v17.11. Testpmd command line support is not included. v2: - v1 is incompelete due to some misoperation. Qi Zhang (5): ether: add flow action to redirect packet in a switch domain ether: add flow last hit query support ether: Add flow timeout support ether: add more protocol support in rte_flow ether: add packet modification aciton in rte_flow doc/guides/prog_guide/rte_flow.rst | 148 ++ lib/librte_ether/rte_flow.c| 38 + lib/librte_ether/rte_flow.h| 305 - lib/librte_ether/rte_flow_driver.h | 12 ++ 4 files changed, 502 insertions(+), 1 deletion(-) -- 2.7.4
[dpdk-dev] [RFC v2 2/5] ether: add flow last hit query support
Enhanced the action RTE_FLOW_TYPE_ACTION_COUNT, number of milliseconds since
last hit can be queried.
Signed-off-by: Qi Zhang
---
lib/librte_ether/rte_flow.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 91706e2..8e902f0 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -1052,9 +1052,11 @@ struct rte_flow_query_count {
uint32_t reset:1; /**< Reset counters after query [in]. */
uint32_t hits_set:1; /**< hits field is set [out]. */
uint32_t bytes_set:1; /**< bytes field is set [out]. */
+ uint32_t last_hit_set:1; /**< last_hit field is set [out]. */
uint32_t reserved:29; /**< Reserved, must be zero [in, out]. */
uint64_t hits; /**< Number of hits for this rule [out]. */
uint64_t bytes; /**< Number of bytes through this rule [out]. */
+ uint64_t last_hit; /**< Number of milliseconds since last hit [out]. */
};
/**
--
2.7.4
[dpdk-dev] [RFC v2 4/5] ether: add more protocol support in rte_flow
Add new protocol header match support as below
RTE_FLOW_ITEM_TYPE_ARP - match IPv4 ARP header.
RTE_FLOW_ITEM_TYPE_EXT_HDR_ANY - match any IPv6 extension header.
RTE_FLOW_ITEM_TYPE_ICMPV6 - match IPv6 ICMP header.
RTE_FLOW_ITEM_TYPE_ICMPV6_TGT_ADDR - match IPv6 ICMP Target address
RTE_FLOW_ITEM_TYPE_ICMPV6_SSL - match IPv6 ICMP Source Link-layer address
RTE_FLOW_ITEM_TYPE_ICMPV6_TTL - match IPv6 ICMP Target Link-layer address
Signed-off-by: Qi Zhang
---
lib/librte_ether/rte_flow.h | 156
1 file changed, 156 insertions(+)
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index e09e07f..4ee2b62 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -348,6 +348,49 @@ enum rte_flow_item_type {
* See struct rte_flow_item_esp.
*/
RTE_FLOW_ITEM_TYPE_ESP,
+
+ /**
+* Matches ARP IPv4 header.
+*
+* See struct rte_flow_item_arp.
+*/
+ RTE_FLOW_ITEM_TYPE_ARP,
+
+ /**
+* Matches any IPv6 Extension header.
+*
+* See struct rte_flow_item_ipv6_ext_any.
+*/
+ RTE_FLOW_ITEM_TYPE_IPV6_EXT_HDR_ANY,
+
+ /**
+* Matches ICMPv6 header.
+*
+* See struct rte_flow_item_icmpv6
+*/
+ RTE_FLOW_ITEM_TYPE_ICMPV6,
+
+ /**
+* Match ICMPv6 target address.
+*
+* See struct rte_flow_item_icmpv6_tgt_addr.
+*/
+ RTE_FLOW_ITEM_TYPE_ICMPV6_TGT_ADDR,
+
+ /**
+* Match ICMPv6 Source Link-Layer Address.
+*
+* See struct rte_flow_item_icmpv6_sll.
+*/
+ RTE_FLOW_ITEM_TYPE_ICMPV6_SLL,
+
+ /**
+* Match ICMPv6 Source Link-Layer Address.
+*
+* See struct rte_flow_item_icmpv6_tll.
+*/
+ RTE_FLOW_ITEM_TYPE_ICMPV6_TLL,
+
};
/**
@@ -817,6 +860,119 @@ static const struct rte_flow_item_esp
rte_flow_item_esp_mask = {
#endif
/**
+ * RTE_FLOW_ITEM_TYPE_ARP
+ *
+ * Matches IPv4 ARP packet header
+ */
+struct rte_flow_item_arp {
+struct arp_hdr hdr;
+};
+
+/** Default mask for RTE_FLOW_ITEM_TYPE_ARP. */
+#ifndef __cplusplus
+static const struct rte_flow_item_arp rte_flow_item_arp_mask = {
+ .hdr = {
+ .arp_data = {
+ .arp_sha = {
+ .addr_bytes = "\xff\xff\xff\xff\xff\xff",
+ },
+ .arp_sip = RTE_BE32(0x),
+ .arp_tha = {
+ .addr_bytes = "\xff\xff\xff\xff\xff\xff",
+ },
+ .arp_tip = RTE_BE32(0x),
+ },
+ },
+};
+#endif
+
+/**
+ * RTE_FLOW_ITEM_TYPE_IPV6_EXT_HDR_ANY
+ *
+ * Matches any IPv6 extension header.
+ */
+struct rte_flow_item_ipv6_ext_hdr_any {
+ uint8_t next_hdr;
+};
+
+/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6_EXT_HDR_ANY. */
+#ifndef __cplusplus
+static const struct rte_flow_item_ipv6_ext_hdr_any
rte_flow_item_ipv6_ext_any_mask = {
+ .next_hdr = 0xff,
+};
+#endif
+
+/**
+ * RTE_FLOW_ITEM_TYPE_ICMPV6
+ *
+ * Matches ICMPv6 header.
+ */
+struct rte_flow_item_icmpv6 {
+ uint8_t type;
+ uint8_t code;
+ uint16_t checksum;
+};
+
+/** Default mask for RTE_FLOW_ITEM_TYPE_ICMPV6 */
+#ifndef __cplusplus
+static const struct rte_flow_item_icmpv6 rte_flow_item_icmpv6_mask = {
+ .type = 0xff,
+ .code = 0xff,
+ .checksum = RTE_BE16(0x),
+};
+#endif
+
+/**
+ * RTE_FLOW_ITEM_TYPE_ICMPV6_TGT_ADDR
+ *
+ * Matches ICMPv6's Target Address.
+ */
+struct rte_flow_item_icmpv6_tgt_addr {
+ uint8_t addr[16];
+};
+
+/** Default mask for RTE_FLOW_ITEM_TYPE_ICMPV6_TGT_ADDR */
+#ifndef __cplusplus
+static const struct rte_flow_item_icmpv6_tgt_addr
rte_flow_item_icmpv6_tgt_addr_mask = {
+ .addr = "\xff\xff\xff\xff",
+};
+#endif
+
+/**
+ * RTE_FLOW_ITEM_TYPE_ICPMV6_SLL.
+ *
+ * Matches ICMPv6 Source Link-Layer address.
+ */
+struct rte_flow_item_icmpv6_sll {
+ struct ether_addr addr;
+};
+/** Default mask for RTE_FLOW_ITEM_TYPE_ICMPV6_SLL */
+#ifndef __cplusplus
+static const struct rte_flow_item_icmpv6_sll rte_flow_item_icmpv6_sll_mask = {
+ .addr = {
+ .addr_bytes = "\xff\xff\xff\xff\xff\xff",
+ }
+};
+#endif
+
+/**
+ * RTE_FLOW_ITEM_TYPE_ICMPV6_TLL.
+ *
+ * Matches ICMPv6 Target Link-Layer address.
+ */
+struct rte_flow_item_icmpv6_tll {
+ struct ether_addr addr;
+};
+/** Default mask for RTE_FLOW_ITEM_TYPE_ICMPV6_TLL */
+#ifndef __cplusplus
+static const struct rte_flow_item_icmpv6_tll rte_flow_item_icmpv6_tll_mask = {
+ .addr = {
+ .addr_bytes = "\xff\xff\xff\xff\xff\xff",
+ }
+};
+#endif
+
+/**
* Matching pattern item definition.
*
* A pattern is formed by stacking items starting from the lowest protocol
--
2.7.4
[dpdk-dev] [RFC v2 3/5] ether: Add flow timeout support
Add new APIs to support flow timeout, application is able to
1. Setup the time duration of a flow, the flow is expected to be deleted
automatically when timeout.
2. Ping a flow to check if it is active or not.
3. Register a callback function when a flow is deleted due to timeout.
Signed-off-by: Qi Zhang
---
doc/guides/prog_guide/rte_flow.rst | 37
lib/librte_ether/rte_flow.c| 38 +
lib/librte_ether/rte_flow.h| 49 ++
lib/librte_ether/rte_flow_driver.h | 12 ++
4 files changed, 136 insertions(+)
diff --git a/doc/guides/prog_guide/rte_flow.rst
b/doc/guides/prog_guide/rte_flow.rst
index dcea2f6..1a242fc 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -181,6 +181,14 @@ directions. At least one direction must be specified.
Specifying both directions at once for a given rule is not recommended but
may be valid in a few cases (e.g. shared counters).
+Attribute: Timeout
+^^
+
+Two kinds of timeout can be assigned to a flow rule. For "hard timeout", flow
+rule will be deleted when specific time duration passed since it's creation.
+For "idle timeout", flow rule will be deleted when no packet hit in the given
+time duration.
+
Pattern item
@@ -1695,6 +1703,35 @@ definition.
void *data,
struct rte_flow_error *error);
+Is Active
+~
+
+Check if a flow is still active or not.
+
+It is possible a flow is be deleted automatically due to timeout, this function
+help to check if a flow is still exist.
+
+.. code-block:: c
+
+ int
+ rte_flow_is_active(uint8_t port_id,
+ struct rte_flow *flow,
+ uint8_t *active,
+ struct rte_flow_error* error);
+
+Auto Delete Callback Set
+
+
+Register a callback function when flow is automatically deleted due to timeout.
+
+.. code-block:: c
+
+ int
+ rte_flow_auto_delete_callback_set(uint8_t port_id,
+ struct rte_flow *flow,
+ void (*callback)(struct rte_flow *),
+ struct rte_flow_error *error);
+
Arguments:
- ``port_id``: port identifier of Ethernet device.
diff --git a/lib/librte_ether/rte_flow.c b/lib/librte_ether/rte_flow.c
index 6659063..650c5a5 100644
--- a/lib/librte_ether/rte_flow.c
+++ b/lib/librte_ether/rte_flow.c
@@ -425,3 +425,41 @@ rte_flow_copy(struct rte_flow_desc *desc, size_t len,
}
return 0;
}
+
+/** Check if a flow is stiall active or not. */
+int
+rte_flow_is_active(uint8_t port_id,
+ struct rte_flow* flow,
+ uint8_t *active,
+ struct rte_flow_error* error)
+{
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+ const struct rte_flow_ops *ops = rte_flow_ops_get(port_id, error);
+
+ if (unlikely(!ops))
+ return -rte_errno;
+ if (likely(!!ops->is_active))
+ return ops->is_active(dev, flow, active, error);
+ return -rte_flow_error_set(error, ENOSYS,
+ RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+ NULL, rte_strerror(ENOSYS));
+}
+
+/** Register a callback function when flow is automatically deleted. */
+int
+rte_flow_auto_delete_callback_set(uint8_t port_id,
+ struct rte_flow* flow,
+ void (*callback)(struct rte_flow *),
+ struct rte_flow_error* error)
+{
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+ const struct rte_flow_ops *ops = rte_flow_ops_get(port_id, error);
+
+ if (unlikely(!ops))
+ return -rte_errno;
+ if (likely(!!ops->auto_delete_callback_set))
+ return ops->auto_delete_callback_set(dev, flow, callback,
error);
+ return -rte_flow_error_set(error, ENOSYS,
+ RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+ NULL, rte_strerror(ENOSYS));
+}
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 8e902f0..e09e07f 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -97,6 +97,10 @@ struct rte_flow_attr {
uint32_t ingress:1; /**< Rule applies to ingress traffic. */
uint32_t egress:1; /**< Rule applies to egress traffic. */
uint32_t reserved:30; /**< Reserved, must be zero. */
+ uint32_t hard_timeout;
+ /**< If !0, flow will be deleted after given number of seconds. */
+ uint32_t idle_timeout;
+ /**< If !0, flow will be deleted if no packet hit in given seconds. */
};
/**
@@ -1491,6 +1495,51 @@ rte_flow_copy(struct rte_flow_desc *fd, size_t len,
const struct rte_flow_item *items,
const struct rte_flow_a
[dpdk-dev] [RFC v2 1/5] ether: add flow action to redirect packet in a switch domain
Add action RTE_FLOW_ACTION_TYPE_SWITCH_PORT, it can be used to redirect
a packet to a network interface that connect to the same switch domain,
rte_ethdev's port_id is used as an identification of the destination.
A typical use case is: with a smart NIC for vSwitch acceleration, flow
is defined to forward packets between the switch port that is managed by
Port Representor.
Signed-off-by: Qi Zhang
---
doc/guides/prog_guide/rte_flow.rst | 22 ++
lib/librte_ether/rte_flow.h| 19 ++-
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst
b/doc/guides/prog_guide/rte_flow.rst
index d158be5..dcea2f6 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1474,6 +1474,28 @@ fields in the pattern items.
| 1 | END |
+---+--+
+Action: ``PORT``
+
+
+Redirect packets to an interface that connect to the same switch domain.
+
+The desitnation should be managed by a rte_ethdev instance, port_id is
+the identification of the destination. A typical use case is to define
+a flow that redirect packet to a interface that mananged by a Port
+Representor.
+
+- Terminating by default.
+
+.. _table_rte_flow_action_port:
+
+.. table:: PORT
+
+ +--+---+
+ | Field| Value |
+ +==+===+
+ | ``port_id`` | identification of the destination |
+ +--+---+
+
Negative types
~~
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 47c88ea..91706e2 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -1008,7 +1008,14 @@ enum rte_flow_action_type {
*
* See struct rte_flow_action_security.
*/
- RTE_FLOW_ACTION_TYPE_SECURITY
+ RTE_FLOW_ACTION_TYPE_SECURITY,
+
+ /**
+* Redirect packets to a network interface in the same switch domain.
+*
+* See struct rte_flow_action_port.
+*/
+ RTE_FLOW_ACTION_TYPE_PORT,
};
/**
@@ -1146,6 +1153,16 @@ struct rte_flow_action_security {
void *security_session; /**< Pointer to security session structure. */
};
+/** RTE_FLOW_ACTION_TYPE_PORT
+ *
+ * Redirect packets to a network interface in the same switch domain.
+ *
+ * Terminateing by default.
+ */
+struct rte_flow_action_port {
+ uint16_t port_id; /**< identification of the forward destination. */
+};
+
/**
* Definition of a single action.
*
--
2.7.4
[dpdk-dev] [RFC v2 5/5] ether: add packet modification aciton in rte_flow
Add new actions that be used to modify packet content with generic semantic: RTE_FLOW_ACTION_TYPE_FIELD_UPDATE: update specific field of packet RTE_FLWO_ACTION_TYPE_FIELD_INCREMENT: increament specific field of packet RTE_FLWO_ACTION_TYPE_FIELD_DECREMENT: decreament specific field of packet RTE_FLWO_ACTION_TYPE_FIELD_COPY: copy data from one field to another in packet. All action use struct rte_flow_item parameter to match the pattern that going to be modified, if no pattern match, the action just be skipped. These action are non-terminating action. they will not impact the fate of the packets. Signed-off-by: Qi Zhang --- doc/guides/prog_guide/rte_flow.rst | 89 ++ lib/librte_ether/rte_flow.h| 79 + 2 files changed, 168 insertions(+) diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst index 1a242fc..b706a78 100644 --- a/doc/guides/prog_guide/rte_flow.rst +++ b/doc/guides/prog_guide/rte_flow.rst @@ -1504,6 +1504,95 @@ Representor. | ``port_id`` | identification of the destination | +--+---+ +Action: ``FILED_UPDATE`` +^^^ + +Update specific field of the packet. + +- Non-terminating by default. + +.. _table_rte_flow_action_field_update: + +.. table:: FIELD_UPDATE + + +---+-+ + | Field | Value | + +===+=+ + | ``item`` | item->type: specify the pattern to modify | + | | item->spec: specify the new value to update | + | | item->mask: specify which part of the pattern to update | + | | item->last: ignored | + +---+-+ + | ``layer`` | 0 means outermost matched pattern, | + | | 1 means next-to-outermost and so on ... | + +---+-+ + +Action: ``FILED_INCREMENT`` +^^^ + +Increment 1 on specific field of the packet. + +- Non-terminating by default. + +.. _table_rte_flow_action_field_increment: + +.. table:: FIELD_INCREMENT + + +---+-+ + | Field | Value | + +===+=+ + | ``item`` | item->type: specify the pattern to modify | + | | item->spec: ignored | + | | item->mask: specify which part of the pattern to update | + | | item->last: ignored | + +---+-+ + | ``layer`` | 0 means outermost matched pattern, | + | | 1 means next-to-outermost and so on ... | + +---+-+ + +Action: ``FIELD_DECREMENT`` +^^^ + +Decrement 1 on specific field of the packet. + +Paramenter is same is FIELD_INCREMENT. + +-Non-terminating by default. + +ACTION: ``FIELD_COPY`` +^^ + +Copy data of one field to another of the packet. + +-Non-terminating by default. + +.. _table_rte_flow_action_field_increment: + +.. table:: FIELD_COPY + + +-+-+ + | Field | Value | + +=+=+ + | ``src_item``| src_item->type: match the pattern that data will be copy from | + | | src_item->spec: ignored | + | | src_item->mask: specify which part of the pattern to copy | + | | src_item->last: ignored | + +-+-+ + | ``src_layer`` | layer of src_item | + | | 0 means outermost matched pattern, | + | | 1 means next-to-outermost and so on ... | + +-+-+ + | ``dst_item``| dst_item->type: match the pattern that data will be copy to | + | | dst_item->spec: ignored | + | | dst_item->mask: specify which part of the patter
Re: [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add target queues in flow actions
Hi Anoob,
On 12/21/2017 10:06 AM, Anoob Joseph wrote:
HI Boris,
On 12/20/2017 09:49 PM, Boris Pismenny wrote:
Hi,
On Wed, Dec 13, 2017 at 07:14:19PM, Nelio Laranjeiro wrote:
Hi,
On Wed, Dec 13, 2017 at 07:23:19PM +0530, Anoob Joseph wrote:
Hi Nelio,
On 12/13/2017 06:23 PM, Nelio Laranjeiro wrote:
Hi Anoob,
On Wed, Dec 13, 2017 at 05:08:19PM +0530, Anoob Joseph wrote:
Hi Nelio,
On 12/13/2017 03:32 PM, Nelio Laranjeiro wrote:
Hi Anoob,
On Wed, Dec 13, 2017 at 12:11:18PM +0530, Anoob Joseph wrote:
Hi Nelio,
On 12/12/2017 08:08 PM, Nelio Laranjeiro wrote:
Hi Anoob,
On Tue, Dec 12, 2017 at 07:34:31PM +0530, Anoob Joseph wrote:
Hi Nelio,
On 12/12/2017 07:14 PM, Nelio Laranjeiro wrote:
Hi Anoob,
On Tue, Dec 12, 2017 at 06:13:08PM +0530, Anoob Joseph
wrote:
Hi Nelio,
On 12/11/2017 07:34 PM, Nelio Laranjeiro wrote:
Mellanox INNOVA NIC needs to have final target queue
actions to perform inline crypto.
Signed-off-by: Nelio Laranjeiro
---
Changes in v3:
* removed PASSTHRU test for ingress.
* removed check on configured queues for the queue
action.
Changes in v2:
* Test the rule by PASSTHRU/RSS/QUEUE and apply the
first one validated.
---
examples/ipsec-secgw/ipsec.c | 57
++--
examples/ipsec-secgw/ipsec.h | 2 +-
2 files changed, 56 insertions(+), 3
deletions(-)
diff --git a/examples/ipsec-secgw/ipsec.c
b/examples/ipsec-secgw/ipsec.c index
17bd7620d..1b8b251c8 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -142,6 +142,7 @@ create_session(struct ipsec_ctx
*ipsec_ctx, struct ipsec_sa *sa)
rte_eth_dev_get_sec_ctx(
sa-
portid);
const struct rte_security_capability
*sec_cap;
+ int ret = 0;
sa->sec_session =
rte_security_session_create(ctx,
&sess_conf,
ipsec_ctx->session_pool); @@
-201,15 +202,67 @@ create_session(struct ipsec_ctx
*ipsec_ctx, struct ipsec_sa *sa)
sa->action[0].type =
RTE_FLOW_ACTION_TYPE_SECURITY;
sa->action[0].conf = sa->sec_session;
- sa->action[1].type =
RTE_FLOW_ACTION_TYPE_END;
-
sa->attr.egress = (sa->direction ==
RTE_SECURITY_IPSEC_SA_DIR_EGRESS);
sa->attr.ingress = (sa->direction ==
RTE_SECURITY_IPSEC_SA_DIR_INGRESS);
+ if (sa->attr.ingress) {
+ uint8_t rss_key[40];
+ struct rte_eth_rss_conf
rss_conf = {
+ .rss_key = rss_key,
+ .rss_key_len = 40,
+ };
+ struct rte_eth_dev
*eth_dev;
+ union {
+ struct
rte_flow_action_rss rss;
+ struct {
+ const struct
rte_eth_rss_conf *rss_conf;
+ uint16_t num;
+ uint16_t
queue[RTE_MAX_QUEUES_PER_PORT];
+ } local;
+ } action_rss;
+ unsigned int i;
+ unsigned int j;
+
+ sa->action[2].type =
RTE_FLOW_ACTION_TYPE_END;
+ /* Try RSS. */
+ sa->action[1].type =
RTE_FLOW_ACTION_TYPE_RSS;
+ sa->action[1].conf =
&action_rss;
+ eth_dev = ctx->device;
+
rte_eth_dev_rss_hash_conf_get(sa->portid,
+
&rss_conf);
+ for (i = 0, j = 0;
+ i < eth_dev->data-
nb_rx_queues; ++i)
+ if (eth_dev->data-
rx_queues[i])
+
action_rss.local.queue[j++] = i;
+ action_rss.local.num = j;
+ action_rss.local.rss_conf =
&rss_conf;
+ ret = rte_flow_validate(sa-
portid, &sa->attr,
+ sa-
pattern, sa->action,
+ &err);
+ if (!ret)
+ goto flow_create;
+ /* Try Queue. */
+ sa->action[1].type =
RTE_FLOW_ACTION_TYPE_QUEUE;
+ sa->action[1].conf =
+ &(struct
rte_flow_action_queue){
+ .index = 0,
+ };
+ ret = rte_flow_validate(sa-
portid, &sa->attr,
+ sa-
pattern, sa->action,
+ &err);
+ if (ret)
+ goto
flow_create_failure;
+ } else {
+ sa->action[1].type =
+
RTE_FLOW_ACTION_TYPE_PASSTHRU;
+ sa->action[2].type =
RTE_FLOW_ACTION_TYPE_END;
We would need flow validate here also. And, for
egress, the application will be able to set metadata
(set_pkt_metadata API) per packet. So flow may not be
required for such cases. But if the flow create fails,
the session create would also fail. It might be better if we
check whether the PMD would need metadata (part of the sec_cap-
ol_flags).
Seems what you are describing is outside of this scope
which is only related to correctly implement the generic
flow API with terminal actions.
Since SECURITY+PASSTHRU won't be terminal, this code
segment might be misleading.
Well, I don't mind adding an extra verification even if the
create should fail if the validate fails, as there is no
other option it is just like adding another if statement
considering the validate() cannot guarantee the flow will
be created(), other
[dpdk-dev] [PATCH 2/2] test/test: add return value to mark unit tests as skipped
Add in a TEST_SKIPPED return value for unit tests to mark the tests
as skipped, rather than just failed. Use this new skipped return value for
the crypto tests which can only run if they have a particular driver.
Signed-off-by: Bruce Richardson
---
test/test/test.c | 14 --
test/test/test.h | 5 +++--
test/test/test_cryptodev.c | 28 ++--
3 files changed, 21 insertions(+), 26 deletions(-)
diff --git a/test/test/test.c b/test/test/test.c
index bc273db07..49a61ce05 100644
--- a/test/test/test.c
+++ b/test/test/test.c
@@ -152,17 +152,11 @@ main(int argc, char **argv)
return -1;
}
- /* check the last unit test suite return, and error out if
-* it failed - this causes Meson to pick up the failure.
-*/
- if (last_test_result) {
- cmdline_stdin_exit(cl);
- exit(-1);
- }
-
- } else {
- cmdline_interact(cl);
+ cmdline_stdin_exit(cl);
+ return last_test_result;
}
+ /* if no DPDK_TEST env variable, go interactive */
+ cmdline_interact(cl);
cmdline_stdin_exit(cl);
#endif
diff --git a/test/test/test.h b/test/test/test.h
index 2e9018437..df5eea088 100644
--- a/test/test/test.h
+++ b/test/test/test.h
@@ -40,8 +40,9 @@
#include
#include
-#define TEST_SUCCESS (0)
-#define TEST_FAILED (-1)
+#define TEST_SUCCESS EXIT_SUCCESS
+#define TEST_FAILED -1
+#define TEST_SKIPPED 77
/* Before including test.h file you can define
* TEST_TRACE_FAILURE(_file, _line, _func) macro to better trace/debug test
diff --git a/test/test/test_cryptodev.c b/test/test/test_cryptodev.c
index 1bed65dad..54e6a9e36 100644
--- a/test/test/test_cryptodev.c
+++ b/test/test/test_cryptodev.c
@@ -9591,7 +9591,7 @@ test_cryptodev_qat(void /*argv __rte_unused, int argc
__rte_unused*/)
RTE_LOG(ERR, USER1, "QAT PMD must be loaded. Check if "
"CONFIG_RTE_LIBRTE_PMD_QAT is enabled "
"in config file to run this testsuite.\n");
- return TEST_FAILED;
+ return TEST_SKIPPED;
}
return unit_test_suite_runner(&cryptodev_qat_testsuite);
@@ -9607,7 +9607,7 @@ test_cryptodev_aesni_mb(void /*argv __rte_unused, int
argc __rte_unused*/)
RTE_LOG(ERR, USER1, "AESNI MB PMD must be loaded. Check if "
"CONFIG_RTE_LIBRTE_PMD_AESNI_MB is enabled "
"in config file to run this testsuite.\n");
- return TEST_FAILED;
+ return TEST_SKIPPED;
}
return unit_test_suite_runner(&cryptodev_aesni_mb_testsuite);
@@ -9623,7 +9623,7 @@ test_cryptodev_openssl(void)
RTE_LOG(ERR, USER1, "OPENSSL PMD must be loaded. Check if "
"CONFIG_RTE_LIBRTE_PMD_OPENSSL is enabled "
"in config file to run this testsuite.\n");
- return TEST_FAILED;
+ return TEST_SKIPPED;
}
return unit_test_suite_runner(&cryptodev_openssl_testsuite);
@@ -9639,7 +9639,7 @@ test_cryptodev_aesni_gcm(void)
RTE_LOG(ERR, USER1, "AESNI GCM PMD must be loaded. Check if "
"CONFIG_RTE_LIBRTE_PMD_AESNI_GCM is enabled "
"in config file to run this testsuite.\n");
- return TEST_FAILED;
+ return TEST_SKIPPED;
}
return unit_test_suite_runner(&cryptodev_aesni_gcm_testsuite);
@@ -9655,7 +9655,7 @@ test_cryptodev_null(void)
RTE_LOG(ERR, USER1, "NULL PMD must be loaded. Check if "
"CONFIG_RTE_LIBRTE_PMD_NULL is enabled "
"in config file to run this testsuite.\n");
- return TEST_FAILED;
+ return TEST_SKIPPED;
}
return unit_test_suite_runner(&cryptodev_null_testsuite);
@@ -9671,7 +9671,7 @@ test_cryptodev_sw_snow3g(void /*argv __rte_unused, int
argc __rte_unused*/)
RTE_LOG(ERR, USER1, "SNOW3G PMD must be loaded. Check if "
"CONFIG_RTE_LIBRTE_PMD_SNOW3G is enabled "
"in config file to run this testsuite.\n");
- return TEST_FAILED;
+ return TEST_SKIPPED;
}
return unit_test_suite_runner(&cryptodev_sw_snow3g_testsuite);
@@ -9687,7 +9687,7 @@ test_cryptodev_sw_kasumi(void /*argv __rte_unused, int
argc __rte_unused*/)
RTE_LOG(ERR, USER1, "ZUC PMD must be loaded. Check if "
"CONFIG_RTE_LIBRTE_PMD_KASUMI is enabled "
"in config file to run this testsuite.\n");
- return TEST_FAILED;
+ return TEST_SKIPPED;
[dpdk-dev] [PATCH 1/2] test/test: fix missed failures when running meson test
When using meson test, and/or the DPDK_TEST environment variable for
running specific tests, the return value from the test binary was the value
returned from the unit test runner function. However, not all tests use
that unit test runner infrastructure - some are regular functions, and so
the failure of those tests would not be recognised.
Fix this by setting the last_test_result value inside the command-line
function that calls the individual test fns and that prints the "Test OK"
or "Test Failure" messages.
Fixes: d79a9657a78c ("meson: add tests app to build")
Signed-off-by: Bruce Richardson
---
test/test/commands.c | 1 +
test/test/test.c | 2 +-
test/test/test.h | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/test/test/commands.c b/test/test/commands.c
index 4097a3310..6649cfc32 100644
--- a/test/test/commands.c
+++ b/test/test/commands.c
@@ -103,6 +103,7 @@ static void cmd_autotest_parsed(void *parsed_result,
ret = t->callback();
}
+ last_test_result = ret;
if (ret == 0)
printf("Test OK\n");
else
diff --git a/test/test/test.c b/test/test/test.c
index fb4d4753e..bc273db07 100644
--- a/test/test/test.c
+++ b/test/test/test.c
@@ -102,7 +102,7 @@ do_recursive_call(void)
return -1;
}
-static int last_test_result;
+int last_test_result;
int
main(int argc, char **argv)
diff --git a/test/test/test.h b/test/test/test.h
index 08ffe949c..2e9018437 100644
--- a/test/test/test.h
+++ b/test/test/test.h
@@ -218,6 +218,7 @@ struct unit_test_suite {
};
int unit_test_suite_runner(struct unit_test_suite *suite);
+extern int last_test_result;
#define RECURSIVE_ENV_VAR "RTE_TEST_RECURSIVE"
--
2.14.3
[dpdk-dev] [PATCH 0/2] improve meson test support
Being able to call "meson test" to run unit tests is very handy, but the support is still in the early days. These two patches improve things by fixing a bug in error reporting and then allowing a test to report as skipped if a particular lib/driver/piece of HW is missing. Bruce Richardson (2): test/test: fix missed failures when running meson test test/test: add return value to mark unit tests as skipped test/test/commands.c | 1 + test/test/test.c | 16 +--- test/test/test.h | 6 -- test/test/test_cryptodev.c | 28 ++-- 4 files changed, 24 insertions(+), 27 deletions(-) -- 2.14.3
[dpdk-dev] [PATCH v2] net/tap: allow user mac to be passed as args
Added fixes for user TAP user MAC
1) user format to RTE_PMD_REGISTER_PARAM_STRING
2) TAP to the RTE_LOG in absence of dynamic RTE_LOG
3) Boundary case for MAC string added
---
Other Details:
1) not to extract "string to mac" conversion to its own function
2) set_mac_type does not take any pmd or device name
3) Segault for boundary cases 'mac="01:01:01:01:01:01', not found
4) Added user MAC format string
Signed-off-by: Vipin Varghese
---
drivers/net/tap/rte_eth_tap.c | 80 ++-
1 file changed, 41 insertions(+), 39 deletions(-)
diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
index 0c53458..85c12af 100644
--- a/drivers/net/tap/rte_eth_tap.c
+++ b/drivers/net/tap/rte_eth_tap.c
@@ -81,6 +81,11 @@
#define FLOWER_KERNEL_VERSION KERNEL_VERSION(4, 2, 0)
#define FLOWER_VLAN_KERNEL_VERSION KERNEL_VERSION(4, 9, 0)
+#define MAC_STRING_NULL (0)
+#define MAC_STRING_FIXED (1)
+#define MAC_STRING_USER (2)
+#define ETH_TAP_USER_MAC_FMT ("xx:xx:xx:xx:xx:xx")
+
static unsigned char user_mac[ETHER_ADDR_LEN];
static struct rte_vdev_driver pmd_tap_drv;
@@ -1293,17 +1298,18 @@ enum ioctl_mode {
pmd->txq[i].fd = -1;
}
- if (fixed_mac_type == 1) {
+ if (fixed_mac_type == MAC_STRING_FIXED) {
/* fixed mac = 00:64:74:61:70: */
static int iface_idx;
char mac[ETHER_ADDR_LEN] = "\0dtap";
mac[ETHER_ADDR_LEN - 1] = iface_idx++;
rte_memcpy(&pmd->eth_addr, mac, ETHER_ADDR_LEN);
- } else if (fixed_mac_type == 2) {
- /* user mac is recieved */
+ } else if (fixed_mac_type == MAC_STRING_USER) {
+ /* user mac is received */
RTE_LOG(INFO, PMD,
- "Using user MAC (%02x:%02x:%02x:%02x:%02x:%02x)\n",
+ "%s; Using user MAC (%02x:%02x:%02x:%02x:%02x:%02x)
argument\n",
+ pmd->name,
user_mac[0], user_mac[1], user_mac[2],
user_mac[3], user_mac[4], user_mac[5]);
rte_memcpy(&pmd->eth_addr, user_mac, ETHER_ADDR_LEN);
@@ -1476,53 +1482,49 @@ enum ioctl_mode {
}
static int
-set_mac_type(const char *key __rte_unused,
-const char *value,
-void *extra_args)
+set_mac_type(const char *key __rte_unused, const char *value, void *extra_args)
{
- char macTemp[20], *macByte = NULL;
+ char mac_temp[20] = {0}, *mac_byte = NULL;
unsigned int index = 0;
if (value) {
+ RTE_LOG(DEBUG, PMD, "TAP user MAC (%s) to set.\n", value);
+
if (!strncasecmp(ETH_TAP_MAC_FIXED, value,
strlen(ETH_TAP_MAC_FIXED))) {
- *(int *)extra_args = 1;
+ *(int *)extra_args = MAC_STRING_FIXED;
} else {
- RTE_LOG(INFO, PMD, "User shared MAC param (%s)\n",
- value);
-
/* desired format aa:bb:cc:dd:ee:ff:11 */
if (strlen(value) == 17) {
- strncpy(macTemp, value, 18);
-
- macByte = strtok(macTemp, ":");
- while ((macByte != NULL) &&
- (strspn(macByte,
"0123456789ABCDEFabcdef")) &&
- (strspn((macByte + 1),
"0123456789ABCDEFabcdef")) &&
- (strlen(macByte) == 2)) {
- user_mac[index] = strtoul(macByte,
NULL, 16);
- macByte = strtok(NULL, ":");
+ strncpy(mac_temp, value, 18);
+ mac_temp[19] = "\0";
+ mac_byte = strtok(mac_temp, ":");
+
+ while ((mac_byte != NULL) &&
+ (strspn(mac_byte,
"0123456789ABCDEFabcdef")) &&
+ (strspn((mac_byte + 1),
"0123456789ABCDEFabcdef")) &&
+ (strlen(mac_byte) == 2)) {
+ user_mac[index] = strtoul(mac_byte,
NULL, 16);
+ mac_byte = strtok(NULL, ":");
index += 1;
}
- if (index != 6) {
- RTE_LOG(ERR, PMD, " failure in MAC
value (%s) at %u\n",
- macByte, index + 1);
- return -1;
- }
+ if (index != 6)
+ goto error;
- RTE_LOG(DEBUG, PMD, " User MAC
Re: [dpdk-dev] [PATCH 2/2] test/test: add return value to mark unit tests as skipped
On Thu, Dec 21, 2017 at 10:15:10AM +, Bruce Richardson wrote: > Add in a TEST_SKIPPED return value for unit tests to mark the tests > as skipped, rather than just failed. Use this new skipped return value for > the crypto tests which can only run if they have a particular driver. > > Signed-off-by: Bruce Richardson +Declan and Pablo as maintainers of crypto code. /Bruce
Re: [dpdk-dev] [PATCH 1/2] test/test: fix missed failures when running meson test
> From: Richardson, Bruce
> Sent: Thursday, December 21, 2017 10:15 AM
> To: dev@dpdk.org
> Cc: Van Haaren, Harry ; Richardson, Bruce
>
> Subject: [PATCH 1/2] test/test: fix missed failures when running meson test
>
> When using meson test, and/or the DPDK_TEST environment variable for
> running specific tests, the return value from the test binary was the value
> returned from the unit test runner function. However, not all tests use
> that unit test runner infrastructure - some are regular functions, and so
> the failure of those tests would not be recognised.
>
> Fix this by setting the last_test_result value inside the command-line
> function that calls the individual test fns and that prints the "Test OK"
> or "Test Failure" messages.
>
> Fixes: d79a9657a78c ("meson: add tests app to build")
>
> Signed-off-by: Bruce Richardson
Reviewed-by: Harry van Haaren
Re: [dpdk-dev] [PATCH 2/2] test/test: add return value to mark unit tests as skipped
> From: Richardson, Bruce > Sent: Thursday, December 21, 2017 10:23 AM > To: dev@dpdk.org; Doherty, Declan ; De Lara > Guarch, Pablo > Cc: Van Haaren, Harry > Subject: Re: [PATCH 2/2] test/test: add return value to mark unit tests as > skipped > > On Thu, Dec 21, 2017 at 10:15:10AM +, Bruce Richardson wrote: > > Add in a TEST_SKIPPED return value for unit tests to mark the tests > > as skipped, rather than just failed. Use this new skipped return value for > > the crypto tests which can only run if they have a particular driver. > > > > Signed-off-by: Bruce Richardson > > +Declan and Pablo as maintainers of crypto code. Looks good to me, checked unit tests using old build system and binary, but 2nd Ack from crypto maintainers welcome :) Acked-by: Harry van Haaren
[dpdk-dev] [PATCH v3] net/ixgbe: removed ipsec keys from private data
All ipsec related setting are being held in the driver
private data to allow easy add and remove of SAs. There
is no need to keep a record of the keys, and also
storing the keys can be a security issue.
Signed-off-by: Radu Nicolau
Acked-by: Declan Doherty
---
v2: updated commit msg
v3: removed key local copy
drivers/net/ixgbe/ixgbe_ipsec.c | 52 +++--
drivers/net/ixgbe/ixgbe_ipsec.h | 4
2 files changed, 19 insertions(+), 37 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ipsec.c b/drivers/net/ixgbe/ixgbe_ipsec.c
index 105da11..91254de 100644
--- a/drivers/net/ixgbe/ixgbe_ipsec.c
+++ b/drivers/net/ixgbe/ixgbe_ipsec.c
@@ -70,6 +70,8 @@ static void
ixgbe_crypto_clear_ipsec_tables(struct rte_eth_dev *dev)
{
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ struct ixgbe_ipsec *priv = IXGBE_DEV_PRIVATE_TO_IPSEC(
+ dev->data->dev_private);
int i = 0;
/* clear Rx IP table*/
@@ -106,6 +108,10 @@ ixgbe_crypto_clear_ipsec_tables(struct rte_eth_dev *dev)
IXGBE_WRITE_REG(hw, IXGBE_IPSTXSALT, 0);
IXGBE_WAIT_TWRITE;
}
+
+ memset(priv->rx_ip_tbl, 0, sizeof(priv->rx_ip_tbl));
+ memset(priv->rx_sa_tbl, 0, sizeof(priv->rx_sa_tbl));
+ memset(priv->tx_sa_tbl, 0, sizeof(priv->tx_sa_tbl));
}
static int
@@ -173,16 +179,6 @@ ixgbe_crypto_add_sa(struct ixgbe_crypto_session
*ic_session)
priv->rx_sa_tbl[sa_index].spi =
rte_cpu_to_be_32(ic_session->spi);
priv->rx_sa_tbl[sa_index].ip_index = ip_index;
- priv->rx_sa_tbl[sa_index].key[3] =
- rte_cpu_to_be_32(*(uint32_t *)&ic_session->key[0]);
- priv->rx_sa_tbl[sa_index].key[2] =
- rte_cpu_to_be_32(*(uint32_t *)&ic_session->key[4]);
- priv->rx_sa_tbl[sa_index].key[1] =
- rte_cpu_to_be_32(*(uint32_t *)&ic_session->key[8]);
- priv->rx_sa_tbl[sa_index].key[0] =
- rte_cpu_to_be_32(*(uint32_t *)&ic_session->key[12]);
- priv->rx_sa_tbl[sa_index].salt =
- rte_cpu_to_be_32(ic_session->salt);
priv->rx_sa_tbl[sa_index].mode = IPSRXMOD_VALID;
if (ic_session->op == IXGBE_OP_AUTHENTICATED_DECRYPTION)
priv->rx_sa_tbl[sa_index].mode |=
@@ -225,15 +221,15 @@ ixgbe_crypto_add_sa(struct ixgbe_crypto_session
*ic_session)
reg_val = IPSRXIDX_RX_EN | IPSRXIDX_WRITE |
IPSRXIDX_TABLE_KEY | (sa_index << 3);
IXGBE_WRITE_REG(hw, IXGBE_IPSRXKEY(0),
- priv->rx_sa_tbl[sa_index].key[0]);
+ rte_cpu_to_be_32(*(uint32_t *)&ic_session->key[12]));
IXGBE_WRITE_REG(hw, IXGBE_IPSRXKEY(1),
- priv->rx_sa_tbl[sa_index].key[1]);
+ rte_cpu_to_be_32(*(uint32_t *)&ic_session->key[8]));
IXGBE_WRITE_REG(hw, IXGBE_IPSRXKEY(2),
- priv->rx_sa_tbl[sa_index].key[2]);
+ rte_cpu_to_be_32(*(uint32_t *)&ic_session->key[4]));
IXGBE_WRITE_REG(hw, IXGBE_IPSRXKEY(3),
- priv->rx_sa_tbl[sa_index].key[3]);
+ rte_cpu_to_be_32(*(uint32_t *)&ic_session->key[0]));
IXGBE_WRITE_REG(hw, IXGBE_IPSRXSALT,
- priv->rx_sa_tbl[sa_index].salt);
+ rte_cpu_to_be_32(ic_session->salt));
IXGBE_WRITE_REG(hw, IXGBE_IPSRXMOD,
priv->rx_sa_tbl[sa_index].mode);
IXGBE_WAIT_RWRITE;
@@ -257,32 +253,22 @@ ixgbe_crypto_add_sa(struct ixgbe_crypto_session
*ic_session)
priv->tx_sa_tbl[sa_index].spi =
rte_cpu_to_be_32(ic_session->spi);
- priv->tx_sa_tbl[sa_index].key[3] =
- rte_cpu_to_be_32(*(uint32_t *)&ic_session->key[0]);
- priv->tx_sa_tbl[sa_index].key[2] =
- rte_cpu_to_be_32(*(uint32_t *)&ic_session->key[4]);
- priv->tx_sa_tbl[sa_index].key[1] =
- rte_cpu_to_be_32(*(uint32_t *)&ic_session->key[8]);
- priv->tx_sa_tbl[sa_index].key[0] =
- rte_cpu_to_be_32(*(uint32_t *)&ic_session->key[12]);
- priv->tx_sa_tbl[sa_index].salt =
- rte_cpu_to_be_32(ic_session->salt);
+ priv->tx_sa_tbl[i].used = 1;
+ ic_session->sa_index = sa_index;
+ /* write Key table entry*/
reg_val = IPSRXIDX_RX_EN | IPSRXIDX_WRITE | (sa_index << 3);
IXGBE_WRITE_REG(hw, IXGBE_IPSTXKEY(0),
- priv->tx_sa_tbl[sa_index].key[0]);
+ rte_cpu_t
[dpdk-dev] [PATCH v1] [net/tap] add logic to assign speed from user
TAP speed is passed as user argument, but never set to interface.
New logic brings speed get and set to LOCAL and REMOTE interfaces.
Updated the default PMD speeed to 10M as per Linux Kernel default
value.
Signed-off-by: Vipin Varghese
---
drivers/net/tap/rte_eth_tap.c | 185 +-
1 file changed, 182 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
index 6b27679..7238504 100644
--- a/drivers/net/tap/rte_eth_tap.c
+++ b/drivers/net/tap/rte_eth_tap.c
@@ -62,6 +62,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -96,7 +98,7 @@
static volatile uint32_t tap_trigger; /* Rx trigger */
static struct rte_eth_link pmd_link = {
- .link_speed = ETH_SPEED_NUM_10G,
+ .link_speed = ETH_SPEED_NUM_10M,
.link_duplex = ETH_LINK_FULL_DUPLEX,
.link_status = ETH_LINK_DOWN,
.link_autoneg = ETH_LINK_SPEED_AUTONEG
@@ -1229,6 +1231,178 @@ enum ioctl_mode {
};
static int
+tap_speed_set(struct pmd_internals *pmd, const char *iface_name,
+enum ioctl_mode mode, uint32_t speed)
+{
+ int err;
+ struct ifreq ifr;
+ struct ethtool_cmd edataCmd = {0};
+#ifdef ETHTOOL_SLINKSETTINGS
+ struct ethtool_link_settings edataLink = {0};
+#endif
+
+ if ((pmd == NULL) || (iface_name == NULL) ||
+ (speed == ETH_SPEED_NUM_NONE))
+ return -1;
+
+ RTE_LOG(DEBUG, PMD,
+ "SET speed %u for %s iface_name %s\n",
+ speed,
+ (mode == REMOTE_ONLY)?"REMOTE":"LOCAL",
+ iface_name);
+
+ switch (speed) {
+ case (ETH_SPEED_NUM_10M):
+ case (ETH_SPEED_NUM_100M):
+ case (ETH_SPEED_NUM_1G):
+ case (ETH_SPEED_NUM_2_5G):
+ case (ETH_SPEED_NUM_5G):
+ case (ETH_SPEED_NUM_10G):
+ case (ETH_SPEED_NUM_20G):
+ case (ETH_SPEED_NUM_25G):
+ case (ETH_SPEED_NUM_40G):
+ case (ETH_SPEED_NUM_50G):
+ case (ETH_SPEED_NUM_56G):
+ case (ETH_SPEED_NUM_100G):
+ break;
+
+ default:
+ RTE_LOG(ERR, PMD,
+ "Unsupported SET speed %u for %s iface_name %s.\n",
+ speed,
+ (mode == REMOTE_ONLY)?"REMOTE":"LOCAL",
+ iface_name);
+
+ return -2;
+ }
+
+#ifdef ETHTOOL_SLINKSETTINGS
+ edataLink.speed = speed;
+ edataLink.cmd = ETHTOOL_SLINKSETTINGS;
+ ifr.ifr_data = (caddr_t)&edataLink;
+
+ err = tap_ioctl(pmd, SIOCETHTOOL, &ifr, 0,
+ (mode == REMOTE_ONLY)?REMOTE_ONLY:LOCAL_ONLY);
+ if (err == 0)
+ return speed;
+#endif
+
+ edataCmd.speed = speed;
+ edataCmd.cmd = ETHTOOL_SSET;
+ ifr.ifr_data = (caddr_t)&edataCmd;
+
+ err = tap_ioctl(pmd, SIOCETHTOOL, &ifr, 0,
+ (mode == REMOTE_ONLY)?REMOTE_ONLY:LOCAL_ONLY);
+
+ if (err == 0)
+ return speed;
+
+ RTE_LOG(ERR, PMD,
+ "Failed to SET speed %u for %s iface_name %s.\n",
+ speed, (mode == REMOTE_ONLY)?"REMOTE":"LOCAL", iface_name);
+
+ return -2;
+}
+
+static int
+tap_speed_get(struct pmd_internals *pmd, const char *iface_name,
+enum ioctl_mode mode)
+{
+ int err;
+ struct ifreq ifr;
+ struct ethtool_cmd edataCmd = {0};
+#ifdef ETHTOOL_GLINKSETTINGS
+ struct ethtool_link_settings edataLink = {0};
+#endif
+
+ if ((pmd == NULL) || (iface_name == NULL))
+ return -1;
+
+ RTE_LOG(DEBUG, PMD,
+ "Retrive speed for %s iface_name %s.\n",
+ (mode == REMOTE_ONLY)?"REMOTE":"LOCAL", iface_name);
+
+#ifdef ETHTOOL_GLINKSETTINGS
+ edataLink.speed = 0;
+ edataLink.cmd = ETHTOOL_GLINKSETTINGS;
+ ifr.ifr_data = (caddr_t)&edataLink;
+
+ err = tap_ioctl(pmd, SIOCETHTOOL, &ifr, 0,
+ (mode == REMOTE_ONLY)?REMOTE_ONLY:LOCAL_ONLY);
+
+ if ((err == 0) && (edataLink.speed))
+ return edataLink.speed;
+#endif
+
+ edataCmd.speed = 0;
+ edataCmd.cmd = ETHTOOL_GSET;
+ ifr.ifr_data = (caddr_t)&edataCmd;
+
+ err = tap_ioctl(pmd, SIOCETHTOOL, &ifr, 0,
+ (mode == REMOTE_ONLY)?REMOTE_ONLY:LOCAL_ONLY);
+ if ((err == 0) && (edataCmd.speed))
+ return edataCmd.speed;
+
+ RTE_LOG(ERR, PMD,
+ "Failed to retrive speed for %s iface_name %s.\n",
+ (mode == REMOTE_ONLY)?"REMOTE":"LOCAL", iface_name);
+
+ return -2;
+}
+
+static int
+eth_dev_tap_config_speed(struct pmd_internals *pmd)
+{
+ int err = 0, remoteSpeed = 0, localSpeed = 0;
+
+ err = tap_speed_get(pmd,
+ pmd->name, LOCAL_ONLY);
+ if (err <= ETH_SPEED_NUM_NONE)
+ return err;
+ localSpeed = err;
+
+ RTE_LOG(DEBUG, PMD,
+ "Local interface %s speed got %d desired %u\n",
+ pmd->name
[dpdk-dev] [PATCH 2/2] test: add skip instead of fail, update crypto test
This commit adds a SKIPPED return value from the unit tests, indicating that the test was not able to run (eg: PMD was not enabled when DPDK was compiled). The cryptodev tests are updated to return SKIPPED instead of failing if the PMD is not enabled, allowing any test infrastructure to identify that the test was not able to run. Signed-off-by: Harry van Haaren Signed-off-by: Bruce Richardson --- Note that this patch is the combination of multiple patches that were developed on the dpdk-next-build tree, however the changes target code for mainline DPDK. As such, the relevant parts of the following commits were merged into this single patch that targets mainline: - 32529 test: use env variable to run test if set - 32555 test/test: fix missed failures when running meson test - 32556 test/test: add return value to mark unit tests as skipped --- test/test/test.h | 5 +++-- test/test/test_cryptodev.c | 28 ++-- 2 files changed, 17 insertions(+), 16 deletions(-) diff --git a/test/test/test.h b/test/test/test.h index 2e90184..df5eea0 100644 --- a/test/test/test.h +++ b/test/test/test.h @@ -40,8 +40,9 @@ #include #include -#define TEST_SUCCESS (0) -#define TEST_FAILED (-1) +#define TEST_SUCCESS EXIT_SUCCESS +#define TEST_FAILED -1 +#define TEST_SKIPPED 77 /* Before including test.h file you can define * TEST_TRACE_FAILURE(_file, _line, _func) macro to better trace/debug test diff --git a/test/test/test_cryptodev.c b/test/test/test_cryptodev.c index 1bed65d..54e6a9e 100644 --- a/test/test/test_cryptodev.c +++ b/test/test/test_cryptodev.c @@ -9591,7 +9591,7 @@ test_cryptodev_qat(void /*argv __rte_unused, int argc __rte_unused*/) RTE_LOG(ERR, USER1, "QAT PMD must be loaded. Check if " "CONFIG_RTE_LIBRTE_PMD_QAT is enabled " "in config file to run this testsuite.\n"); - return TEST_FAILED; + return TEST_SKIPPED; } return unit_test_suite_runner(&cryptodev_qat_testsuite); @@ -9607,7 +9607,7 @@ test_cryptodev_aesni_mb(void /*argv __rte_unused, int argc __rte_unused*/) RTE_LOG(ERR, USER1, "AESNI MB PMD must be loaded. Check if " "CONFIG_RTE_LIBRTE_PMD_AESNI_MB is enabled " "in config file to run this testsuite.\n"); - return TEST_FAILED; + return TEST_SKIPPED; } return unit_test_suite_runner(&cryptodev_aesni_mb_testsuite); @@ -9623,7 +9623,7 @@ test_cryptodev_openssl(void) RTE_LOG(ERR, USER1, "OPENSSL PMD must be loaded. Check if " "CONFIG_RTE_LIBRTE_PMD_OPENSSL is enabled " "in config file to run this testsuite.\n"); - return TEST_FAILED; + return TEST_SKIPPED; } return unit_test_suite_runner(&cryptodev_openssl_testsuite); @@ -9639,7 +9639,7 @@ test_cryptodev_aesni_gcm(void) RTE_LOG(ERR, USER1, "AESNI GCM PMD must be loaded. Check if " "CONFIG_RTE_LIBRTE_PMD_AESNI_GCM is enabled " "in config file to run this testsuite.\n"); - return TEST_FAILED; + return TEST_SKIPPED; } return unit_test_suite_runner(&cryptodev_aesni_gcm_testsuite); @@ -9655,7 +9655,7 @@ test_cryptodev_null(void) RTE_LOG(ERR, USER1, "NULL PMD must be loaded. Check if " "CONFIG_RTE_LIBRTE_PMD_NULL is enabled " "in config file to run this testsuite.\n"); - return TEST_FAILED; + return TEST_SKIPPED; } return unit_test_suite_runner(&cryptodev_null_testsuite); @@ -9671,7 +9671,7 @@ test_cryptodev_sw_snow3g(void /*argv __rte_unused, int argc __rte_unused*/) RTE_LOG(ERR, USER1, "SNOW3G PMD must be loaded. Check if " "CONFIG_RTE_LIBRTE_PMD_SNOW3G is enabled " "in config file to run this testsuite.\n"); - return TEST_FAILED; + return TEST_SKIPPED; } return unit_test_suite_runner(&cryptodev_sw_snow3g_testsuite); @@ -9687,7 +9687,7 @@ test_cryptodev_sw_kasumi(void /*argv __rte_unused, int argc __rte_unused*/) RTE_LOG(ERR, USER1, "ZUC PMD must be loaded. Check if " "CONFIG_RTE_LIBRTE_PMD_KASUMI is enabled " "in config file to run this testsuite.\n"); - return TEST_FAILED; + return TEST_SKIPPED; } return unit_test_suite_runner(&cryptodev_sw_kasumi_testsuite); @@ -9703,7 +9703,7 @@ test_cryptodev_sw_zuc(void /*argv __rte_unused, int argc __rte_unused*/) RTE_LOG(ERR, USER1, "ZUC PMD must be loaded. Check if "
[dpdk-dev] [PATCH 1/2] test: use env variable to run tests
With this patch the test binary checks the DPDK_TEST
environment variable and if set, the contents of the var
are inserted on the test app command line, and run.
Signed-off-by: Bruce Richardson
Signed-off-by: Harry van Haaren
---
Note that this patch is the combination of multiple patches
that were developed on the dpdk-next-build tree, however the
changes target code for mainline DPDK.
As such, the relevant parts of the following commits were
merged into this single patch that targets mainline:
- 32529 test: use env variable to run test if set
- 32555 test/test: fix missed failures when running meson test
- 32556 test/test: add return value to mark unit tests as skipped
---
test/test/commands.c | 1 +
test/test/test.c | 18 ++
test/test/test.h | 1 +
3 files changed, 20 insertions(+)
diff --git a/test/test/commands.c b/test/test/commands.c
index 4097a33..6649cfc 100644
--- a/test/test/commands.c
+++ b/test/test/commands.c
@@ -103,6 +103,7 @@ static void cmd_autotest_parsed(void *parsed_result,
ret = t->callback();
}
+ last_test_result = ret;
if (ret == 0)
printf("Test OK\n");
else
diff --git a/test/test/test.c b/test/test/test.c
index 0e6ff7c..49a61ce 100644
--- a/test/test/test.c
+++ b/test/test/test.c
@@ -102,6 +102,8 @@ do_recursive_call(void)
return -1;
}
+int last_test_result;
+
int
main(int argc, char **argv)
{
@@ -140,6 +142,20 @@ main(int argc, char **argv)
if (cl == NULL) {
return -1;
}
+
+ char *dpdk_test = getenv("DPDK_TEST");
+ if (dpdk_test && strlen(dpdk_test)) {
+ char buf[1024];
+ snprintf(buf, sizeof(buf), "%s\n", dpdk_test);
+ if (cmdline_in(cl, buf, strlen(buf)) < 0) {
+ printf("error on cmdline input\n");
+ return -1;
+ }
+
+ cmdline_stdin_exit(cl);
+ return last_test_result;
+ }
+ /* if no DPDK_TEST env variable, go interactive */
cmdline_interact(cl);
cmdline_stdin_exit(cl);
#endif
@@ -231,6 +247,8 @@ unit_test_suite_runner(struct unit_test_suite *suite)
printf(" + Tests Failed : %2d\n", failed);
printf(" + ---
+\n");
+ last_test_result = failed;
+
if (failed)
return -1;
diff --git a/test/test/test.h b/test/test/test.h
index 08ffe94..2e90184 100644
--- a/test/test/test.h
+++ b/test/test/test.h
@@ -218,6 +218,7 @@ struct unit_test_suite {
};
int unit_test_suite_runner(struct unit_test_suite *suite);
+extern int last_test_result;
#define RECURSIVE_ENV_VAR "RTE_TEST_RECURSIVE"
--
2.7.4
Re: [dpdk-dev] [PATCH 2/2] test/test: add return value to mark unit tests as skipped
On Thu, Dec 21, 2017 at 10:48:22AM +, Van Haaren, Harry wrote: > > From: Richardson, Bruce > > Sent: Thursday, December 21, 2017 10:23 AM > > To: dev@dpdk.org; Doherty, Declan ; De Lara > > Guarch, Pablo > > Cc: Van Haaren, Harry > > Subject: Re: [PATCH 2/2] test/test: add return value to mark unit tests as > > skipped > > > > On Thu, Dec 21, 2017 at 10:15:10AM +, Bruce Richardson wrote: > > > Add in a TEST_SKIPPED return value for unit tests to mark the tests > > > as skipped, rather than just failed. Use this new skipped return value for > > > the crypto tests which can only run if they have a particular driver. > > > > > > Signed-off-by: Bruce Richardson > > > > +Declan and Pablo as maintainers of crypto code. > > Looks good to me, checked unit tests using old build system and binary, but > 2nd Ack from crypto maintainers welcome :) > > Acked-by: Harry van Haaren Following IRC discussion this set is now superceded by a new set targeting these changes at the main tree. http://dpdk.org/dev/patchwork/patch/32560/ http://dpdk.org/dev/patchwork/patch/32561/ Patchwork has been updated to reflect this. /Bruce
Re: [dpdk-dev] [RFC v2 1/5] ether: add flow action to redirect packet in a switch domain
On Thu, Dec 21, 2017 at 4:35 AM, Qi Zhang wrote: > Add action RTE_FLOW_ACTION_TYPE_SWITCH_PORT, it can be used to redirect I guess the word "SWITCH" should be remove from commit message. you don't use it later in the patch. > > +Action: ``PORT`` > + > + > +Redirect packets to an interface that connect to the same switch domain. > + > +The desitnation should be managed by a rte_ethdev instance, port_id is > +the identification of the destination. A typical use case is to define > +a flow that redirect packet to a interface that mananged by a Port > +Representor. A verbs would be better suited for an ACTION_TYPE. while ".._TYPE_PORT" is a nous. Probably ".._TYPE_REDIRECT" would better fit here. See man tc-mirred as referance: http://man7.org/linux/man-pages/man8/tc-mirred.8.html Do we want to distinguish between different destination type? The target might be a port (port_id) or potencial other destinations/queue. So maybe use ".._TYPE_REDIRECT_TO_PORT"? Anyway, I think you should remove the "same switch domain" from docs since there is no switch domain yet in DPDK. Lets let the PMD decided if this sucessed or fails, based on the target type and other HW limitations. Not just based on switch domain. PS: I agree switch domain needs to be introduced. I don't think port representor is the correct direction. Alex
Re: [dpdk-dev] [PATCH v4] vhost_user: protect active rings from async ring changes
- Original Message -
> From: "Stephen Hemminger"
> To: "Victor Kaplansky"
> Cc: dev@dpdk.org, sta...@dpdk.org, "Jens Freimann" ,
> "Maxime Coquelin"
> , "Yuanhan Liu" , "Tiwei
> Bie" , "Jianfeng
> Tan"
> Sent: Wednesday, December 20, 2017 10:19:45 PM
> Subject: Re: [dpdk-dev] [PATCH v4] vhost_user: protect active rings from
> async ring changes
>
> On Wed, 20 Dec 2017 15:06:30 -0500 (EST)
> Victor Kaplansky wrote:
>
> > > Wrapping locking inline's adds nothing and makes life harder
> > > for static analysis tools.
> >
> > Yep. In this case it inhibits the details of how the locking is
> > implemented (e.g. the name of the lock). It also facilitates
> > replacement of locking mechanism, by another implementation.
> > See below.
>
> YAGNI You aren't gonna need it.
>
> Don't build infrastructure for things that you forsee.
Good point, thanks. I'll simplify this.
>
>
>
>
> > >
> > > The bigger problem is that doing locking on all enqueue/dequeue
> > > can have a visible performance impact. Did you measure that?
> > >
> > > Could you invent an RCUish mechanism using compiler barriers?
> > >
> >
> > I've played a bit with measuring performance impact. Successful
> > lock adds on the average about 30 cycles on my Haswell cpu.
> > (and it successes 99.999...% of time).
> >
> > I can investigate it more, but my initial feeling is that adding a
> > memory barrier (the real one, not the compiler barrier) would add
> > about the same overhead.
> >
> > By the way, the way update_queuing_status() in
> > drivers/net/vhost/rte_eth_vhost.c tries to avoid contention with
> > the active queue by playing with "allow_queuing" and "while_queuing"
> > seems to be broken, since memory barriers are missing.
>
> CPU cycles alone don't matter on modern x86.
> What matters is cache and instructions per cycle.
> In this case locking requires locked instruction which causes the cpu
> prefetching and instruction pipeline to stall.
>
I agree. I've measured total overhead of added pair of lock/unlock and
it appears to be around 28 cycles per lock/unlock pair on my 3.5GHz Haswell.
>From "Intel® 64 and IA-32 Architectures Software Developer’s Manual
Volume 3A: System Programming Guide, Part 1":
In the Pentium 4, Intel Xeon, and P6 family processors, the
locking operation is handled with either a cache lock or bus
lock. If a memory access is cacheable and affects only a
single cache line, a cache lock is invoked and the system
bus and the actual memory location in system memory are not
locked during the operation. Here, other Pentium 4, Intel
Xeon, or P6 family processors on the bus write-back any
modified data and invalidate their caches as necessary to
maintain system memory coherency. If the memory access is
not cacheable and/or it crosses a cache line boundary, the
processor’s LOCK# signal is asserted and the processor does
not respond to requests for bus control during the locked
operation.
So, the whole memory bus is locked only if the memory access crosses
memory cache line.
Anyway, I'm open to ways to reduce this overhead. This patch fixes a critical
host of bugs reported in bugzilla, so if we can pull this fix
and try to optimize it later by a subsequent patch it would be great.
See below a quick test program I've used to test and measure the overhead.
It also demonstrates the problem I'm trying to fix. Do you have any idea
about using RCU of how to reduce the overhead?
BTW, our implementation of rte_spinlock_unlock() could be slightly faster,
if we would use regular move instead of xchg instruction.
Also our implementation of rte_spinlock_lock() could be faster if we
optimize it for success path by making conditional branch to fall-trough
or even better if we reimplement the spinlock using gcc builtins.
--
Victor
diff --git a/tlock.c b/tlock.c
deleted file mode 100644
index 62c68852..
--- a/tlock.c
+++ /dev/null
@@ -1,91 +0,0 @@
-#include
-#include
-#include
-#include
-
-/* build me with:
- gcc -march=native -std=gnu11 -O3 -lpthread tlock.c -o tlock
-*/
-
-
-
-typedef struct {
-volatile int locked; /**< lock status 0 = unlocked, 1 = locked */
-} rte_spinlock_t;
-
-static inline void
-rte_spinlock_lock(rte_spinlock_t *sl)
-{
-int lock_val = 1;
-asm volatile (
-"1:\n"
-"xchg %[locked], %[lv]\n"
-"test %[lv], %[lv]\n"
-"jz 3f\n"
-"2:\n"
-"pause\n"
-"cmpl $0, %[locked]\n"
-"jnz 2b\n"
-"jmp 1b\n"
-"3:\n"
-: [locked] "=m" (sl->locked), [lv] "=q" (lock_val)
-: "[lv]" (lock_val)
-: "memory");
-}
-
-static inline void
-rte_spinlock_unlock (r
[dpdk-dev] [PATCH v1 1/6] devtools: update check-includes exceptions
rte_eal_interrupts.h is an internal file not supposed to be included
directly by applications.
Signed-off-by: Adrien Mazarguil
Cc: Bruce Richardson
---
devtools/check-includes.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/devtools/check-includes.sh b/devtools/check-includes.sh
index c4ec73f15..685a3e772 100755
--- a/devtools/check-includes.sh
+++ b/devtools/check-includes.sh
@@ -111,6 +111,7 @@ include_dir=${1:-build/include}
'exec-env/*' \
'rte_vhost.h' \
'rte_eth_vhost.h' \
+ 'rte_eal_interrupts.h' \
}
: ${IGNORE_CXX= \
'rte_vhost.h' \
--
2.11.0
[dpdk-dev] [PATCH v1 0/6] Address various issues with exported headers
Exported header files are installed system-wide and must be as clean and self-sufficient as possible. In particular they must not conflict with other system headers and cannot assume specific command-line options will be provided to the compiler by users, unless their absence is detected and triggers appropriate #error messages. This series addresses the following issues: - The lack of rte_config.h inclusion in most of them. - The inability to combine rte_ether.h with system's net/ethernet.h, preventing applications from using the ether_ntoa() family of functions. - A couple of GNUisms (e.g. named variadic arguments in macro definitions). Adrien Mazarguil (6): devtools: update check-includes exceptions net/i40e: fix issue in exported header flow_classify: fix issue in exported header member: fix issue in exported header fix missing includes in exported headers net: fix rte_ether conflicts with libc devtools/check-includes.sh | 1 + drivers/net/avp/rte_avp_common.h| 1 + drivers/net/i40e/base/i40e_osdep.h | 1 + drivers/net/i40e/rte_pmd_i40e.h | 2 +- drivers/net/ixgbe/base/ixgbe_osdep.h| 1 + drivers/net/qede/base/bcm_osal.h| 1 - lib/librte_cmdline/cmdline_cirbuf.h | 2 ++ lib/librte_cryptodev/rte_cryptodev.h| 1 + lib/librte_cryptodev/rte_cryptodev_pmd.h| 1 + .../common/include/arch/x86/rte_atomic.h| 1 + .../common/include/arch/x86/rte_byteorder.h | 1 + .../common/include/arch/x86/rte_cycles.h| 1 + .../common/include/arch/x86/rte_memcpy.h| 1 + .../common/include/arch/x86/rte_vect.h | 1 + .../common/include/generic/rte_byteorder.h | 1 + lib/librte_eal/common/include/rte_bitmap.h | 1 + lib/librte_eal/common/include/rte_common.h | 2 ++ lib/librte_eal/common/include/rte_dev.h | 1 + lib/librte_eal/common/include/rte_eal.h | 1 + .../common/include/rte_eal_memconfig.h | 1 + lib/librte_eal/common/include/rte_keepalive.h | 1 + lib/librte_eal/common/include/rte_lcore.h | 1 + lib/librte_eal/common/include/rte_log.h | 1 + lib/librte_eal/common/include/rte_memory.h | 1 + lib/librte_eal/common/include/rte_service.h | 1 + .../eal/include/exec-env/rte_kni_common.h | 1 + lib/librte_ether/rte_ethdev.h | 1 + lib/librte_ether/rte_ethdev_pci.h | 1 + lib/librte_ether/rte_ethdev_vdev.h | 1 + lib/librte_eventdev/rte_eventdev.h | 1 + lib/librte_eventdev/rte_eventdev_pmd.h | 1 + lib/librte_eventdev/rte_eventdev_pmd_pci.h | 1 + lib/librte_eventdev/rte_eventdev_pmd_vdev.h | 1 + lib/librte_flow_classify/rte_flow_classify.h| 10 +-- lib/librte_hash/rte_fbk_hash.h | 1 + lib/librte_hash/rte_hash_crc.h | 1 + lib/librte_hash/rte_jhash.h | 1 + lib/librte_hash/rte_thash.h | 1 + lib/librte_ip_frag/rte_ip_frag.h| 1 + lib/librte_lpm/rte_lpm.h| 1 + lib/librte_mbuf/rte_mbuf.h | 1 + lib/librte_member/rte_member.h | 12 ++-- lib/librte_mempool/rte_mempool.h| 1 + lib/librte_net/rte_ether.h | 30 +--- lib/librte_ring/rte_ring.h | 1 + lib/librte_table/rte_lru.h | 1 + lib/librte_table/rte_lru_x86.h | 2 ++ lib/librte_timer/rte_timer.h| 1 + 48 files changed, 83 insertions(+), 18 deletions(-) -- 2.11.0
[dpdk-dev] [PATCH v1 3/6] flow_classify: fix issue in exported header
Reported by check-includes.sh:
[...]/rte_flow_classify.h:85:47: error: ISO C does not permit named
variadic macros [-Werror=variadic-macros]
#define RTE_FLOW_CLASSIFY_LOG(level, fmt, args...) \
^
Fixes: be41ac2a330f ("flow_classify: introduce flow classify library")
Cc: Ferruh Yigit
Cc: Bernard Iremonger
Signed-off-by: Adrien Mazarguil
---
lib/librte_flow_classify/rte_flow_classify.h | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/lib/librte_flow_classify/rte_flow_classify.h
b/lib/librte_flow_classify/rte_flow_classify.h
index 1211873a1..e14bc787e 100644
--- a/lib/librte_flow_classify/rte_flow_classify.h
+++ b/lib/librte_flow_classify/rte_flow_classify.h
@@ -70,6 +70,7 @@
*with rte_flow_classifier_free()
*/
+#include
#include
#include
#include
@@ -82,9 +83,12 @@ extern "C" {
extern int librte_flow_classify_logtype;
-#define RTE_FLOW_CLASSIFY_LOG(level, fmt, args...) \
-rte_log(RTE_LOG_ ## level, librte_flow_classify_logtype, "%s(): " fmt, \
- __func__, ## args)
+#define RTE_FLOW_CLASSIFY_LOG(level, ...) \
+ rte_log(RTE_LOG_ ## level, \
+ librte_flow_classify_logtype, \
+ RTE_FMT("%s(): " RTE_FMT_HEAD(__VA_ARGS__,), \
+ __func__, \
+ RTE_FMT_TAIL(__VA_ARGS__,)))
/** Opaque data type for flow classifier */
struct rte_flow_classifier;
--
2.11.0
[dpdk-dev] [PATCH v1 2/6] net/i40e: fix issue in exported header
Reported by check-includes.sh:
[...]/rte_pmd_i40e.h:97:30: error: ISO C restricts enumerator values to
range of `int' [-Werror=pedantic]
RTE_PMD_I40E_PKG_INFO_MAX = 0x
^
Fixes: edeab742edac ("net/i40e: get information about DDP profile")
Cc: Andrey Chilikin
Signed-off-by: Adrien Mazarguil
---
drivers/net/i40e/rte_pmd_i40e.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/i40e/rte_pmd_i40e.h b/drivers/net/i40e/rte_pmd_i40e.h
index 580ca4ae9..49f4427a5 100644
--- a/drivers/net/i40e/rte_pmd_i40e.h
+++ b/drivers/net/i40e/rte_pmd_i40e.h
@@ -94,7 +94,7 @@ enum rte_pmd_i40e_package_info {
RTE_PMD_I40E_PKG_INFO_PCTYPE_LIST,
RTE_PMD_I40E_PKG_INFO_PTYPE_NUM,
RTE_PMD_I40E_PKG_INFO_PTYPE_LIST,
- RTE_PMD_I40E_PKG_INFO_MAX = 0x
+ RTE_PMD_I40E_PKG_INFO_MAX = (int)0x
};
/**
--
2.11.0
[dpdk-dev] [PATCH v1 5/6] fix missing includes in exported headers
Many exported headers rely on definitions found in rte_config.h without
including it, as shown by the following command:
grep -L '^#include ' -- \
$(grep -Rl \
$(sed -n '/^#define \([^ ]\+\).*$/{s//\1/;H;};${x;s/\n//;s/\n/\\|/g;p;}' \
build/include/rte_config.h) \
-- build/include/)
We cannot assume external applications will include rte_config.h on their
own, neither directly nor through a -include parameter like DPDK does
internally.
This not only causes obvious compilation failures that can be reproduced
with check-includes.sh such as:
[...]/rte_memory.h:88:43: error: ‘RTE_CACHE_LINE_SIZE’ was not declared in
this scope
#define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE)
^
It also results in less visible issues, for instance rte_hash_crc.h relying
on RTE_ARCH_X86_64's presence to provide dedicated inline functions.
This patch partially reverts the commit below and adds missing include
lines to the remaining files.
Fixes: f1a7a5c5f404 ("remove include of generated config header")
Cc: Thomas Monjalon
Signed-off-by: Adrien Mazarguil
---
drivers/net/avp/rte_avp_common.h | 1 +
lib/librte_cmdline/cmdline_cirbuf.h | 2 ++
lib/librte_cryptodev/rte_cryptodev.h | 1 +
lib/librte_cryptodev/rte_cryptodev_pmd.h | 1 +
lib/librte_eal/common/include/arch/x86/rte_atomic.h | 1 +
lib/librte_eal/common/include/arch/x86/rte_byteorder.h| 1 +
lib/librte_eal/common/include/arch/x86/rte_cycles.h | 1 +
lib/librte_eal/common/include/arch/x86/rte_memcpy.h | 1 +
lib/librte_eal/common/include/arch/x86/rte_vect.h | 1 +
lib/librte_eal/common/include/generic/rte_byteorder.h | 1 +
lib/librte_eal/common/include/rte_bitmap.h| 1 +
lib/librte_eal/common/include/rte_common.h| 2 ++
lib/librte_eal/common/include/rte_dev.h | 1 +
lib/librte_eal/common/include/rte_eal.h | 1 +
lib/librte_eal/common/include/rte_eal_memconfig.h | 1 +
lib/librte_eal/common/include/rte_keepalive.h | 1 +
lib/librte_eal/common/include/rte_lcore.h | 1 +
lib/librte_eal/common/include/rte_log.h | 1 +
lib/librte_eal/common/include/rte_memory.h| 1 +
lib/librte_eal/common/include/rte_service.h | 1 +
lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h | 1 +
lib/librte_ether/rte_ethdev.h | 1 +
lib/librte_ether/rte_ethdev_pci.h | 1 +
lib/librte_ether/rte_ethdev_vdev.h| 1 +
lib/librte_eventdev/rte_eventdev.h| 1 +
lib/librte_eventdev/rte_eventdev_pmd.h| 1 +
lib/librte_eventdev/rte_eventdev_pmd_pci.h| 1 +
lib/librte_eventdev/rte_eventdev_pmd_vdev.h | 1 +
lib/librte_hash/rte_fbk_hash.h| 1 +
lib/librte_hash/rte_hash_crc.h| 1 +
lib/librte_hash/rte_jhash.h | 1 +
lib/librte_hash/rte_thash.h | 1 +
lib/librte_ip_frag/rte_ip_frag.h | 1 +
lib/librte_lpm/rte_lpm.h | 1 +
lib/librte_mbuf/rte_mbuf.h| 1 +
lib/librte_member/rte_member.h| 1 +
lib/librte_mempool/rte_mempool.h | 1 +
lib/librte_ring/rte_ring.h| 1 +
lib/librte_table/rte_lru.h| 1 +
lib/librte_table/rte_lru_x86.h| 2 ++
lib/librte_timer/rte_timer.h | 1 +
41 files changed, 44 insertions(+)
diff --git a/drivers/net/avp/rte_avp_common.h b/drivers/net/avp/rte_avp_common.h
index 54437e9a1..81dfe5ea6 100644
--- a/drivers/net/avp/rte_avp_common.h
+++ b/drivers/net/avp/rte_avp_common.h
@@ -63,6 +63,7 @@
#else
#include
#include
+#include
#include
#include
#include
diff --git a/lib/librte_cmdline/cmdline_cirbuf.h
b/lib/librte_cmdline/cmdline_cirbuf.h
index 6321dec5c..87407efa1 100644
--- a/lib/librte_cmdline/cmdline_cirbuf.h
+++ b/lib/librte_cmdline/cmdline_cirbuf.h
@@ -61,6 +61,8 @@
#ifndef _CIRBUF_H_
#define _CIRBUF_H_
+#include
+
#ifdef __cplusplus
extern "C" {
#endif
diff --git a/lib/librte_cryptodev/rte_cryptodev.h
b/lib/librte_cryptodev/rte_cryptodev.h
index dade5548f..ed92f9822 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -49,6 +49,7 @@ extern "C" {
#include "rte_crypto.h"
#include "rte_dev.h"
#include
+#include
extern const char **rte_cyptodev_names;
diff --git a/lib/librte_cry
[dpdk-dev] [PATCH v1 6/6] net: fix rte_ether conflicts with libc
Applications can't combine either net/ethernet.h or netinet/ether.h
together with rte_ether.h due to the redefinition of struct ether_addr and
various macros by the latter.
This patch adapts rte_ether.h to rely on system definitions while
maintaining DPDK additions.
An unforeseen consequence of involving more system header files compilation
issues with some base drivers (i40e, ixgbe) defining their own conflicting
types (e.g. __le64). This is addressed by explicitly including rte_ether.h
where missing to ensure system definitions always come first.
Signed-off-by: Adrien Mazarguil
Cc: Olivier Matz
Cc: Bruce Richardson
---
This patch should work but wasn't validated on FreeBSD, any volunteers?
---
drivers/net/i40e/base/i40e_osdep.h | 1 +
drivers/net/ixgbe/base/ixgbe_osdep.h | 1 +
drivers/net/qede/base/bcm_osal.h | 1 -
lib/librte_net/rte_ether.h | 30 --
4 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/net/i40e/base/i40e_osdep.h
b/drivers/net/i40e/base/i40e_osdep.h
index 8e5c593c9..0f53d8f66 100644
--- a/drivers/net/i40e/base/i40e_osdep.h
+++ b/drivers/net/i40e/base/i40e_osdep.h
@@ -40,6 +40,7 @@
#include
#include
+#include
#include
#include
#include
diff --git a/drivers/net/ixgbe/base/ixgbe_osdep.h
b/drivers/net/ixgbe/base/ixgbe_osdep.h
index bb5dfd2af..a59d2a63f 100644
--- a/drivers/net/ixgbe/base/ixgbe_osdep.h
+++ b/drivers/net/ixgbe/base/ixgbe_osdep.h
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
#include
diff --git a/drivers/net/qede/base/bcm_osal.h b/drivers/net/qede/base/bcm_osal.h
index 52c2f0ec9..c4c8e179e 100644
--- a/drivers/net/qede/base/bcm_osal.h
+++ b/drivers/net/qede/base/bcm_osal.h
@@ -334,7 +334,6 @@ u32 qede_find_first_zero_bit(unsigned long *, u32);
qede_find_first_zero_bit(bitmap, length)
#define OSAL_BUILD_BUG_ON(cond)nothing
-#define ETH_ALEN ETHER_ADDR_LEN
#define OSAL_BITMAP_WEIGHT(bitmap, count) 0
diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
index 06d7b486c..19e62ea89 100644
--- a/lib/librte_net/rte_ether.h
+++ b/lib/librte_net/rte_ether.h
@@ -44,6 +44,7 @@
extern "C" {
#endif
+#include
#include
#include
@@ -52,15 +53,7 @@ extern "C" {
#include
#include
-#define ETHER_ADDR_LEN 6 /**< Length of Ethernet address. */
-#define ETHER_TYPE_LEN 2 /**< Length of Ethernet type field. */
-#define ETHER_CRC_LEN 4 /**< Length of Ethernet CRC. */
-#define ETHER_HDR_LEN \
- (ETHER_ADDR_LEN * 2 + ETHER_TYPE_LEN) /**< Length of Ethernet header. */
-#define ETHER_MIN_LEN 64/**< Minimum frame len, including CRC. */
-#define ETHER_MAX_LEN 1518 /**< Maximum frame len, including CRC. */
-#define ETHER_MTU \
- (ETHER_MAX_LEN - ETHER_HDR_LEN - ETHER_CRC_LEN) /**< Ethernet MTU. */
+#define ETHER_MTU ETHERMTU /**< Deprecated, defined for compatibility. */
#define ETHER_MAX_VLAN_FRAME_LEN \
(ETHER_MAX_LEN + 4) /**< Maximum VLAN frame length, including CRC. */
@@ -72,8 +65,11 @@ extern "C" {
#define ETHER_MIN_MTU 68 /**< Minimum MTU for IPv4 packets, see RFC 791. */
+#ifdef __DOXYGEN__
+
/**
- * Ethernet address:
+ * Ethernet address.
+ *
* A universally administered address is uniquely assigned to a device by its
* manufacturer. The first three octets (in transmission order) contain the
* Organizationally Unique Identifier (OUI). The following three (MAC-48 and
@@ -82,11 +78,25 @@ extern "C" {
* A locally administered address is assigned to a device by a network
* administrator and does not contain OUIs.
* See http://standards.ieee.org/regauth/groupmac/tutorial.html
+ *
+ * This structure is defined system-wide by "net/ethernet.h", however since
+ * the name of its data field is OS-dependent, a macro named "addr_bytes" is
+ * defined as an alias for the convenience of DPDK applications.
+ *
+ * The following definition is only for documentation purposes.
*/
struct ether_addr {
uint8_t addr_bytes[ETHER_ADDR_LEN]; /**< Addr bytes in tx order */
} __attribute__((__packed__));
+#endif /* __DOXYGEN__ */
+
+#if defined(__FreeBSD__)
+#define addr_bytes octet
+#else
+#define addr_bytes ether_addr_octet
+#endif
+
#define ETHER_LOCAL_ADMIN_ADDR 0x02 /**< Locally assigned Eth. address. */
#define ETHER_GROUP_ADDR 0x01 /**< Multicast or broadcast Eth. address.
*/
--
2.11.0
[dpdk-dev] [PATCH v1 4/6] member: fix issue in exported header
Reported by check-includes.sh:
[...]/rte_member.h:107:40: error: ISO C does not permit named variadic
macros [-Werror=variadic-macros]
#define RTE_MEMBER_LOG(level, fmt, args...) \
^
Fixes: 857ed6c68cf2 ("member: implement main API")
Cc: Yipeng Wang
Signed-off-by: Adrien Mazarguil
---
lib/librte_member/rte_member.h | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/lib/librte_member/rte_member.h b/lib/librte_member/rte_member.h
index 9b0c8f99c..fa0871122 100644
--- a/lib/librte_member/rte_member.h
+++ b/lib/librte_member/rte_member.h
@@ -80,6 +80,8 @@ extern "C" {
#include
+#include
+
/** The set ID type that stored internally in hash table based set summary. */
typedef uint16_t member_set_t;
/** Invalid set ID used to mean no match found. */
@@ -104,9 +106,12 @@ typedef uint16_t member_set_t;
extern int librte_member_logtype;
-#define RTE_MEMBER_LOG(level, fmt, args...) \
-rte_log(RTE_LOG_ ## level, librte_member_logtype, "%s(): " fmt, \
- __func__, ## args)
+#define RTE_MEMBER_LOG(level, ...) \
+ rte_log(RTE_LOG_ ## level, \
+ librte_member_logtype, \
+ RTE_FMT("%s(): " RTE_FMT_HEAD(__VA_ARGS__,), \
+ __func__, \
+ RTE_FMT_TAIL(__VA_ARGS__,)))
/** @internal setsummary structure. */
struct rte_member_setsum;
--
2.11.0
Re: [dpdk-dev] [RFC v2 0/5] rte_flow extension for vSwitch acceleration
On Thu, Dec 21, 2017 at 4:35 AM, Qi Zhang wrote: > This patch extend rte_flow API. > The purpose is to provide comfortable programming interface for virtual switch > software (such as OVS) to take advantage of incoming device's vSwitch > acceleration > capability when using DPDK as data plane. > > Below is summary of changes: > > 1. Support to specify flow's destination as an ethdev interface. > > Add action RTE_FLOW_ACTION_TYPE_ETHDEV_PORT, use port_id as the identification > of the destitation. A typical use case is, with a smart NIC used for vSwitch > acceleration, flow is defined to redirect packet between switch port that is > managed by a Port Representor. > See patch for Port Representor: http://dpdk.org/dev/patchwork/patch/31458/ If we are going to have a representation of a switch in DPDK then I we need real PMD's for the switch ports, and not virtual PMD's as in the Port Representor model. These real ports will probably require specific switch_ops, which are different than the NIC (eth_dev_ops). At least few additional on top of NIC ops. We will need to support Tx and Rx burst on these switch ports and configure ACL's, flooding mode and more. Alex
Re: [dpdk-dev] [PATCH v1] [net/tap] add logic to assign speed from user
> On Dec 21, 2017, at 10:53 AM, Vipin Varghese wrote: > > TAP speed is passed as user argument, but never set to interface. > New logic brings speed get and set to LOCAL and REMOTE interfaces. > > Updated the default PMD speeed to 10M as per Linux Kernel default > value. The problem in setting the link speed to 10M is that TAP will not limit its traffic to 10M. Applications like pktgen and others use the Link speed to calculate the bit rate, which will be broken now. I would suggest making the default value 10G or 40G instead as CPU speeds will continue to increase. Forcing someone to always add the link speed seems a bit much when we know the systems can send/receive much higher then 10M, which is the reason 10G was picked. Please set the default back to 10G or some much higher number. > > Signed-off-by: Vipin Varghese > --- > drivers/net/tap/rte_eth_tap.c | 185 +- > 1 file changed, 182 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c > index 6b27679..7238504 100644 > --- a/drivers/net/tap/rte_eth_tap.c > +++ b/drivers/net/tap/rte_eth_tap.c > @@ -62,6 +62,8 @@ > #include > #include > #include > +#include > +#include > Regards, Keith
Re: [dpdk-dev] [PATCH v2 15/39] examples/ipsec-secgw: convert to new ethdev offloads API
Hi Pablo and maintainers of ipsec-secgw,
Tuesday, December 19, 2017 2:39 PM, De Lara Guarch, Pablo
> > diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-
> > secgw/ipsec-secgw.c index c98454a..1e8af8d 100644
> > --- a/examples/ipsec-secgw/ipsec-secgw.c
> > +++ b/examples/ipsec-secgw/ipsec-secgw.c
> > @@ -217,6 +217,9 @@ struct lcore_conf {
> > },
> > .txmode = {
> > .mq_mode = ETH_MQ_TX_NONE,
> > + .offloads = (DEV_TX_OFFLOAD_IPV4_CKSUM |
> > +DEV_TX_OFFLOAD_MULTI_SEGS |
> > +DEV_TX_OFFLOAD_MBUF_FAST_FREE),
>
> Hi Shahaf,
>
> Isn't this removing some checksums that were previously done?
> Txq_flags was set to 0, which means that SCTP, UDP... checksums are
> disabled now?
You are right that before txqflags were 0, but it doesn't seem the application
uses any Tx checksum offload beside IPv4, as seen on snipped code[1].
If I was mistaken and it does uses L4 checksums then I will need to update this
commit.
Maintainers of this examples - can you confirm?
[1]
static inline void
prepare_tx_pkt(struct rte_mbuf *pkt, uint16_t port)
{
struct ip *ip;
struct ether_hdr *ethhdr;
ip = rte_pktmbuf_mtod(pkt, struct ip *);
ethhdr = (struct ether_hdr *)rte_pktmbuf_prepend(pkt, ETHER_HDR_LEN);
if (ip->ip_v == IPVERSION) {
pkt->ol_flags |= PKT_TX_IP_CKSUM | PKT_TX_IPV4;
pkt->l3_len = sizeof(struct ip);
pkt->l2_len = ETHER_HDR_LEN;
ethhdr->ether_type = rte_cpu_to_be_16(ETHER_TYPE_IPv4);
} else {
pkt->ol_flags |= PKT_TX_IPV6;
pkt->l3_len = sizeof(struct ip6_hdr);
pkt->l2_len = ETHER_HDR_LEN;
ethhdr->ether_type = rte_cpu_to_be_16(ETHER_TYPE_IPv6);
}
memcpy(ðhdr->s_addr, ðaddr_tbl[port].src,
sizeof(struct ether_addr));
memcpy(ðhdr->d_addr, ðaddr_tbl[port].dst,
sizeof(struct ether_addr));
}
>
> Regards,
> Pablo
>
Re: [dpdk-dev] [PATCH v2 03/39] examples/l2fwd-jobstats: convert to new ethdev offloads API
Tuesday, December 19, 2017 2:33 PM, De Lara Guarch, Pablo:
>
> There is a compilation error when building for 32-bit targets:
>
> examples/l2fwd-jobstats/main.c:883:11: error: format '%lx' expects
> argument of type 'long unsigned int', but argument 3 has type 'uint64_t {aka
> long long unsigned int}'
> [-Werror=format=]
> printf("Some Rx offloads are not supported "
>^
> examples/l2fwd-jobstats/main.c:883:11: error: format '%lx' expects
> argument of type 'long unsigned int', but argument 4 has type 'uint64_t {aka
> long long unsigned int}'
> [-Werror=format=]
> examples/l2fwd-jobstats/main.c:890:11: error: format '%lx' expects
> argument of type 'long unsigned int', but argument 3 has type 'uint64_t {aka
> long long unsigned int}'
> [-Werror=format=]
> printf("Some Tx offloads are not supported "
>^
> examples/l2fwd-jobstats/main.c:890:11: error: format '%lx' expects
> argument of type 'long unsigned int', but argument 4 has type 'uint64_t {aka
> long long unsigned int}'
> [-Werror=format=]
>
> This happens on all the apps (I acked the first two apps, since I missed this
> issue when I was reviewing them).
Thanks, will take care.
In fact am thinking of removing those prints, they don't seems necessary. The
PMD can print error/warn log in case of bad offloads configuration.
>
> Thanks,
> Pablo
Re: [dpdk-dev] [RFC v2 3/5] ether: Add flow timeout support
On Thu, Dec 21, 2017 at 4:35 AM, Qi Zhang wrote: > Add new APIs to support flow timeout, application is able to > 1. Setup the time duration of a flow, the flow is expected to be deleted > automatically when timeout. Can you explain how the application (OVS) is expected to use this API? It will help to better understand the motivation here... Are you trying to move the aging timer from application code into the PMD? or can your HW remove/disable/inactivate a flow at certain time semantics without software context? I would prefer to have the aging timer logic in a centralized location, leek the application itself or some DPDK library. instead of having each PMD implement its own software timers. > 3. Register a callback function when a flow is deleted due to timeout. Is the application 'struct rte_flow*' handle really deleted? or the flow was removed from HW, just in-active at this time? Can a flow be re-activated? or does this require a call to rte_flow_destory() and ret_flow_create()? Alex
Re: [dpdk-dev] [PATCH v2 05/39] examples/l3fwd: move to ethdev offloads API
>Looking at diff between v1 and v2, following lines are missing:
>
>- port_conf.rxmode.offloads &= dev_info.rx_offload_capa;
>- port_conf.txmode.offloads &= dev_info.tx_offload_capa;
>
>I can see this change is consistent across all examples. Is it intentional to
>enforce the capabilities this way?
Yes it was intentional.
The reason is that application is relying on its offloads to be set. So any
offloads set by the application must reach the PMD, otherwise application won’t
work correctly.
For example – if application needs Rx checksum, and it is silently masked (by
v1 of this series) then it will wrongly assume all checksums are bad.
This is true almost to every offloads. One is exceptional -
DEV_TX_OFFLOAD_MBUF_FAST_FREE. Application *can* work without it, as it is only
a performance optimization for the mbuf free.
>If so, why enforcing DEV_RX_OFFLOAD_CHECKSUM if the feature is not used by
>l3fwd code?
>I.e. there is no reference to RX-side ol_flags so application can run without
>it.
You are right.
When I worked on this code I used the DEV_RX_OFFLOAD_CHECKSUM offloads because
also the original example enabled it (hw_ip_checksum = 1)
Adding Thomas the maintainer to confirm.
If it doesn’t use , then we can safely remove this offload.
>
>In v1 the flag was optional which made sense for this particular case.
--Shahaf
From: Maciej Czekaj [mailto:m...@semihalf.com]
Sent: Monday, December 18, 2017 6:00 PM
To: Shahaf Shuler ; dev@dpdk.org;
konstantin.anan...@intel.com; radu.nico...@intel.com; arybche...@solarflare.com
Subject: Re: [dpdk-dev] [PATCH v2 05/39] examples/l3fwd: move to ethdev
offloads API
-- Oryginal message --
Ethdev offloads API has changed since:
commit ce17eddefc20 ("ethdev: introduce Rx queue offloads API")
commit cba7f53b717d ("ethdev: introduce Tx queue offloads API")
This commit support the new API.
Signed-off-by: Shahaf Shuler
---
examples/l3fwd/main.c | 40 ++--
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
index 6229568..3bdf4d5 100644
--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -149,11 +149,9 @@ struct lcore_params {
.mq_mode = ETH_MQ_RX_RSS,
.max_rx_pkt_len = ETHER_MAX_LEN,
.split_hdr_size = 0,
- .header_split = 0, /**< Header Split disabled */
- .hw_ip_checksum = 1, /**< IP checksum offload enabled */
- .hw_vlan_filter = 0, /**< VLAN filtering disabled */
- .jumbo_frame= 0, /**< Jumbo Frame Support disabled */
- .hw_strip_crc = 1, /**< CRC stripped by hardware */
+ .ignore_offload_bitfield = 1,
+ .offloads = (DEV_RX_OFFLOAD_CRC_STRIP |
+DEV_RX_OFFLOAD_CHECKSUM),
},
.rx_adv_conf = {
.rss_conf = {
@@ -163,6 +161,7 @@ struct lcore_params {
},
.txmode = {
.mq_mode = ETH_MQ_TX_NONE,
+ .offloads = DEV_TX_OFFLOAD_MBUF_FAST_FREE,
},
};
@@ -612,7 +611,8 @@ enum {
};
printf("%s\n", str8);
- port_conf.rxmode.jumbo_frame = 1;
+ port_conf.rxmode.offloads |= DEV_RX_OFFLOAD_JUMBO_FRAME;
+ port_conf.txmode.offloads |= DEV_TX_OFFLOAD_MULTI_SEGS;
/*
* if no max-pkt-len set, use the default
@@ -908,6 +908,22 @@ enum {
n_tx_queue = MAX_TX_QUEUE_PER_PORT;
printf("Creating queues: nb_rxq=%d nb_txq=%u... ",
nb_rx_queue, (unsigned)n_tx_queue );
+
+ rte_eth_dev_info_get(portid, &dev_info);
+ if ((dev_info.rx_offload_capa & port_conf.rxmode.offloads) !=
+ port_conf.rxmode.offloads) {
+ printf("Some Rx offloads are not supported "
+ "by port %d: requested 0x%lx supported 0x%lx\n",
+ portid, port_conf.rxmode.offloads,
+ dev_info.rx_offload_capa);
+ }
+ if ((dev_info.tx_offload_capa & port_conf.txmode.offloads) !=
+ port_conf.txmode.offloads) {
+ printf("Some Tx offloads are not supported "
+ "by port %d: requested 0x%lx supported 0x%lx\n",
+ portid, port_conf.txmode.offloads,
+ dev_info.tx_offload_capa);
+ }
Looking at diff between v1 and v2, following lines are missing:
- port_conf.rxmode.offloads &= dev_info.rx_offload_capa;
- port_conf.txmode.offloads &= dev_info.tx_offload_ca
[dpdk-dev] [PATCH] doc: add i40e update in release note
From: Beilei Xing Updates 17.11 release note to declare GTPU/GTPC support in i40e driver. Signed-off-by: Beilei Xing --- doc/guides/rel_notes/release_17_11.rst | 10 ++ 1 file changed, 10 insertions(+) diff --git a/doc/guides/rel_notes/release_17_11.rst b/doc/guides/rel_notes/release_17_11.rst index 016a08c..d2df7cf 100644 --- a/doc/guides/rel_notes/release_17_11.rst +++ b/doc/guides/rel_notes/release_17_11.rst @@ -273,6 +273,16 @@ New Features applications to classify an input packet by matching it against a set of flow rules. It uses the ``librte_table`` API to manage the flow rules. +* **Updated i40e driver to support GTPC/GTPU.** + + Updated i40e PMD to support GTPC/GTPU with GTPC/GTPU supporting + profiles which can be programed by dynamic device personalization (DDP) + process: + + * Support RSS of GTPC/GTPU flow. + * Support flow director of GTPC/GTPU flow base on TEID. + * Support cloud filer of GTPC/GTPU flow base on TEID. + Resolved Issues --- -- 2.4.11
Re: [dpdk-dev] [PATCH v1 5/6] fix missing includes in exported headers
On Thu, Dec 21, 2017 at 02:00:04PM +0100, Adrien Mazarguil wrote:
> Many exported headers rely on definitions found in rte_config.h without
> including it, as shown by the following command:
>
> grep -L '^#include ' -- \
> $(grep -Rl \
> $(sed -n '/^#define \([^ ]\+\).*$/{s//\1/;H;};${x;s/\n//;s/\n/\\|/g;p;}' \
> build/include/rte_config.h) \
> -- build/include/)
>
> We cannot assume external applications will include rte_config.h on their
> own, neither directly nor through a -include parameter like DPDK does
> internally.
>
> This not only causes obvious compilation failures that can be reproduced
> with check-includes.sh such as:
>
> [...]/rte_memory.h:88:43: error: ‘RTE_CACHE_LINE_SIZE’ was not declared in
> this scope
> #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE)
> ^
>
> It also results in less visible issues, for instance rte_hash_crc.h relying
> on RTE_ARCH_X86_64's presence to provide dedicated inline functions.
>
> This patch partially reverts the commit below and adds missing include
> lines to the remaining files.
>
> Fixes: f1a7a5c5f404 ("remove include of generated config header")
> Cc: Thomas Monjalon
>
> Signed-off-by: Adrien Mazarguil
> ---
Hi Adrien,
Just FYI, when we move to the new DPDK build system and pass the
necessary build meta-data to the application using pkg-config, this
should be a non-issue, as the pkg-config information will include the
"-include rte_config.h" parameter.
When investigating that, I also tried this approach of adding rte_config
to files explicitly but it did not work for me as expected, as there
were cases where the build was depending upon the rte_config.h always
being the first include in the file. Normally, the rte_* headers should
be last included, so putting it at the top just didn't seem right to me.
I don't remember the specifics, but it was something like using the RTE_
defines to determine which system header file to use e.g. BSD vs Linux.
However, this may be an internal DPDK-build restriction rather than one
that would affect user-apps our or examples.
So, with transitioning to meson and pkg-config, this issue becomes less
significant.
/Bruce
Re: [dpdk-dev] [PATCHv4 0/4] dpdk: enhance EXPERIMENTAL api tagging
On Wed, Dec 13, 2017 at 10:17:23AM -0500, Neil Horman wrote: > Hey all- > A few days ago, I was lamenting the fact that, when reviewing patches > I > would frequently complain about ABI changes that were actually considered safe > because they were part of the EXPERIMENTAL api set. John M. asked me then > what > I might do to improve the situation, and the following patch set is a proposal > that I've come up with. > > In thinking about the problem I identified two issues that I think we > can improve on in this area: > > 1) Make experimental api calls more visible in the source code. That is to > say, > when reviewing patches, it would be nice to have some sort of visual reference > that indicates that the changes being made are part of an experimental API and > therefore ABI concerns need not be addressed > > 2) Make experimenal api usage more visible to consumers of the DPDK, so that > they can make a more informed decision about the API's they consume in their > application. We make an effort to document all the experimental API's, but > there is no guarantee that a user will check the documentation before making > use > of a new library. > > This patch set attempts to achieve both of the above goals. To do this I've > added an __experimental macro tag, suitable for inserting into api forward > declarations and definitions. > > The presence of the tag in the header and c files where the api code resides > increases the likelyhood that any patch submitted against them will include > the > tag in the context, making it clear to reviewers that ABI stability isn't a > concern here. > > Also, This tag marks each function it is used on with an attibute causing any > use of the fuction to emit a warning during the build > with a message indicating that the API call in question is not yet part of the > stable interface. Developers can then make an informed decision to suppress > that warning or not. > > Because there is internal use of several experimental API's, this set also > includes a new override macro ALLOW_EXPERIMENTAL_APIS to automatically > suprress these warnings. I think its fair to assume that, for internal use, > we > almost always want to suppress these warnings, as by definition any change to > the apis (even their removal) must be done in parallel with an appropriate > change in the calling locations, lest the dpdk build itself break. > > Neil > > --- > Change Notes: > v2) > * Cleaned up checkpatch errors > * Added Allowance for building experimental on BSD > * Swapped Patch 3 and 4 so that we didn't have a commit level that issued > warnings/errors without need > > v3) > * On suggestion from Bruce, modify ALLOW_EXPERIMENTAL_APIS to be defined in > CFLAGS rather than a makefile variable. This is more flexible in that it > allows us to suppress this specific feature rather than all uses of the > deprecated attribute, as we might use it for other features in the furute > > v4) > * Added documentation patch to contributors guide > > Ping, can I get some more reviews/acks here please? Neil
Re: [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add target queues in flow actions
On Thu, Dec 21, 2017 at 12:12:29PM +0200, Boris Pismenny wrote: > On 12/21/2017 10:06 AM, Anoob Joseph wrote: > > I can see the benefits of using rte_flow in both rx & tx, but this > > unnecessarily introduces hardware requirements for supporting inline. > > Rte_flow would do two operations: > > 1) Pattern matching > > 2) Perform some operation with the above matched packets > > > > Issue is with pattern matching, not about performing the operations > > specified. If we need rte_flow in the tx, the PMD should support pattern > > matching in software or hardware. Since the application will have to do > > a lookup in it's space to determine the SA, the secondary lookup in the > > PMD may not be necessary. But making rte_flow mandatory would make tx > > side pattern matching mandatory, which may not be supported on all > > hardware (with inline crypto/protocol). Also the pattern matching > > hardware module should be able to submit to inline performing module for > > this to work. > > > > May be the right approach is to decouple pattern matching from actions > > to be performed for the flow. In other words, add a new API to allow > > application to submit a packet to a flow. In such case, application > > could do the lookup and submit packet to a flow. The packet submitted > > could be validated to see if it is matching the flow properties. If it > > is matching, then the actions specified for the flow would be performed. > > Adding such an API will allow rte_flow to be used with hardware which > > doesn't have packet filtering features. > > > > The flow could have a "pattern item" which would say whether application > > can submit packets to the flow. Submit would be allowed only for those > > flows. flow_validate would give PMD the option to accept or reject such > > a model. This may need some thought before we can start implementing, > > like, whether we should support "submit" for flows which doesn't have > > terminating action. > > > > Any thoughts? > > I think that your suggested API is more or less the intended use of rte_flow > egress actions with rte_security. > > Would it be wrong to say that you could use rte_flow without doing pattern > matching in HW or in the PMD in the data-path? > Suppose that your HW doesn't support pattern matching on tx. But, you do > support IPsec inline crypto on tx according to user provided pointers that > you set in the set_pkt_metadata callback. The user will call rte_create_flow > with some pattern, in response you check that the driver's set_pkt_metadata > could handle such patterns and actions on tx. If yes, then return success, > otherwise return false. The successful creation of the flow will indicate to > the user that packets with this format will be offloaded. Packets with other > formats will not get offload and set_pkt_metadata for such packets shouldn't > be called! > > When using rte_flow with IPsec, it is used not to indicate that HW must do > this pattern matching. But rather to indicate that software will send > packets that match a pattern with proper metadata and expect an action to be > applied. Software cannot expect this action to be applied unless the packet > matches the pattern and the proper metadata is provided. For example, > packets with IPv6 extension headers should not go through IPsec inline > crypto offload if the pattern is IPv6/ESP because the next IP protocol must > be ESP. I think there's already a way to satisfy everyone regarding context requirements on TX without the huge penalty of SW parsing in case HW doesn't support matching on egress. While seldom used at the moment, rte_flow patterns can match packet meta-data (see meta pattern items); for instance RTE_FLOW_ITEM_TYPE_PORT matches a physical port of the underlying device. This works both with ingress and egress. For ingress, RTE_FLOW_ACTION_TYPE_MARK can be used to add meta data to selected packets. While for egress such an action doesn't make much sense at the moment, the converse meta pattern item (RTE_FLOW_ITEM_TYPE_MARK) could be useful to let PMD know what needs to be done with packets submitted by the application and containing a given mark. That way, PMDs that do not support egress packet matching wouldn't need to lie and would reject rules such as: flow create X egress pattern ip / udp / end actions whatever / end But would accept: flow create X egress pattern mark is 42 / end actions whatever / end PMDs could also support combinations (remember the position of meta items within a pattern is not significant) to only perform whatever for UDPv4 packets marked with 42. Non-marked packets would go through unmodified: flow create X egress pattern ip / udp / mark is 42 / end actions whatever / end This is just to point out how leveraging meta pattern items on egress is one possibility using MARK as an example. -- Adrien Mazarguil 6WIND
Re: [dpdk-dev] [PATCH v2 05/39] examples/l3fwd: move to ethdev offloads API
Wednesday, December 13, 2017 7:32 PM, Jerin Jacob: > > OK. I just suggested because adding the flag in PMD is harmless and we can > avoid an extra check(setting the DEV_TX_OFFLOAD_MBUF_FAST_FREE only > when PMD supports it) in application to hide warning as you pointed out. > No strong opinion on the specifics, I am just cared only reaching the flag to > driver. Following some other comments from different examples I believe the way to go is the following: 1. application will set the offloads it *must have* in order to properly function. PMD will fail the configuration if not supported. Such kind of offloads are basically all the offloads besides DEV_TX_OFFLOAD_MBUF_FAST_FREE as it is an optimization. 2. application will set optional features only if supported (such as DEV_TX_OFFLOAD_MBUF_FAST_FREE) 3. I will remove the redundant print for offloads set but not supported. This can be done in the PMD level based on its implemented (as I understood some PMDs don't set some offloads but do expect to have them enabled. This though should be fixed IMO). > >
Re: [dpdk-dev] [dpdk-stable] [PATCH] net/mlx5: fix VLAN configuration after port stop
Wednesday, December 13, 2017 4:03 PM, Shahaf Shuler:
> Ethdev layer has an API to configure vlan setting on the flight, i.e.
> when the port state is start.
>
> calling such API when the port is stopped may cause segmentation fault as
> the related Verbs contexts has not been created yet.
>
> Fixes: 09cb5b581762 ("net/mlx5: separate DPDK from verbs Rx queue
> objects")
> Cc: nelio.laranje...@6wind.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Shahaf Shuler
> Acked-by: Nelio Laranjeiro
> ---
Applied to next-net-mlx, thanks.
Re: [dpdk-dev] [PATCH v1 5/6] fix missing includes in exported headers
On Thu, Dec 21, 2017 at 02:12:57PM +, Bruce Richardson wrote:
> On Thu, Dec 21, 2017 at 02:00:04PM +0100, Adrien Mazarguil wrote:
> > Many exported headers rely on definitions found in rte_config.h without
> > including it, as shown by the following command:
> >
> > grep -L '^#include ' -- \
> > $(grep -Rl \
> > $(sed -n '/^#define \([^
> > ]\+\).*$/{s//\1/;H;};${x;s/\n//;s/\n/\\|/g;p;}' \
> > build/include/rte_config.h) \
> > -- build/include/)
> >
> > We cannot assume external applications will include rte_config.h on their
> > own, neither directly nor through a -include parameter like DPDK does
> > internally.
> >
> > This not only causes obvious compilation failures that can be reproduced
> > with check-includes.sh such as:
> >
> > [...]/rte_memory.h:88:43: error: ‘RTE_CACHE_LINE_SIZE’ was not declared in
> > this scope
> > #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE)
> > ^
> >
> > It also results in less visible issues, for instance rte_hash_crc.h relying
> > on RTE_ARCH_X86_64's presence to provide dedicated inline functions.
> >
> > This patch partially reverts the commit below and adds missing include
> > lines to the remaining files.
> >
> > Fixes: f1a7a5c5f404 ("remove include of generated config header")
> > Cc: Thomas Monjalon
> >
> > Signed-off-by: Adrien Mazarguil
> > ---
>
> Hi Adrien,
>
> Just FYI, when we move to the new DPDK build system and pass the
> necessary build meta-data to the application using pkg-config, this
> should be a non-issue, as the pkg-config information will include the
> "-include rte_config.h" parameter.
Right, actually -include rte_config.h is also provided to applications that
rely on the current DPDK build system, those are already safe.
The motivation behind this patch is other applications that casually
#include things without even depending on the build features of DPDK (not
even going through pkg-config manually), in order to meet a safety level
worthy of /usr/include.
In my opinion it's fine if this usage is not supported and a prior #include
is required, however in that case we need our header files to
#error out. Adding #include directly as done in this patch was in fact just
as easy.
> When investigating that, I also tried this approach of adding rte_config
> to files explicitly but it did not work for me as expected, as there
> were cases where the build was depending upon the rte_config.h always
> being the first include in the file. Normally, the rte_* headers should
> be last included, so putting it at the top just didn't seem right to me.
> I don't remember the specifics, but it was something like using the RTE_
> defines to determine which system header file to use e.g. BSD vs Linux.
> However, this may be an internal DPDK-build restriction rather than one
> that would affect user-apps our or examples.
Was it perhaps before we added consistency to all public headers?
check-includes.sh was added a few releases ago to make sure each of them
could be included on its own, to ensure they properly fetched all their
dependencies instead of triggering compilation errors.
Rule of thumb being if you need something, #include the file providing it
first. I find it strange rte_config.h is somehow an exception.
> So, with transitioning to meson and pkg-config, this issue becomes less
> significant.
Agreed, however I still think something needs to be done, so:
- Do we want to let applications not rely on our build flags yet still use
our exported headers?
- Is a missing #include supposed to trigger an explicit
#error for safety?
- How about putting back #include in our exported header
files directly given the above?
Note this discussion is only about exported headers. The rest remains
unaffected and can safely continue to rely on -include rte_config.h.
--
Adrien Mazarguil
6WIND
Re: [dpdk-dev] [RFC 0/5] Port Representor for control and monitoring of VF devices
Declan, Mohammad, The submission [1] of steering action between switch ports clearly requires a switch model in DPDK. The Port Representor based on a virtual PMD broker on NIC ops (rte_dev_ops) does not provide the required functionality. Using NIC terminology and not Switch API's will lead to a dead-end. Moreover, it does not fit the Kernel design. We need to be careful from this ending up as two different deployment models for users, which is very bad. There was a long discussion about this in netdev ML [2], including the VEPA mode support. As described in the links Alejandro referenced earlier, each of the switch ports should be a real PMD, and switch operations should be applied on these PMD ports. This includes the steering redirection of traffic between switch ports [1], port ACL's to block/allow traffic, VST/VGT modes and anti spoofing, link trust mode [3] for promiscuous configuration, mirroring of switch port traffic, and Tx and Rx of switch port traffic to/from VF's port. More over, building this as real PMD ports of a switch device removes the need to add a new broker framework all together. Each vendor just needs to map additional PMD ports during the probing stage. By adding a switchdev_id we can define these are ports associated to the same switching device, and can allow new port and inter-port actions. [1] http://dpdk.org/dev/patchwork/patch/32550/ [2] https://www.spinics.net/lists/netdev/msg467375.html [2] https://www.systutorials.com/docs/linux/man/8-ip-link/ Alex
Re: [dpdk-dev] [dpdk-stable] [PATCH 1/2] net/mlx5: fix Memory Region registration
Friday, December 15, 2017 3:59 AM, Yongseok Koh:
> Althought granularity of chunks in a mempool is a cacheline, addresses are
> extended to align to page boundary for performance reason in device when
> registering a MR (Memory Region). This could make some regions overlap,
> then can cause Tx completion error due to incorrect LKEY search. If the error
> occurs, the Tx queue will get stuck. To avoid it, end address of a packet
> segment is used in LKEY search.
>
> Fixes: b0b093845793 ("net/mlx5: use buffer address for LKEY search")
> Cc: sta...@dpdk.org
>
> Reported-by: Hanoch Haim
> Signed-off-by: Yongseok Koh
> Acked-by: Nelio Laranjeiro
Series applied to next-net-mlx, thanks.
[dpdk-dev] [PATCH] doc: remove UTF-8 BOM from programmer's guide
Fixes: 55694b2a9f64 ("doc: add membership documentation")
Cc: yipeng1.w...@intel.com
Signed-off-by: Anatoly Burakov
---
doc/guides/prog_guide/member_lib.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/guides/prog_guide/member_lib.rst
b/doc/guides/prog_guide/member_lib.rst
index caca8dc..4e62f76 100644
--- a/doc/guides/prog_guide/member_lib.rst
+++ b/doc/guides/prog_guide/member_lib.rst
@@ -1,4 +1,4 @@
-.. BSD LICENSE
+.. BSD LICENSE
Copyright(c) 2017 Intel Corporation. All rights reserved.
All rights reserved.
--
2.7.4
[dpdk-dev] [PATCH] test: fix uninitialized parameter in table autotest
delete_bulk() copies metadata to pointers provided by the entries
parameter, but in the unit test, they are uninitialized, leading
to rte_table attempting to memcpy into random garbage pointers.
Memsetting pointer table to zero will prevent that from happening.
Fixes: 48f2543cf0a8 ("app/test: add bulk adding and deleting")
Cc: marcinx.ker...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov
---
test/test/test_table_acl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/test/test/test_table_acl.c b/test/test/test_table_acl.c
index 08c100f..6fcf4cc 100644
--- a/test/test/test_table_acl.c
+++ b/test/test/test_table_acl.c
@@ -532,6 +532,8 @@ setup_acl_pipeline(void)
struct rte_pipeline_table_entry *table_entries[5];
int key_found[5];
+ memset(table_entries, 0, sizeof(table_entries));
+
for (n = 0; n < 5; n++) {
memset(&keys[n], 0, sizeof(struct
rte_table_acl_rule_delete_params));
key_array[n] = &keys[n];
--
2.7.4
Re: [dpdk-dev] [PATCH v1 5/6] fix missing includes in exported headers
On Thu, Dec 21, 2017 at 03:50:31PM +0100, Adrien Mazarguil wrote:
> On Thu, Dec 21, 2017 at 02:12:57PM +, Bruce Richardson wrote:
> > On Thu, Dec 21, 2017 at 02:00:04PM +0100, Adrien Mazarguil wrote:
> > > Many exported headers rely on definitions found in rte_config.h without
> > > including it, as shown by the following command:
> > >
> > > grep -L '^#include ' -- \
> > > $(grep -Rl \
> > > $(sed -n '/^#define \([^
> > > ]\+\).*$/{s//\1/;H;};${x;s/\n//;s/\n/\\|/g;p;}' \
> > > build/include/rte_config.h) \
> > > -- build/include/)
> > >
> > > We cannot assume external applications will include rte_config.h on their
> > > own, neither directly nor through a -include parameter like DPDK does
> > > internally.
> > >
> > > This not only causes obvious compilation failures that can be reproduced
> > > with check-includes.sh such as:
> > >
> > > [...]/rte_memory.h:88:43: error: ‘RTE_CACHE_LINE_SIZE’ was not declared
> > > in
> > > this scope
> > > #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE)
> > > ^
> > >
> > > It also results in less visible issues, for instance rte_hash_crc.h
> > > relying
> > > on RTE_ARCH_X86_64's presence to provide dedicated inline functions.
> > >
> > > This patch partially reverts the commit below and adds missing include
> > > lines to the remaining files.
> > >
> > > Fixes: f1a7a5c5f404 ("remove include of generated config header")
> > > Cc: Thomas Monjalon
> > >
> > > Signed-off-by: Adrien Mazarguil
> > > ---
> >
> > Hi Adrien,
> >
> > Just FYI, when we move to the new DPDK build system and pass the
> > necessary build meta-data to the application using pkg-config, this
> > should be a non-issue, as the pkg-config information will include the
> > "-include rte_config.h" parameter.
>
> Right, actually -include rte_config.h is also provided to applications that
> rely on the current DPDK build system, those are already safe.
>
> The motivation behind this patch is other applications that casually
> #include things without even depending on the build features of DPDK (not
> even going through pkg-config manually), in order to meet a safety level
> worthy of /usr/include.
>
> In my opinion it's fine if this usage is not supported and a prior #include
> is required, however in that case we need our header files to
> #error out. Adding #include directly as done in this patch was in fact just
> as easy.
>
> > When investigating that, I also tried this approach of adding rte_config
> > to files explicitly but it did not work for me as expected, as there
> > were cases where the build was depending upon the rte_config.h always
> > being the first include in the file. Normally, the rte_* headers should
> > be last included, so putting it at the top just didn't seem right to me.
> > I don't remember the specifics, but it was something like using the RTE_
> > defines to determine which system header file to use e.g. BSD vs Linux.
> > However, this may be an internal DPDK-build restriction rather than one
> > that would affect user-apps our or examples.
>
> Was it perhaps before we added consistency to all public headers?
>
> check-includes.sh was added a few releases ago to make sure each of them
> could be included on its own, to ensure they properly fetched all their
> dependencies instead of triggering compilation errors.
>
> Rule of thumb being if you need something, #include the file providing it
> first. I find it strange rte_config.h is somehow an exception.
>
> > So, with transitioning to meson and pkg-config, this issue becomes less
> > significant.
>
> Agreed, however I still think something needs to be done, so:
>
> - Do we want to let applications not rely on our build flags yet still use
> our exported headers?
>
> - Is a missing #include supposed to trigger an explicit
> #error for safety?
>
> - How about putting back #include in our exported header
> files directly given the above?
>
> Note this discussion is only about exported headers. The rest remains
> unaffected and can safely continue to rely on -include rte_config.h.
>
Sure, and to be clear I have no objection to having this patch applied.
Having the include on the compiler cmdline as well as having it the file
is fine, so there is no real conflict. As you say, it will make
individual headers more consumable for those not looking to use all of
DPDK.
/Bruce
[dpdk-dev] [PATCH] doc: add instructions on build using meson
Add a document describing how to configure, build and install DPDK using meson and ninja. Document includes references to official installation docs using make, and points out the experimental nature of the build. Signed-off-by: Bruce Richardson --- INSTALL.meson | 177 ++ 1 file changed, 177 insertions(+) create mode 100644 INSTALL.meson diff --git a/INSTALL.meson b/INSTALL.meson new file mode 100644 index 0..f5ded1f7e --- /dev/null +++ b/INSTALL.meson @@ -0,0 +1,177 @@ +INSTALLING DPDK USING THE MESON BUILD SYSTEM +- + +NOTE: Compiling and installing DPDK using ``meson`` and ``ninja``, rather +than using ``make`` (GNU make) is EXPERIMENTAL. Official builds of DPDK +should always be done using ``make``, as described in the ``Getting Started +Guide`` documentation, and at "http://dpdk.org/doc/quick-start";. + +Summary + +For many platforms, compiling and installing DPDK should work using the +following set of commands: + + meson build + cd build + ninja + ninja install + +This will compile DPDK in the ``build`` subdirectory, and then install the +resulting libraries, drivers and header files onto the system - generally +in /usr/local. A package-config file, ``libdpdk.pc``, for DPDK will also +be install to allow ease of compiling and linking with applications. + +After installation, to use DPDK, the necessary CFLAG and LDFLAG variables +can be got from pkg-config. + pkg-config --cflags libdpdk + pkg-config --libs libdpdk + +More detail on each of these steps can be got from the following sections. + + +Getting the Tools +-- + +The ``meson`` tool is used to configure a DPDK build. On most Linux +distributions this can be got using the local package management system, +e.g. ``dnf install meson`` or ``apt-get install meson``. If meson is not +available as a suitable package, it can also be installed using the Python +3 ``pip`` tool, e.g. ``pip3 install meson``. Version 0.42 of meson is +recommended - if the version packaged is too old, the latest version is +generally available from "pip". + +The other dependency for building is the ``ninja`` tool, which acts similar +to make and performs the actual build using information provided by meson. +Installing meson will in many cases also install ninja, but, if not already +installed, it too is generally packaged by most Linux distributions. If not +available as a package, it can be downloaded as source or binary from +https://ninja-build.org/ + + +Configuring the Build +-- + +To configure a build, run the meson tool, passing the path to the directory +to be used for the build e.g. ``meson build``, as shown above. If calling +meson not from with the root directory of the DPDK project the path to the +root directory should be passed as the first parameter, and the build path +as the second. For example, to build DPDK in /tmp/dpdk-build: + + user@host:/tmp$ meson ~user/dpdk dpdk-build + +Meson will then configure the build based on settings in the project's +meson.build files, and by checking the build environment for e.g. compiler +properties or the presence of dependencies, such as libpcap, or openssl +libcrypto libraries. Once done, meson writes a ``build.ninja`` file in the +build directory to be used to do the build itself when ninja is called + +Tuning of the build is possible, both as part of the original meson call, +or subsequently using ``meson configure`` command (``mesonconf`` in some +older versions). Some options, such as ``buildtype``, or ``werror`` are +built into meson, while others, such as ``max_lcores``, or the list of +examples to build, are DPDK-specific. To have a list of all options +available run ``meson configure`` in the build directory. + +Examples of adjusting the defaults when doing initial meson configuration. +Project-specific options are passed used -Doption=value. + + meson --werror werrorbuild # build with warnings as errors + + meson --buildtype=debug debugbuild # build for debugging + + meson -Dexamples=l3fwd,l2fwd fwdbuild # build some examples as + # part of the normal DPDK build + + meson -Dmax_lcores=8 smallbuild # scale build for smaller systems + +Examples of setting the same options using meson configure + + meson configure -Dwerror=true + + meson configure -Dbuildtype=debug + + meson configure -Dexamples=l3fwd,l2fwd + + meson configure -Dmax_lcores=8 + +NOTE: once meson has been run to configure a build in a directory, it +cannot be run again on the same directory. Instead ``meson configure`` +should be used to change the build settings within the directory, and when +``ninja`` is called to do the build itself, it will trigger the necessary +re-scan from meson. + +As well as those settings taken from ``meson configure``, other options +s
Re: [dpdk-dev] [PATCH v1 2/3] net/hyperv: implement core functionality
Disclaimer: I agree with Thomas's suggestions in his reply [1] to your
message, I'm replying below as well to provide more details of my own and
clarify the motivations behind this approach a bit more.
On Tue, Dec 19, 2017 at 12:44:35PM -0800, Ferruh Yigit wrote:
> On 12/19/2017 7:06 AM, Adrien Mazarguil wrote:
> > On Mon, Dec 18, 2017 at 05:54:45PM -0800, Ferruh Yigit wrote:
> >> On 12/18/2017 8:46 AM, Adrien Mazarguil wrote:
> >>> As described in more details in the attached documentation (see patch
> >>> contents), this virtual device driver manages NetVSC interfaces in virtual
> >>> machines hosted by Hyper-V/Azure platforms.
> >>>
> >>> This driver does not manage traffic nor Ethernet devices directly; it acts
> >>> as a thin configuration layer that automatically instantiates and controls
> >>> fail-safe PMD instances combining tap and PCI sub-devices, so that each
> >>> NetVSC interface is exposed as a single consolidated port to DPDK
> >>> applications.
> >>>
> >>> PCI sub-devices being hot-pluggable (e.g. during VM migration),
> >>> applications automatically benefit from increased throughput when present
> >>> and automatic fallback on NetVSC otherwise without interruption thanks to
> >>> fail-safe's hot-plug handling.
> >>>
> >>> Once initialized, the sole job of the hyperv driver is to regularly scan
> >>> for PCI devices to associate with NetVSC interfaces and feed their
> >>> addresses to corresponding fail-safe instances.
> >>>
> >>> Signed-off-by: Adrien Mazarguil
> >>
> >> <...>
> >>
> >>> + RTE_ETH_FOREACH_DEV(port_id) {
> >> <..>
> >>> + ret = rte_eal_hotplug_remove(bus->name, dev->name);
> >> <..>
> >>> + ret = rte_eal_hotplug_add("vdev", ctx->devname, ctx->devargs);
> >>
> >> Overall why this logic implemented as network PMD?
> >> Yes technically you can implement *anything* as PMD :), but should we?
> >>
> >> This code does eal level work (scans bus, add/remove devices), and for
> >> control
> >> path, and not a generic solution either (specific to netvsc and failsafe).
> >>
> >> Only device argument part of a PMD seems used, rest is unrelated to being
> >> a PMD.
> >> Scans netvsc changes in background and reflects them into failsafe PMD...
> >>
> >> Why this is implemented as PMD, not another entity, like bus driver
> >> perhaps?
> >>
> >> Or indeed why this in DPDK instead of being in application?
> >
> > I'll address that last question first: the point of this driver is enabling
> > existing applications to run within a Hyper-V environment unmodified,
> > because they'd otherwise need to manage two driver instances correctly on
> > their own in addition to hot-plug events during VM migration.
> >
> > Some kind of driver generating a front end to what otherwise appears as two
> > distinct ethdev to applications is therefore necessary.
> >
> > Currently without it, users have to manually configure failsafe properly for
> > each NetVSC interface on their system. Besides the inconvenience, it's not
> > even a possibility with DPDK applications that don't rely on EAL
> > command-line arguments.
> >
> > As such it's more correctly defined as a "platform" driver rather than a
> > true PMD. It leaves VF device handling to their respective PMDs while
> > automatically managing the platform-specific part itself. There's no simpler
> > alternative when running in blacklist mode (i.e. not specifying any device
> > parameters on the command line).
> >
> > Regarding its presence in drivers/net rather than drivers/bus, the end
> > result from an application standpoint is that each instance exposes a single
> > ethdev, even if not its own (failsafe's). Busses don't do that. It also
> > allows passing arguments to individual devices through --vdev if needed.
> >
> > You're right about putting device detection at the bus level though, and I
> > think there's work in progress to do just that, this driver will be updated
> > to benefit from it once applied. In the meantime, the code as submitted
> > works fine with the current DPDK code base and addresses an existing use
> > case for which there is no solution at this point.
>
> This may be working but this looks like a hack to me.
>
> If we need a platform driver why not properly work on it. If we need to
> improve
> eal hotplug, this is a good motivation to improve it.
Hotplug surely can be improved but I don't think that alone will be enough
for what this driver does. Here's how things are sequenced as currently
implemented:
1. DPDK application starts.
2. EAL scans for PCI devices, ethdev ports are created for relevant ones.
3. hyperv vdev scans the system for appropriate NetVSC netdevices,
instantiates failsafe PMD accordingly to create ethdev ports for each of
them.
At this stage, rte_eal_hotplug_remove() is also called on physical
devices found in 2. that will be given to failsafe (see 4.), since
they're not supposed to be seen or owned by the application (keep in mind
this happens on Hyper-V
Re: [dpdk-dev] [PATCH] doc: add i40e update in release note
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jingjing Wu > Sent: Thursday, December 21, 2017 2:04 PM > To: dev@dpdk.org > Cc: Zhang, Helin ; Xing, Beilei > > Subject: [dpdk-dev] [PATCH] doc: add i40e update in release note > > From: Beilei Xing > > Updates 17.11 release note to declare GTPU/GTPC support in i40e driver. > > Signed-off-by: Beilei Xing > --- > doc/guides/rel_notes/release_17_11.rst | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/doc/guides/rel_notes/release_17_11.rst > b/doc/guides/rel_notes/release_17_11.rst > index 016a08c..d2df7cf 100644 > --- a/doc/guides/rel_notes/release_17_11.rst > +++ b/doc/guides/rel_notes/release_17_11.rst > @@ -273,6 +273,16 @@ New Features >applications to classify an input packet by matching it against a set > of >flow rules. It uses the ``librte_table`` API to manage the flow rules. > > +* **Updated i40e driver to support GTPC/GTPU.** > + > + Updated i40e PMD to support GTPC/GTPU with GTPC/GTPU supporting > + profiles which can be programed by dynamic device personalization > + (DDP) > + process: > + > + * Support RSS of GTPC/GTPU flow. > + * Support flow director of GTPC/GTPU flow base on TEID. > + * Support cloud filer of GTPC/GTPU flow base on TEID. > + There is a small typo: s/programed/programmed/ Apart from that: Acked-by: John McNamara
[dpdk-dev] [PATCH] vhost: introduce rte_vhost_vring_call()
Users of librte_vhost currently implement the vring call operation
themselves. Each caller performs the operation slightly differently.
This patch introduces a new librte_vhost API called
rte_vhost_vring_call() that performs the operation so that vhost-user
applications don't have to duplicate it.
Signed-off-by: Stefan Hajnoczi
---
lib/librte_vhost/rte_vhost.h | 15 +++
examples/vhost/virtio_net.c| 11 ++-
examples/vhost_scsi/vhost_scsi.c | 6 +++---
lib/librte_vhost/vhost.c | 27 +++
lib/librte_vhost/virtio_net.c | 29 ++---
lib/librte_vhost/rte_vhost_version.map | 7 +++
6 files changed, 60 insertions(+), 35 deletions(-)
diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h
index fe5c94c69..dde0eeb03 100644
--- a/lib/librte_vhost/rte_vhost.h
+++ b/lib/librte_vhost/rte_vhost.h
@@ -85,7 +85,9 @@ struct rte_vhost_vring {
struct vring_used *used;
uint64_tlog_guest_addr;
+ /** Deprecated, use rte_vhost_vring_call() instead. */
int callfd;
+
int kickfd;
uint16_tsize;
};
@@ -435,6 +437,19 @@ int rte_vhost_get_mem_table(int vid, struct
rte_vhost_memory **mem);
int rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
struct rte_vhost_vring *vring);
+/**
+ * Notify the guest that used descriptors have been added to the vring. This
+ * function acts as a memory barrier.
+ *
+ * @param vid
+ * vhost device ID
+ * @param vring_idx
+ * vring index
+ * @return
+ * 0 on success, -1 on failure
+ */
+int rte_vhost_vring_call(int vid, uint16_t vring_idx);
+
/**
* Get vhost RX queue avail count.
*
diff --git a/examples/vhost/virtio_net.c b/examples/vhost/virtio_net.c
index 1ab57f526..252c5b8ce 100644
--- a/examples/vhost/virtio_net.c
+++ b/examples/vhost/virtio_net.c
@@ -207,13 +207,8 @@ vs_enqueue_pkts(struct vhost_dev *dev, uint16_t queue_id,
*(volatile uint16_t *)&vr->used->idx += count;
queue->last_used_idx += count;
- /* flush used->idx update before we read avail->flags. */
- rte_mb();
+ rte_vhost_vring_call(dev->vid, queue_id);
- /* Kick the guest if necessary. */
- if (!(vr->avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
- && (vr->callfd >= 0))
- eventfd_write(vr->callfd, (eventfd_t)1);
return count;
}
@@ -396,9 +391,7 @@ vs_dequeue_pkts(struct vhost_dev *dev, uint16_t queue_id,
vr->used->idx += i;
- if (!(vr->avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
- && (vr->callfd >= 0))
- eventfd_write(vr->callfd, (eventfd_t)1);
+ rte_vhost_vring_call(dev->vid, queue_id);
return i;
}
diff --git a/examples/vhost_scsi/vhost_scsi.c b/examples/vhost_scsi/vhost_scsi.c
index b4f1f8d27..e30e61f6d 100644
--- a/examples/vhost_scsi/vhost_scsi.c
+++ b/examples/vhost_scsi/vhost_scsi.c
@@ -110,7 +110,7 @@ descriptor_is_wr(struct vring_desc *cur_desc)
}
static void
-submit_completion(struct vhost_scsi_task *task)
+submit_completion(struct vhost_scsi_task *task, uint32_t q_idx)
{
struct rte_vhost_vring *vq;
struct vring_used *used;
@@ -131,7 +131,7 @@ submit_completion(struct vhost_scsi_task *task)
/* Send an interrupt back to the guest VM so that it knows
* a completion is ready to be processed.
*/
- eventfd_write(vq->callfd, (eventfd_t)1);
+ rte_vhost_vring_call(task->bdev->vid, q_idx);
}
static void
@@ -263,7 +263,7 @@ process_requestq(struct vhost_scsi_ctrlr *ctrlr, uint32_t
q_idx)
task->resp->status = 0;
task->resp->resid = 0;
}
- submit_completion(task);
+ submit_completion(task, q_idx);
rte_free(task);
}
}
diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
index 4f8b73a09..0d269f12a 100644
--- a/lib/librte_vhost/vhost.c
+++ b/lib/librte_vhost/vhost.c
@@ -519,6 +519,33 @@ rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
return 0;
}
+int
+rte_vhost_vring_call(int vid, uint16_t vring_idx)
+{
+ struct virtio_net *dev;
+ struct vhost_virtqueue *vq;
+
+ dev = get_device(vid);
+ if (!dev)
+ return -1;
+
+ if (vring_idx >= VHOST_MAX_VRING)
+ return -1;
+
+ vq = dev->virtqueue[vring_idx];
+ if (!vq)
+ return -1;
+
+ /* flush used->idx update before we read avail->flags. */
+ rte_mb();
+
+ /* Kick the guest if necessary. */
+ if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
+ && (vq->callfd >= 0))
+ eventfd_write(vq->callfd, (eventfd_t)1);
+ return 0;
+}
+
uint16_t
rte_vhost_avail_entries(int vid, uint16_t
[dpdk-dev] [PATCH] eal/x86: move header to standard BSD license
This updates the license on the rte_rtm.h file to be the standard BSD-3-Clause license used for the rest of DPDK, thus bringing the file in compliance with the DPDK licensing policy. Signed-off-by: Bruce Richardson CC: Roman Dementiev CC: Andi Kleen --- lib/librte_eal/common/include/arch/x86/rte_rtm.h | 19 --- 1 file changed, 4 insertions(+), 15 deletions(-) diff --git a/lib/librte_eal/common/include/arch/x86/rte_rtm.h b/lib/librte_eal/common/include/arch/x86/rte_rtm.h index ab0999521..eb0f8e81e 100644 --- a/lib/librte_eal/common/include/arch/x86/rte_rtm.h +++ b/lib/librte_eal/common/include/arch/x86/rte_rtm.h @@ -1,21 +1,10 @@ +/* SPDX-License-Identifier: BSD-3-Clause + * Copyright(c) 2012,2013 Intel Corporation + */ + #ifndef _RTE_RTM_H_ #define _RTE_RTM_H_ 1 -/* - * Copyright (c) 2012,2013 Intel Corporation - * Author: Andi Kleen - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that: (1) source code distributions - * retain the above copyright notice and this paragraph in its entirety, (2) - * distributions including binary code include the above copyright notice and - * this paragraph in its entirety in the documentation or other materials - * provided with the distribution - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. - */ /* Official RTM intrinsics interface matching gcc/icc, but works on older gcc compatible compilers and binutils. */ -- 2.14.3
[dpdk-dev] [PATCH] eal: fix end for bounded malloc elements
In cases when alignment is bigger than boundary, we may incorrectly
calculate end of a bounded malloc element.
Consider this: suppose we are allocating a bounded malloc element
that should be of 128 bytes in size, bounded to 128 bytes and
aligned on a 256-byte boundary. Suppose our malloc element ends
at 0x140 - that is, 256 plus one cacheline.
So, right at the start, we are aligning our new_data_start to
include the required element size, and to be aligned on a specified
boundary - so new_data_start becomes 0. This fails the following
bounds check, because our element cannot go above 128 bytes from
the start, and we are at 320. So, we enter the bounds handling
branch.
While we're in there, we are aligning end_pt to our boundedness
requirement of 128 byte, and end up with 0x100 (since 256 is
128-byte aligned). We recalculate new_data_size and it stays at
0, however our end is at 0x100, which is beyond the 128 byte
boundary, and we report inability to reserve a bounded element
when we could have.
This patch adds an end_pt recalculation after new_data_start
adjustment - we already know that size <= bound, so we can do it
safely - and we then correctly report that we can, in fact, try
using this element for bounded malloc allocation.
Fixes: fafcc11985a2 ("mem: rework memzone to be allocated by malloc")
Cc: sergio.gonzalez.mon...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/common/malloc_elem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_eal/common/malloc_elem.c
b/lib/librte_eal/common/malloc_elem.c
index 98bcd37..f6cbc42 100644
--- a/lib/librte_eal/common/malloc_elem.c
+++ b/lib/librte_eal/common/malloc_elem.c
@@ -98,6 +98,7 @@ elem_start_pt(struct malloc_elem *elem, size_t size, unsigned
align,
if ((new_data_start & bmask) != ((end_pt - 1) & bmask)) {
end_pt = RTE_ALIGN_FLOOR(end_pt, bound);
new_data_start = RTE_ALIGN_FLOOR((end_pt - size), align);
+ end_pt = new_data_start + size;
if (((end_pt - 1) & bmask) != (new_data_start & bmask))
return NULL;
}
--
2.7.4
Re: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership
08/12/2017 13:31, Neil Horman: > On Fri, Dec 08, 2017 at 12:35:18PM +0100, Thomas Monjalon wrote: > > 05/12/2017 11:05, Bruce Richardson: > > > > I think you suggest to make all the ethdev configuration race safe, it > > > > is behind to this thread. Current ethdev implementation leave the > > > > race management to applications, so port ownership as any other port > > > > configurations should be designed in the same method. > > > > > > One key difference, though, being that port ownership itself could be > > > used to manage the thread-safety of the ethdev configuration. It's also > > > a little different from other APIs in that I find it hard to come up > > > with a scenario where it would be very useful to an application without > > > also having some form of locking present in it. For other config/control > > > APIs we can have the control plane APIs work without locks e.g. by > > > having a single designated thread/process manage all configuration > > > updates. However, as Neil points out, in such a scenario, the ownership > > > concept doesn't provide any additional benefit so can be skipped > > > completely. I'd view it a bit like the reference counting of mbufs - > > > we can provide a lockless/non-atomic version, but for just about every > > > real use-case, you want the atomic version. > > > > I think we need to clearly describe what is the tread-safety policy > > in DPDK (especially in ethdev as a first example). > > Let's start with obvious things: > > > > 1/ A queue is not protected for races with multiple Rx or Tx > > - no planned change because of performance purpose > > 2/ The list of devices is racy > > - to be fixed with atomics > > 3/ The configuration of different devices is thread-safe > > - the configurations are different per-device > > 4/ The configuration of a given device is racy > > - can be managed by the owner of the device > > 5/ The device ownership is racy > > - to be fixed with atomics > > > > What am I missing? > > > There is fan out to consider here: > > 1) Is device configuration racy with ownership? That is to say, can I change > ownership of a device safely while another thread that currently owns it > modifies its configuration? If an entity steals ownership to another one, either it is agreed earlier, or it is done by a central authority. When it is acked that ownership can be moved, there should not be any configuration in progress. So it is more a communication issue than a race. > 2) Is device configuration racy with device addition/removal? That is to say, > can one thread remove a device while another configures it. I think it is the same as two threads configuring the same device (item 4/ above). It can be managed with port ownership. > There are probably many subsystem interactions that need to be addressed here. > > Neil > > > I am also wondering whether the device ownership can be a separate > > library used in several device class interfaces?
[dpdk-dev] [RFC v3 PATCH 0/8] event: eventdev OPDL PMD
The OPDL (Ordered Packet Distribution Library) eventdev is a specific implementation of the eventdev API. It is particularly suited to packet processing workloads that have high throughput and low latency requirements. All packets follow the same path through the device. The order which packets follow is determinted by the order in which queues are set up. Packets are left on the ring until they are transmitted. As a result packets do not go out of order. Features: The OPDL eventdev implements a subset of features of the eventdev API; Queues * Atomic * Ordered (Parallel is supported as parallel is a subset of Ordered) * Single-Link Ports * Load balanced (for Atomic, Ordered, Parallel queues) * Single Link (for single-link queues) Single Port Queue It is possible to create a Single Port Queue RTE_EVENT_QUEUE_CFG_SINGLE_LINK. Packets dequeued from this queue do not need to be re-enqueued (as is the case with an ordered queue). The purpose of this queue is to allow for asynchronous handling of packets in the middle of a pipeline. Ordered queues in the middle of a pipeline cannot delete packets. Queue Dependencies As stated the order in which packets travel through queues is static in nature. They go through the queues in the order the queues are setup at initialisation rte_event_queue_setup(). For example if an application sets up 3 queues, Q0, Q1, Q2 and has 3 assoicated ports P0, P1, P2 and P3 then packets must be * Enqueued onto Q0 (typically through P0), then * Dequeued from Q0 (typically through P1), then * Enqueued onto Q1 (also through P1), then * Dequeued from Q2 (typically through P2), then * Enqueued onto Q3 (also through P2), then * Dequeued from Q3 (typically through P3) and then transmitted on the relevant eth port Limitations The opdl implementation has a number of limitations. These limitations are due to the static nature of the underlying queues. It is because of this that the implementation can achieve such high throughput and low latency The following list is a comprehensive outline of the what is supported and the limitations / restrictions imposed by the opdl pmd - The order in which packets moved between queues is static and fixed (dynamic scheduling is not supported). - NEW, RELEASE op type are not explicitly supported. RX (first enqueue) implicitly adds NEW event types, and TX (last dequeue) implicitly does RELEASE event types. - All packets follow the same path through device queues. - Flows within queues are NOT supported. - Event priority is NOT supported. - Once the device is stopped all inflight events are lost. Applications should clear all inflight events before stopping it. - Each port can only be associated with one queue. - Each queue can have multiple ports associated with it. - Each worker core has to dequeue the maximum burst size for that port. Reference General concept of event driven programming model [http://dpdk.org/doc/guides/eventdevs/index.html] Original Ordered Pipeline Design slides [https://dpdksummit.com/Archive/pdf/2017Asia/DPDK-China2017-Ma-OPDL.pdf] ChangeLoga [v3] 1. add dynamic log support. 2. update maintainer, release notes. 3. fix issues with review comments. [v2] 1. merge the opdl eventdev unit test code into opdl pmd. 2. propose three new capability capability flags for overall eventdev. 3. remove the opdl pmd example code. 4. remove the opdl pmd example doc. Liang Ma (8): event/opdl: add the opdl ring infrastructure library event/opdl: add the opdl pmd main body and helper function eventdev/opdl: opdl eventdev pmd unit test function lib/librte_eventdev: extend the eventdev capability flags event/*: apply the three new capability flags for sw/dppa2/octeontx maintainers: add the opdl pmd maintainer information doc:update 18.02 release notes doc: add eventdev opdl pmd docuement MAINTAINERS |6 + config/common_base|6 + doc/guides/eventdevs/index.rst|1 + doc/guides/eventdevs/opdl.rst | 162 +++ doc/guides/rel_notes/release_18_02.rst| 11 + drivers/event/Makefile|1 + drivers/event/dpaa2/dpaa2_eventdev.c |6 +- drivers/event/octeontx/ssovf_evdev.c |6 +- drivers/event/opdl/Makefile | 66 ++ drivers/event/opdl/opdl_evdev.c | 794 + drivers/event/opdl/opdl_evdev.h | 342 ++ drivers/event/opdl/opdl_evdev_init.c | 963 drivers/event/opdl/opdl_evdev_xstats.c| 205 drivers/event/opdl/opdl_log.h | 59 + drivers/event/opdl/opdl_ring.c| 1250 + drivers/event/opdl/opdl_ring.h| 628 +++ drivers/event/opdl/opdl_test.c|
[dpdk-dev] [PATCH v3 1/8] event/opdl: add the opdl ring infrastructure library
OPDL ring is the core infrastructure of OPDL PMD. OPDL ring library provide the core data structure and core helper function set. The Ring implements a single ring multi-port/stage pipelined packet distribution mechanism. This mechanism has the following characteristics: • No multiple queue cost, therefore, latency is significant reduced. • Fixed dependencies between queue/ports is more suitable for complex. fixed pipelines of stateless packet processing (static pipeline). • Has decentralized distribution (no scheduling core). • Packets remain in order (no reorder core(s)). * Update build system to enable compilation. Signed-off-by: Liang Ma Signed-off-by: Peter Mccarthy --- config/common_base|6 + drivers/event/Makefile|1 + drivers/event/opdl/Makefile | 62 + drivers/event/opdl/opdl_log.h | 59 + drivers/event/opdl/opdl_ring.c| 1250 + drivers/event/opdl/opdl_ring.h| 628 +++ drivers/event/opdl/rte_pmd_evdev_opdl_version.map |3 + mk/rte.app.mk |1 + mk/toolchain/gcc/rte.toolchain-compat.mk |6 + mk/toolchain/icc/rte.toolchain-compat.mk |6 + 10 files changed, 2022 insertions(+) create mode 100644 drivers/event/opdl/Makefile create mode 100644 drivers/event/opdl/opdl_log.h create mode 100644 drivers/event/opdl/opdl_ring.c create mode 100644 drivers/event/opdl/opdl_ring.h create mode 100644 drivers/event/opdl/rte_pmd_evdev_opdl_version.map diff --git a/config/common_base b/config/common_base index e74febe..67adaba 100644 --- a/config/common_base +++ b/config/common_base @@ -594,6 +594,12 @@ CONFIG_RTE_LIBRTE_PMD_OCTEONTX_SSOVF=y CONFIG_RTE_LIBRTE_PMD_OCTEONTX_SSOVF_DEBUG=n # +# Compile PMD for OPDL event device +# +CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV=y +CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV_DEBUG=n + +# # Compile librte_ring # CONFIG_RTE_LIBRTE_RING=y diff --git a/drivers/event/Makefile b/drivers/event/Makefile index 1f9c0ba..d62 100644 --- a/drivers/event/Makefile +++ b/drivers/event/Makefile @@ -35,5 +35,6 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_SKELETON_EVENTDEV) += skeleton DIRS-$(CONFIG_RTE_LIBRTE_PMD_SW_EVENTDEV) += sw DIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_SSOVF) += octeontx DIRS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_EVENTDEV) += dpaa2 +DIRS-$(CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV) += opdl include $(RTE_SDK)/mk/rte.subdir.mk diff --git a/drivers/event/opdl/Makefile b/drivers/event/opdl/Makefile new file mode 100644 index 000..8277e25 --- /dev/null +++ b/drivers/event/opdl/Makefile @@ -0,0 +1,62 @@ +# BSD LICENSE +# +# Copyright(c) 2016-2017 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_opdl_event.a + +# build flags +CFLAGS += -O3 +CFLAGS += $(WERROR_FLAGS) +# for older GCC versions, allow us to initialize an event using +# designated initializers. +ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y) +ifeq ($(shell test $(GCC_VERSION) -le 50 && echo 1), 1) +CFLAGS += -Wno-missing-field-initializers +endif +endif + +LDLIBS += -lrte_eal -lrte_eventdev -lrte_kvargs +LDLIBS += -lrte_bus_vdev -lrte_mbuf -lrte_mempool + +# library version +LIBABIVER := 1 + +# versioning export map +EXPORT_MAP := rte_pmd_evdev_opdl_version.map + +# library source fil
[dpdk-dev] [PATCH v3 3/8] eventdev/opdl: opdl eventdev pmd unit test function
This commit adds unit test inside the OPDL PMD. There is a PMd parameter
"self_test" can be used to triger the test when vdev bus probe opdl device
e.g.
sudo ./app/test --vdev="event_opdl0,self_test=1"
Signed-off-by: Liang Ma
Signed-off-by: Peter Mccarthy
---
drivers/event/opdl/Makefile |1 +
drivers/event/opdl/opdl_evdev.c |3 +
drivers/event/opdl/opdl_evdev.h |1 +
drivers/event/opdl/opdl_test.c | 1079 +++
4 files changed, 1084 insertions(+)
create mode 100644 drivers/event/opdl/opdl_test.c
diff --git a/drivers/event/opdl/Makefile b/drivers/event/opdl/Makefile
index 473a09c..62c9e1f 100644
--- a/drivers/event/opdl/Makefile
+++ b/drivers/event/opdl/Makefile
@@ -58,6 +58,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV) += opdl_ring.c
SRCS-$(CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV) += opdl_evdev.c
SRCS-$(CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV) += opdl_evdev_init.c
SRCS-$(CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV) += opdl_evdev_xstats.c
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV) += opdl_test.c
# export include files
SYMLINK-y-include +=
diff --git a/drivers/event/opdl/opdl_evdev.c b/drivers/event/opdl/opdl_evdev.c
index f51a174..fca1dc9 100644
--- a/drivers/event/opdl/opdl_evdev.c
+++ b/drivers/event/opdl/opdl_evdev.c
@@ -753,6 +753,9 @@ opdl_probe(struct rte_vdev_device *vdev)
str_len = strlen(name);
memcpy(opdl->service_name, name, str_len);
+ if (do_test == 1)
+ test_result = opdl_selftest();
+
return test_result;
}
diff --git a/drivers/event/opdl/opdl_evdev.h b/drivers/event/opdl/opdl_evdev.h
index 33bc8f2..7849af1 100644
--- a/drivers/event/opdl/opdl_evdev.h
+++ b/drivers/event/opdl/opdl_evdev.h
@@ -337,5 +337,6 @@ int initialise_all_other_ports(struct rte_eventdev *dev);
int initialise_queue_zero_ports(struct rte_eventdev *dev);
int assign_internal_queue_ids(struct rte_eventdev *dev);
void destroy_queues_and_rings(struct rte_eventdev *dev);
+int opdl_selftest(void);
#endif /* _OPDL_EVDEV_H_ */
diff --git a/drivers/event/opdl/opdl_test.c b/drivers/event/opdl/opdl_test.c
new file mode 100644
index 000..4e58b10
--- /dev/null
+++ b/drivers/event/opdl/opdl_test.c
@@ -0,0 +1,1079 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016-2017 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
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "opdl_evdev.h"
+#include "opdl_log.h"
+
+
+#define MAX_PORTS 16
+#define MAX_QIDS 16
+#define NUM_PACKETS (1<<18)
+#define NUM_EVENTS 256
+#define BURST_SIZE 32
+
+
+
+static int evdev;
+
+struct test {
+ struct rte_mempool *mbuf_pool;
+ uint8_t port[MAX_PORTS];
+ uint8_t qid[MAX_QIDS];
+ int nb_qids;
+};
+
+static struct rte_mempool *eventdev_func_mempool;
+
+static __rte_always_inline struct rte_mbuf *
+rte_gen_arp(int portid, struct rte_mempool *mp)
+{
+ /*
+* len = 14 + 46
+* ARP, Request who-has 10.0.0.1 tell 10.0.0.2, length 46
+*/
+ static const uint8_t arp_request[] = {
+ /*0x:*/ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xec, 0xa8,
+ 0x6b, 0xfd, 0x02, 0x29, 0x08, 0x06, 0x00, 0x01,
+ /*0x0010:*/ 0x08, 0
[dpdk-dev] [PATCH v3 2/8] event/opdl: add the opdl pmd main body and helper function
This commit adds a OPDL implementation of the eventdev API. The
implementation here is intended to enable the community to use
the OPDL infrastructure under eventdev API.
The main components of the implementation is three files:
- opdl_evdev.c Creation, configuration, etc
- opdl_evdev_xstats.c helper function to support stats collection
- opdl_evdev.h include the main data structure of opdl
device and all the function prototype
need to be exposed to support eventdev API.
- opdl_evdev_init.c implement all initailization helper function
This commit only adds the implementation, no existing DPDK files
are modified.
Signed-off-by: Liang Ma
Signed-off-by: Peter Mccarthy
---
drivers/event/opdl/Makefile| 3 +
drivers/event/opdl/opdl_evdev.c| 791 +++
drivers/event/opdl/opdl_evdev.h| 341
drivers/event/opdl/opdl_evdev_init.c | 963 +
drivers/event/opdl/opdl_evdev_xstats.c | 205 +++
5 files changed, 2303 insertions(+)
create mode 100644 drivers/event/opdl/opdl_evdev.c
create mode 100644 drivers/event/opdl/opdl_evdev.h
create mode 100644 drivers/event/opdl/opdl_evdev_init.c
create mode 100644 drivers/event/opdl/opdl_evdev_xstats.c
diff --git a/drivers/event/opdl/Makefile b/drivers/event/opdl/Makefile
index 8277e25..473a09c 100644
--- a/drivers/event/opdl/Makefile
+++ b/drivers/event/opdl/Makefile
@@ -55,6 +55,9 @@ EXPORT_MAP := rte_pmd_evdev_opdl_version.map
# library source files
SRCS-$(CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV) += opdl_ring.c
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV) += opdl_evdev.c
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV) += opdl_evdev_init.c
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV) += opdl_evdev_xstats.c
# export include files
SYMLINK-y-include +=
diff --git a/drivers/event/opdl/opdl_evdev.c b/drivers/event/opdl/opdl_evdev.c
new file mode 100644
index 000..f51a174
--- /dev/null
+++ b/drivers/event/opdl/opdl_evdev.c
@@ -0,0 +1,791 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016-2017 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
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "opdl_evdev.h"
+#include "opdl_ring.h"
+#include "opdl_log.h"
+
+#define EVENTDEV_NAME_OPDL_PMD event_opdl
+#define NUMA_NODE_ARG "numa_node"
+#define DO_VALIDATION_ARG "do_validation"
+#define DO_TEST_ARG "self_test"
+
+
+uint16_t
+opdl_event_enqueue_burst(void *port,
+const struct rte_event ev[],
+uint16_t num)
+{
+ struct opdl_port *p = port;
+
+ if (unlikely(!p->opdl->data->dev_started))
+ return 0;
+
+
+ /* either rx_enqueue or disclaim*/
+ return p->enq(p, ev, num);
+}
+
+uint16_t
+opdl_event_enqueue(void *port, const struct rte_event *ev)
+{
+ struct opdl_port *p = port;
+
+ if (unlikely(!p->opdl->data->dev_started))
+ return 0;
+
+
+ return p->enq(p, ev, 1);
+}
+
+uint16_t
+opdl_event_dequeue_burst(void *port,
+struct rte_event *ev,
+uint16_t num,
+uint64_t wait)
+{
+ struct opdl_port *p = (void *)port;
+
+ RTE_SET_USED(wait);
+
+ if (unlikely(!p->op
[dpdk-dev] [PATCH v3 4/8] lib/librte_eventdev: extend the eventdev capability flags
this commitd add three new eventdev capability flags RTE_EVENT_DEV_CAP_NONSEQ_MODE Event device is capable of operating in none sequential mode. The path of the event is not necessary to be sequential. Application can change the path of event at runtime.if the flag is not set, then event each event will follow a path from queue 0 to queue 1 to queue 2 etc. If the flag is set, events may be sent to queues in any order.If the flag is not set, the eventdev will return an error when the application enqueues an event for a qid which is not the next in the sequence. RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK Event device is capable of configuring the queue/port link at runtime. if the flag is not set, the eventdev queue/port linkis only can be configured during initialization. RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT Event device is capable of setting up the link between multiple queue with single port. if the flag is not set, the eventdev can only map a single queue to each port or map a signle queue to many port. Signed-off-by: Liang Ma Signed-off-by: Peter Mccarthy --- lib/librte_eventdev/rte_eventdev.h | 22 ++ 1 file changed, 22 insertions(+) diff --git a/lib/librte_eventdev/rte_eventdev.h b/lib/librte_eventdev/rte_eventdev.h index 1bbea57..91fd4ef 100644 --- a/lib/librte_eventdev/rte_eventdev.h +++ b/lib/librte_eventdev/rte_eventdev.h @@ -293,6 +293,28 @@ struct rte_mbuf; /* we just use mbuf pointers; no need to include rte_mbuf.h */ * @see rte_event_dequeue_burst() rte_event_enqueue_burst() */ +#define RTE_EVENT_DEV_CAP_NONSEQ_MODE (1ULL << 6) +/**< Event device is capable of operating in none sequential mode. The path + * of the event is not necessary to be sequential. Application can change + * the path of event at runtime.if the flag is not set, then event each event + * will follow a path from queue 0 to queue 1 to queue 2 etc. If the flag is + * set, events may be sent to queues in any order.If the flag is not set, the + * eventdev will return an error when the application enqueues an event for a + * qid which is not the next in the sequence. + */ + +#define RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK (1ULL << 7) +/**< Event device is capable of configuring the queue/port link at runtime. + * if the flag is not set, the eventdev queue/port link is only can be + * configured during initialization. + */ + +#define RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT (1ULL << 8) +/**< Event device is capable of setting up the link between multiple queue + * with single port. if the flag is not set, the eventdev can only map a + * single queue to each port or map a signle queue to many port. + */ + /* Event device priority levels */ #define RTE_EVENT_DEV_PRIORITY_HIGHEST 0 /**< Highest priority expressed across eventdev subsystem -- 2.7.5 -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
[dpdk-dev] [PATCH v3 5/8] event/*: apply the three new capability flags for sw/dppa2/octeontx
Signed-off-by: Liang Ma Signed-off-by: Peter Mccarthy --- drivers/event/dpaa2/dpaa2_eventdev.c | 6 +- drivers/event/octeontx/ssovf_evdev.c | 6 +- drivers/event/sw/sw_evdev.c | 5 - 3 files changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/event/dpaa2/dpaa2_eventdev.c b/drivers/event/dpaa2/dpaa2_eventdev.c index 13e7122..e437edc 100644 --- a/drivers/event/dpaa2/dpaa2_eventdev.c +++ b/drivers/event/dpaa2/dpaa2_eventdev.c @@ -333,7 +333,11 @@ dpaa2_eventdev_info_get(struct rte_eventdev *dev, DPAA2_EVENT_MAX_PORT_ENQUEUE_DEPTH; dev_info->max_num_events = DPAA2_EVENT_MAX_NUM_EVENTS; dev_info->event_dev_cap = RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED | - RTE_EVENT_DEV_CAP_BURST_MODE; + RTE_EVENT_DEV_CAP_BURST_MODE| + RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK | + RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT | + RTE_EVENT_DEV_CAP_NONSEQ_MODE; + } static int diff --git a/drivers/event/octeontx/ssovf_evdev.c b/drivers/event/octeontx/ssovf_evdev.c index b80a6c0..d85b4fb 100644 --- a/drivers/event/octeontx/ssovf_evdev.c +++ b/drivers/event/octeontx/ssovf_evdev.c @@ -187,7 +187,11 @@ ssovf_info_get(struct rte_eventdev *dev, struct rte_event_dev_info *dev_info) dev_info->max_num_events = edev->max_num_events; dev_info->event_dev_cap = RTE_EVENT_DEV_CAP_QUEUE_QOS | RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED | - RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES; + RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES| + RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK | + RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT | + RTE_EVENT_DEV_CAP_NONSEQ_MODE; + } static int diff --git a/drivers/event/sw/sw_evdev.c b/drivers/event/sw/sw_evdev.c index 1ef6340..aed521b 100644 --- a/drivers/event/sw/sw_evdev.c +++ b/drivers/event/sw/sw_evdev.c @@ -488,7 +488,10 @@ sw_info_get(struct rte_eventdev *dev, struct rte_event_dev_info *info) RTE_EVENT_DEV_CAP_QUEUE_QOS | RTE_EVENT_DEV_CAP_BURST_MODE | RTE_EVENT_DEV_CAP_EVENT_QOS | - RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE), + RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE| + RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK | + RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT | + RTE_EVENT_DEV_CAP_NONSEQ_MODE), }; *info = evdev_sw_info; -- 2.7.5 -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
[dpdk-dev] [PATCH v3 6/8] maintainers: add the opdl pmd maintainer information
Signed-off-by: Liang Ma Signed-off-by: Peter Mccarthy --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index f0baeb4..1b8d617 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -700,6 +700,12 @@ F: doc/guides/eventdevs/sw.rst F: examples/eventdev_pipeline_sw_pmd/ F: doc/guides/sample_app_ug/eventdev_pipeline_sw_pmd.rst +Software Eventdev PMD +M: Liang Ma +M: Peter Mccarthy +F: drivers/event/opdl/ +F: doc/guides/eventdevs/opdl.rst + Packet processing - -- 2.7.5 -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
[dpdk-dev] [PATCH v3 7/8] doc:update 18.02 release notes
add opdl pmd description Signed-off-by: Liang Ma Signed-off-by: Peter Mccarthy --- doc/guides/rel_notes/release_18_02.rst | 11 +++ 1 file changed, 11 insertions(+) diff --git a/doc/guides/rel_notes/release_18_02.rst b/doc/guides/rel_notes/release_18_02.rst index 24b67bb..b2dc39c 100644 --- a/doc/guides/rel_notes/release_18_02.rst +++ b/doc/guides/rel_notes/release_18_02.rst @@ -42,6 +42,17 @@ New Features = +* **Added New eventdev OPDL PMD** + The OPDL (Ordered Packet Distribution Library) eventdev is a specific + implementation of the eventdev API. It is particularly suited to packet + processing workloads that have high throughput and low latency requirements. + All packets follow the same path through the device. The order in which + packets follow is determinted by the order in which queues are set up. + Events are left on the ring until they are transmitted. As a result packets + do not go out of order. + + With this change, application can use OPDL PMD by eventdev api. + API Changes --- -- 2.7.5 -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
[dpdk-dev] [PATCH v3 8/8] doc: add eventdev opdl pmd docuement
Add the description about opdl pmd
Signed-off-by: Liang Ma
Signed-off-by: Peter Mccarthy
---
doc/guides/eventdevs/index.rst | 1 +
doc/guides/eventdevs/opdl.rst | 162 +
2 files changed, 163 insertions(+)
create mode 100644 doc/guides/eventdevs/opdl.rst
diff --git a/doc/guides/eventdevs/index.rst b/doc/guides/eventdevs/index.rst
index ba2048c..07a41bc 100644
--- a/doc/guides/eventdevs/index.rst
+++ b/doc/guides/eventdevs/index.rst
@@ -40,3 +40,4 @@ application trough the eventdev API.
dpaa2
sw
octeontx
+opdl
diff --git a/doc/guides/eventdevs/opdl.rst b/doc/guides/eventdevs/opdl.rst
new file mode 100644
index 000..4922eaa
--- /dev/null
+++ b/doc/guides/eventdevs/opdl.rst
@@ -0,0 +1,162 @@
+.. BSD LICENSE
+Copyright(c) 2017 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.
+
+OPDL Eventdev Poll Mode Driver
+==
+
+The OPDL (Ordered Packet Distribution Library) eventdev is a specific\
+implementation of the eventdev API. It is particularly suited to packet\
+processing workloads that have high throughput and low latency requirements.\
+All packets follow the same path through the device. The order in which\
+packets follow is determinted by the order in which queues are set up.\
+Events are left on the ring until they are transmitted. As a result packets\
+do not go out of order
+
+
+Features
+
+
+The OPDL eventdev implements a subset of features of the eventdev API;
+
+Queues
+ * Atomic
+ * Ordered (Parallel is supported as parallel is a subset of Ordered)
+ * Single-Link
+
+Ports
+ * Load balanced (for Atomic, Ordered, Parallel queues)
+ * Single Link (for single-link queues)
+
+
+Configuration and Options
+-
+
+The software eventdev is a vdev device, and as such can be created from the
+application code, or from the EAL command line:
+
+* Call ``rte_vdev_init("event_opdl0")`` from the application
+
+* Use ``--vdev="event_opdl0"`` in the EAL options, which will call
+ rte_vdev_init() internally
+
+Example:
+
+.. code-block:: console
+
+./your_eventdev_application --vdev="event_opdl0"
+
+
+Single Port Queue
+~
+
+It is possible to create a Single Port Queue
``RTE_EVENT_QUEUE_CFG_SINGLE_LINK``.
+Packets dequeued from this queue do not need to be re-enqueued (as is the
+case with an ordered queue). The purpose of this queue is to allow for
+asynchronous handling of packets in the middle of a pipeline. Ordered
+queues in the middle of a pipeline cannot delete packets.
+
+
+Queue Dependencies
+~~
+
+As stated the order in which packets travel through queues is static in
+nature. They go through the queues in the order the queues are setup at
+initialisation ``rte_event_queue_setup()``. For example if an application
+sets up 3 queues, Q0, Q1, Q2 and has 3 assoicated ports P0, P1, P2 and
+P3 then packets must be
+
+ * Enqueued onto Q0 (typically through P0), then
+
+ * Dequeued from Q0 (typically through P1), then
+
+ * Enqueued onto Q1 (also through P1), then
+
+ * Dequeued from Q2 (typically through P2), then
+
+ * Enqueued onto Q3 (also through P2), then
+
+ * Dequeued from Q3 (typically through P3) and then transmitted on the
relevant \
+ eth port
+
+
+Limitations
+---
+
+The opdl implementation has a number of limitations. These limitations are
+due to the static nature of the underlying queues. It is because of this
+that
[dpdk-dev] [PATCH] eal: protect malloc stats with lock
When we're gathering statistics, we are traversing the freelist,
which may change under our feet in multithreaded scenario. This
is verified by occasional segfaults when running malloc autotest
on a machine with big amount of cores.
This patch protects malloc heap stats call with a lock. It changes
its definition in the process due to locking invalidating the
const-ness, but this isn't a public API, so that's OK.
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/common/malloc_heap.c | 6 +-
lib/librte_eal/common/malloc_heap.h | 2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/common/malloc_heap.c
b/lib/librte_eal/common/malloc_heap.c
index 267a4c6..c731f1c 100644
--- a/lib/librte_eal/common/malloc_heap.c
+++ b/lib/librte_eal/common/malloc_heap.c
@@ -178,12 +178,14 @@ malloc_heap_alloc(struct malloc_heap *heap,
* Function to retrieve data for heap on given socket
*/
int
-malloc_heap_get_stats(const struct malloc_heap *heap,
+malloc_heap_get_stats(struct malloc_heap *heap,
struct rte_malloc_socket_stats *socket_stats)
{
size_t idx;
struct malloc_elem *elem;
+ rte_spinlock_lock(&heap->lock);
+
/* Initialise variables for heap */
socket_stats->free_count = 0;
socket_stats->heap_freesz_bytes = 0;
@@ -205,6 +207,8 @@ malloc_heap_get_stats(const struct malloc_heap *heap,
socket_stats->heap_allocsz_bytes = (socket_stats->heap_totalsz_bytes -
socket_stats->heap_freesz_bytes);
socket_stats->alloc_count = heap->alloc_count;
+
+ rte_spinlock_unlock(&heap->lock);
return 0;
}
diff --git a/lib/librte_eal/common/malloc_heap.h
b/lib/librte_eal/common/malloc_heap.h
index 3ccbef0..3b1166f 100644
--- a/lib/librte_eal/common/malloc_heap.h
+++ b/lib/librte_eal/common/malloc_heap.h
@@ -57,7 +57,7 @@ malloc_heap_alloc(struct malloc_heap *heap, const char
*type, size_t size,
unsigned flags, size_t align, size_t bound);
int
-malloc_heap_get_stats(const struct malloc_heap *heap,
+malloc_heap_get_stats(struct malloc_heap *heap,
struct rte_malloc_socket_stats *socket_stats);
int
--
2.7.4
Re: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership
On Thu, Dec 21, 2017 at 06:06:48PM +0100, Thomas Monjalon wrote: > 08/12/2017 13:31, Neil Horman: > > On Fri, Dec 08, 2017 at 12:35:18PM +0100, Thomas Monjalon wrote: > > > 05/12/2017 11:05, Bruce Richardson: > > > > > I think you suggest to make all the ethdev configuration race safe, it > > > > > is behind to this thread. Current ethdev implementation leave the > > > > > race management to applications, so port ownership as any other port > > > > > configurations should be designed in the same method. > > > > > > > > One key difference, though, being that port ownership itself could be > > > > used to manage the thread-safety of the ethdev configuration. It's also > > > > a little different from other APIs in that I find it hard to come up > > > > with a scenario where it would be very useful to an application without > > > > also having some form of locking present in it. For other config/control > > > > APIs we can have the control plane APIs work without locks e.g. by > > > > having a single designated thread/process manage all configuration > > > > updates. However, as Neil points out, in such a scenario, the ownership > > > > concept doesn't provide any additional benefit so can be skipped > > > > completely. I'd view it a bit like the reference counting of mbufs - > > > > we can provide a lockless/non-atomic version, but for just about every > > > > real use-case, you want the atomic version. > > > > > > I think we need to clearly describe what is the tread-safety policy > > > in DPDK (especially in ethdev as a first example). > > > Let's start with obvious things: > > > > > > 1/ A queue is not protected for races with multiple Rx or Tx > > > - no planned change because of performance purpose > > > 2/ The list of devices is racy > > > - to be fixed with atomics > > > 3/ The configuration of different devices is thread-safe > > > - the configurations are different per-device > > > 4/ The configuration of a given device is racy > > > - can be managed by the owner of the device > > > 5/ The device ownership is racy > > > - to be fixed with atomics > > > > > > What am I missing? > > > > > There is fan out to consider here: > > > > 1) Is device configuration racy with ownership? That is to say, can I > > change > > ownership of a device safely while another thread that currently owns it > > modifies its configuration? > > If an entity steals ownership to another one, either it is agreed earlier, > or it is done by a central authority. > When it is acked that ownership can be moved, there should not be any > configuration in progress. > So it is more a communication issue than a race. > But if thats the case (specifically that mutual exclusion between port ownership and configuration is an exercize left to an application developer), then port ownership itself is largely meaningless within the dpdk, because the notion of who owns the port needs to be codified within the application anyway. > > 2) Is device configuration racy with device addition/removal? That is to > > say, > > can one thread remove a device while another configures it. > > I think it is the same as two threads configuring the same device > (item 4/ above). It can be managed with port ownership. > Only if you assert that application is required to have the owning port be responsible for the ports deletion, which we can say, but that leads to the issue above again. > > There are probably many subsystem interactions that need to be addressed > > here. > > > > Neil > > > > > I am also wondering whether the device ownership can be a separate > > > library used in several device class interfaces? > > >
[dpdk-dev] [PATCH] member: fix memory leak on error
rte_member may have allocated a tailq entry before failure, so
free it.
Fixes: 857ed6c68cf2 ("member: implement main API")
Cc: yipeng1.w...@intel.com
Signed-off-by: Anatoly Burakov
---
lib/librte_member/rte_member.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_member/rte_member.c b/lib/librte_member/rte_member.c
index cc9ea84..569fff9 100644
--- a/lib/librte_member/rte_member.c
+++ b/lib/librte_member/rte_member.c
@@ -191,6 +191,7 @@ rte_member_create(const struct rte_member_parameters
*params)
return setsum;
error_unlock_exit:
+ rte_free(te);
rte_rwlock_write_unlock(RTE_EAL_TAILQ_RWLOCK);
rte_member_free(setsum);
return NULL;
--
2.7.4
Re: [dpdk-dev] [PATCH 01/11] avp: implement dynamic logging
On 12/20/2017 10:58 AM, Stephen Hemminger wrote:
> On Tue, 19 Dec 2017 17:53:50 -0800
> Ferruh Yigit wrote:
>
>> On 12/18/2017 10:38 PM, Stephen Hemminger wrote:
>>> All PMD should be using dynamic log levels.
>>>
>>> Signed-off-by: Stephen Hemminger
<...>
>>> @@ -2312,3 +2313,12 @@ avp_dev_stats_reset(struct rte_eth_dev *eth_dev)
>>>
>>> RTE_PMD_REGISTER_PCI(net_avp, rte_avp_pmd);
>>> RTE_PMD_REGISTER_PCI_TABLE(net_avp, pci_id_avp_map);
>>> +
>>> +RTE_INIT(avp_init_log);
>>> +static void
>>> +avp_init_log(void)
>>> +{
>>> + avp_logtype_driver = rte_log_register("pmd.avp.driver");
>>> + if (avp_logtype_driver >= 0)
>>> + rte_log_set_level(avp_logtype_driver, RTE_LOG_NOTICE);
>>> +}
>>
>> This can be done later as well but what do you think creating a macro [1], so
>> that driver part can become just:
>>
>> PMD_INIT_LOG(avp, init, NOTICE);
>>
>>
>>
>> [1] something like:
>> #define INIT_LOG_VAR_NAME(pmd, type) logtype_ ## pmd ## _ ## type
>> #define INIT_LOG_FUNC_NAME(pmd, type) log_ ## pmd ## _ ## type
>>
>> #define PMD_INIT_LOG(pmd, type, level)\
>> int INIT_LOG_VAR_NAME(pmd, type); \
>> RTE_INIT(INIT_LOG_FUNC_NAME(pmd, type));\
>> static void INIT_LOG_FUNC_NAME(pmd, type)(void) \
>> { \
>> INIT_LOG_VAR_NAME(pmd, type) = rte_log_register("pmd."
>> RTE_STR(pmd) "." RTE_STR(type)); \
>> if (INIT_LOG_VAR_NAME(pmd, type) > 0) \
>> rte_log_set_level(INIT_LOG_VAR_NAME(pmd, type),
>> RTE_LOG_##level); \
>> }
>
> That macro is a little complex. Also, for better or worse, the current
> logging is done on a per driver basis. If we want to do something fancier
> it should be in common EAL core.
Of course, my intention was putting it into rte_log.h so updates in each driver
will be minimal. But this can be done better to cover library updates as well.
[dpdk-dev] [PATCH] eal: fix memory leak in memzone when no room in config
We check if there's space in config after we allocated the memzone,
but if there isn't, we never free it back. This patch adds memzone
free if there's no room in memzone config.
Fixes: ff909fe21f0a ("mem: introduce memzone freeing")
Cc: sergio.gonzalez.mon...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/common/eal_common_memzone.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/common/eal_common_memzone.c
b/lib/librte_eal/common/eal_common_memzone.c
index ea072a2..b682b00 100644
--- a/lib/librte_eal/common/eal_common_memzone.c
+++ b/lib/librte_eal/common/eal_common_memzone.c
@@ -237,7 +237,7 @@ memzone_reserve_aligned_thread_unsafe(const char *name,
size_t len,
return NULL;
}
- const struct malloc_elem *elem = malloc_elem_from_data(mz_addr);
+ struct malloc_elem *elem = malloc_elem_from_data(mz_addr);
/* fill the zone in config */
mz = get_next_free_memzone();
@@ -245,6 +245,7 @@ memzone_reserve_aligned_thread_unsafe(const char *name,
size_t len,
if (mz == NULL) {
RTE_LOG(ERR, EAL, "%s(): Cannot find free memzone but there is
room "
"in config!\n", __func__);
+ malloc_elem_free(elem);
rte_errno = ENOSPC;
return NULL;
}
--
2.7.4
Re: [dpdk-dev] [PATCH] doc: add queue region feature info to release notes
On 12/20/2017 7:52 PM, Wei Zhao wrote: > This patch add inforation about i40e queue region > realted to release notes, it has been missed before. > > Signed-off-by: Wei Zhao > --- > doc/guides/rel_notes/release_17_11.rst | 17 + I think we shouldn't update release notes once it has been released. Perhaps it can be an option to mention from this in latest release notes with a note that says actual support added in v17.11?
[dpdk-dev] [PATCH 1/3] test: fix typo in memzone autotest
Fixes: 71330483a193 ("test/memzone: fix memory leak")
Cc: radoslaw.bierna...@linaro.org
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov
---
test/test/test_memzone.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/test/test/test_memzone.c b/test/test/test_memzone.c
index 1cf235a..aaffef9 100644
--- a/test/test/test_memzone.c
+++ b/test/test/test_memzone.c
@@ -948,11 +948,11 @@ test_memzone_basic(void)
return 0;
}
-static int memzone_calk_called;
+static int memzone_walk_called;
static void memzone_walk_clb(const struct rte_memzone *mz __rte_unused,
void *arg __rte_unused)
{
- memzone_calk_called = 1;
+ memzone_walk_called = 1;
}
static int
@@ -996,7 +996,7 @@ test_memzone(void)
printf("check memzone cleanup\n");
rte_memzone_walk(memzone_walk_clb, NULL);
- if (memzone_calk_called) {
+ if (memzone_walk_called) {
printf("there are some memzones left after test\n");
rte_memzone_dump(stdout);
return -1;
--
2.7.4
[dpdk-dev] [PATCH 2/3] test: fix copypaste error in memzone autotest
Fixes: b77b5639726e ("mem: add huge page sizes for IBM Power")
Cc: chao...@linux.vnet.ibm.com
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov
---
test/test/test_memzone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/test/test_memzone.c b/test/test/test_memzone.c
index aaffef9..5c0567f 100644
--- a/test/test/test_memzone.c
+++ b/test/test/test_memzone.c
@@ -321,7 +321,7 @@ test_memzone_reserve_flags(void)
mz = rte_memzone_reserve("flag_zone_16M_HINT", size,
SOCKET_ID_ANY, RTE_MEMZONE_16MB|RTE_MEMZONE_SIZE_HINT_ONLY);
if (mz == NULL) {
- printf("MEMZONE FLAG 2MB\n");
+ printf("MEMZONE FLAG 16MB\n");
return -1;
}
if (mz->hugepage_sz != RTE_PGSIZE_16M) {
--
2.7.4
[dpdk-dev] [PATCH 3/3] test: fix wrong test in memzone autotest
When reserving memzones in autotest, it makes no sense to expect a
failed memzone reserve when we specify both size flags - instead,
we should expect a memzone reserved with one of the two sizes.
Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov
---
test/test/test_memzone.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/test/test/test_memzone.c b/test/test/test_memzone.c
index 5c0567f..ecd9880 100644
--- a/test/test/test_memzone.c
+++ b/test/test/test_memzone.c
@@ -289,10 +289,19 @@ test_memzone_reserve_flags(void)
if (hugepage_2MB_avail && hugepage_1GB_avail) {
mz = rte_memzone_reserve("flag_zone_2M_HINT", size,
SOCKET_ID_ANY,
RTE_MEMZONE_2MB|RTE_MEMZONE_1GB);
- if (mz != NULL) {
+ if (mz == NULL) {
printf("BOTH SIZES SET\n");
return -1;
}
+ if (mz->hugepage_sz != RTE_PGSIZE_1G &&
+ mz->hugepage_sz != RTE_PGSIZE_2M) {
+ printf("Wrong size when both sizes set\n");
+ return -1;
+ }
+ if (rte_memzone_free(mz)) {
+ printf("Fail memzone free\n");
+ return -1;
+ }
}
}
/*
@@ -424,10 +433,19 @@ test_memzone_reserve_flags(void)
mz = rte_memzone_reserve("flag_zone_16M_HINT", size,
SOCKET_ID_ANY,
RTE_MEMZONE_16MB|RTE_MEMZONE_16GB);
- if (mz != NULL) {
+ if (mz == NULL) {
printf("BOTH SIZES SET\n");
return -1;
}
+ if (mz->hugepage_sz != RTE_PGSIZE_16G &&
+ mz->hugepage_sz != RTE_PGSIZE_16M) {
+ printf("Wrong size when both sizes set\n");
+ return -1;
+ }
+ if (rte_memzone_free(mz)) {
+ printf("Fail memzone free\n");
+ return -1;
+ }
}
}
return 0;
--
2.7.4
Re: [dpdk-dev] [dpdk-stable] [PATCH] net/sfc: fix main MAC address handling
On 12/20/2017 1:52 AM, Andrew Rybchenko wrote:
> From: Ivan Malov
>
> There is a school of thought that rte_eth_dev_default_mac_addr_set()
> must call the PMD callback first and then save the new MAC address
> in dev->data->mac_addrs[0].
:)
> If this concept gets approved, it will
> break the current approach used in sfc driver as the latter relies
> on the assumption that the new MAC address is already contained in
> dev->data->mac_addrs[0], and, if adapter restart is needed to make
> the HW apply the new address, the outdated value will be retrieved
> from dev->data. In order to preclude any possible bugs, this patch
> adds device private storage for the up-to-date copy of the address.
Thank you for taking care of this.
>
> Fixes: c100fd464bb7 ("net/sfc: support main MAC address change")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Ivan Malov
> Signed-off-by: Andrew Rybchenko
Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership
Hi > -Original Message- > From: Neil Horman [mailto:nhor...@tuxdriver.com] > Sent: Thursday, December 21, 2017 7:43 PM > To: Thomas Monjalon > Cc: dev@dpdk.org; Bruce Richardson ; Matan > Azrad ; Ananyev, Konstantin > ; Gaëtan Rivet ; > Wu, Jingjing > Subject: Re: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership > > On Thu, Dec 21, 2017 at 06:06:48PM +0100, Thomas Monjalon wrote: > > 08/12/2017 13:31, Neil Horman: > > > On Fri, Dec 08, 2017 at 12:35:18PM +0100, Thomas Monjalon wrote: > > > > 05/12/2017 11:05, Bruce Richardson: > > > > > > I think you suggest to make all the ethdev configuration race > > > > > > safe, it is behind to this thread. Current ethdev > > > > > > implementation leave the race management to applications, so > > > > > > port ownership as any other port configurations should be designed > in the same method. > > > > > > > > > > One key difference, though, being that port ownership itself > > > > > could be used to manage the thread-safety of the ethdev > > > > > configuration. It's also a little different from other APIs in > > > > > that I find it hard to come up with a scenario where it would be > > > > > very useful to an application without also having some form of > > > > > locking present in it. For other config/control APIs we can have > > > > > the control plane APIs work without locks e.g. by having a > > > > > single designated thread/process manage all configuration > > > > > updates. However, as Neil points out, in such a scenario, the > > > > > ownership concept doesn't provide any additional benefit so can > > > > > be skipped completely. I'd view it a bit like the reference > > > > > counting of mbufs - we can provide a lockless/non-atomic version, > but for just about every real use-case, you want the atomic version. > > > > > > > > I think we need to clearly describe what is the tread-safety > > > > policy in DPDK (especially in ethdev as a first example). > > > > Let's start with obvious things: > > > > > > > > 1/ A queue is not protected for races with multiple Rx or Tx > > > > - no planned change because of performance > purpose > > > > 2/ The list of devices is racy > > > > - to be fixed with atomics > > > > 3/ The configuration of different devices is thread-safe > > > > - the configurations are different per-device > > > > 4/ The configuration of a given device is racy > > > > - can be managed by the owner of the device > > > > 5/ The device ownership is racy > > > > - to be fixed with atomics > > > > > > > > What am I missing? > > > > Thank you Thomas for this order. Actually the port ownership is a good opportunity to redefine the synchronization rules in ethdev :) > > > There is fan out to consider here: > > > > > > 1) Is device configuration racy with ownership? That is to say, can > > > I change ownership of a device safely while another thread that > > > currently owns it modifies its configuration? > > > > If an entity steals ownership to another one, either it is agreed > > earlier, or it is done by a central authority. > > When it is acked that ownership can be moved, there should not be any > > configuration in progress. > > So it is more a communication issue than a race. > > > But if thats the case (specifically that mutual exclusion between port > ownership and configuration is an exercize left to an application developer), > then port ownership itself is largely meaningless within the dpdk, because > the notion of who owns the port needs to be codified within the application > anyway. > Bruce, As I understand it, only the dpdk entity who took ownership of a port successfully can configure the device by default, if other dpdk entities want to configure it too they must to be synchronized with the port owner while it is not recommended after the port ownership integration. So, for example, if the dpdk entity is an application, the application should take ownership of the port and manage the synchronization of this port configuration between the application threads and its EAL host thread callbacks, no other dpdk entity should configure the same port because they should fail when they try to take ownership of the same port too. Each dpdk entity which wants to take ownership must to be able to synchronize the port configuration in its level. > > > > 2) Is device configuration racy with device addition/removal? That > > > is to say, can one thread remove a device while another configures it. > > > > I think it is the same as two threads configuring the same device > > (item 4/ above). It can be managed with port ownership. > > > Only if you assert that application is required to have the owning port be > responsible for the ports deletion, which we can say, but that leads to the > issue above again. > > As Thomas said in item 2 the port creation must be synchr
Re: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership
On Thu, Dec 21, 2017 at 07:37:06PM +, Matan Azrad wrote: > Hi > > > -Original Message- > > From: Neil Horman [mailto:nhor...@tuxdriver.com] > > Sent: Thursday, December 21, 2017 7:43 PM > > To: Thomas Monjalon > > Cc: dev@dpdk.org; Bruce Richardson ; Matan > > Azrad ; Ananyev, Konstantin > > ; Gaëtan Rivet ; > > Wu, Jingjing > > Subject: Re: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership > > > > On Thu, Dec 21, 2017 at 06:06:48PM +0100, Thomas Monjalon wrote: > > > 08/12/2017 13:31, Neil Horman: > > > > On Fri, Dec 08, 2017 at 12:35:18PM +0100, Thomas Monjalon wrote: > > > > > 05/12/2017 11:05, Bruce Richardson: > > > > > > > I think you suggest to make all the ethdev configuration race > > > > > > > safe, it is behind to this thread. Current ethdev > > > > > > > implementation leave the race management to applications, so > > > > > > > port ownership as any other port configurations should be designed > > in the same method. > > > > > > > > > > > > One key difference, though, being that port ownership itself > > > > > > could be used to manage the thread-safety of the ethdev > > > > > > configuration. It's also a little different from other APIs in > > > > > > that I find it hard to come up with a scenario where it would be > > > > > > very useful to an application without also having some form of > > > > > > locking present in it. For other config/control APIs we can have > > > > > > the control plane APIs work without locks e.g. by having a > > > > > > single designated thread/process manage all configuration > > > > > > updates. However, as Neil points out, in such a scenario, the > > > > > > ownership concept doesn't provide any additional benefit so can > > > > > > be skipped completely. I'd view it a bit like the reference > > > > > > counting of mbufs - we can provide a lockless/non-atomic version, > > but for just about every real use-case, you want the atomic version. > > > > > > > > > > I think we need to clearly describe what is the tread-safety > > > > > policy in DPDK (especially in ethdev as a first example). > > > > > Let's start with obvious things: > > > > > > > > > > 1/ A queue is not protected for races with multiple Rx or Tx > > > > > - no planned change because of performance > > purpose > > > > > 2/ The list of devices is racy > > > > > - to be fixed with atomics > > > > > 3/ The configuration of different devices is thread-safe > > > > > - the configurations are different per-device > > > > > 4/ The configuration of a given device is racy > > > > > - can be managed by the owner of the device > > > > > 5/ The device ownership is racy > > > > > - to be fixed with atomics > > > > > > > > > > What am I missing? > > > > > > > Thank you Thomas for this order. > Actually the port ownership is a good opportunity to redefine the > synchronization rules in ethdev :) > > > > > There is fan out to consider here: > > > > > > > > 1) Is device configuration racy with ownership? That is to say, can > > > > I change ownership of a device safely while another thread that > > > > currently owns it modifies its configuration? > > > > > > If an entity steals ownership to another one, either it is agreed > > > earlier, or it is done by a central authority. > > > When it is acked that ownership can be moved, there should not be any > > > configuration in progress. > > > So it is more a communication issue than a race. > > > > > But if thats the case (specifically that mutual exclusion between port > > ownership and configuration is an exercize left to an application > > developer), > > then port ownership itself is largely meaningless within the dpdk, because > > the notion of who owns the port needs to be codified within the application > > anyway. > > > > Bruce, As I understand it, only the dpdk entity who took ownership of a port > successfully can configure the device by default, if other dpdk entities want > to configure it too they must to be synchronized with the port owner while it > is not recommended after the port ownership integration. > Can you clarify what you mean by "it is not recommended after the port ownership integration"? I think there is consensus that the port owner must be the only entitiy to operate on a port (be that configuration/frame rx/tx, or some other operation). Multithreaded operation on a port always means some level of synchronization between application threads and the dpdk library, but I'm not sure why that would be different if we introduced a more concrete notion of port ownership via a new library. > So, for example, if the dpdk entity is an application, the application > should take ownership of the port and manage the synchronization of this port > configuration between the application threads and its EAL host thread > callbacks, no other dpdk entity should configure the same port because
Re: [dpdk-dev] [PATCH] vhost: introduce rte_vhost_vring_call()
Hi Stefan,
On 12/21/2017 05:41 PM, Stefan Hajnoczi wrote:
+int
+rte_vhost_vring_call(int vid, uint16_t vring_idx)
+{
+ struct virtio_net *dev;
+ struct vhost_virtqueue *vq;
+
+ dev = get_device(vid);
+ if (!dev)
+ return -1;
+
+ if (vring_idx >= VHOST_MAX_VRING)
+ return -1;
+
+ vq = dev->virtqueue[vring_idx];
+ if (!vq)
+ return -1;
+
+ /* flush used->idx update before we read avail->flags. */
+ rte_mb();
+
+ /* Kick the guest if necessary. */
+ if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
+ && (vq->callfd >= 0))
+ eventfd_write(vq->callfd, (eventfd_t)1);
+ return 0;
+}
I think it may be better to have an internal function that just take the
vq as argument to avoid getting again the vq from the vid & vring index
in the hot path.
Also, this internal function could be tagged as always inlined.
Thanks,
Maxime
Re: [dpdk-dev] [RFC v2 00/23] Dynamic memory allocation for DPDK
On Tue, 2017-12-19 at 11:14 +, Anatoly Burakov wrote: > > Quick outline of all changes done as part of this patchset: > > * Malloc heap adjusted to handle holes in address space > * Single memseg list replaced by multiple expandable memseg lists > * VA space for hugepages is preallocated in advance > * Added dynamic alloc/free for pages, happening as needed on malloc/free SPDK will need some way to register for a notification when pages are allocated or freed. For storage, the number of requests per second is (relative to networking) fairly small (hundreds of thousands per second in a traditional block storage stack, or a few million per second with SPDK). Given that, we can afford to do a dynamic lookup from va to pa/iova on each request in order to greatly simplify our APIs (users can just pass pointers around instead of mbufs). DPDK has a way to lookup the pa from a given va, but it does so by scanning /proc/self/pagemap and is very slow. SPDK instead handles this by implementing a lookup table of va to pa/iova which we populate by scanning through the DPDK memory segments at start up, so the lookup in our table is sufficiently fast for storage use cases. If the list of memory segments changes, we need to know about it in order to update our map. Having the map also enables a number of other nice things - for instance we allow users to register memory that wasn't allocated through DPDK and use it for DMA operations. We keep that va to pa/iova mapping in the same map. I appreciate you adding APIs to dynamically register this type of memory with the IOMMU on our behalf. That allows us to eliminate a nasty hack where we were looking up the vfio file descriptor through sysfs in order to send the registration ioctl. > * Added contiguous memory allocation API's for rte_malloc and rte_memzone > * Integrated Pawel Wodkowski's patch [1] for registering/unregistering memory >with VFIO >
Re: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership
> -Original Message- > From: Neil Horman [mailto:nhor...@tuxdriver.com] > Sent: Thursday, December 21, 2017 10:14 PM > To: Matan Azrad > Cc: Thomas Monjalon ; dev@dpdk.org; Bruce > Richardson ; Ananyev, Konstantin > ; Gaëtan Rivet ; > Wu, Jingjing > Subject: Re: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership > > On Thu, Dec 21, 2017 at 07:37:06PM +, Matan Azrad wrote: > > Hi > > > > > > > > I think we need to clearly describe what is the tread-safety > > > > > > policy in DPDK (especially in ethdev as a first example). > > > > > > Let's start with obvious things: > > > > > > > > > > > > 1/ A queue is not protected for races with multiple Rx or Tx > > > > > > - no planned change because of performance > > > purpose > > > > > > 2/ The list of devices is racy > > > > > > - to be fixed with atomics > > > > > > 3/ The configuration of different devices is thread-safe > > > > > > - the configurations are different per-device > > > > > > 4/ The configuration of a given device is racy > > > > > > - can be managed by the owner of the device > > > > > > 5/ The device ownership is racy > > > > > > - to be fixed with atomics > > > > > > > > > > > > What am I missing? > > > > > > > > > > Thank you Thomas for this order. > > Actually the port ownership is a good opportunity to redefine the > > synchronization rules in ethdev :) > > > > > > > There is fan out to consider here: > > > > > > > > > > 1) Is device configuration racy with ownership? That is to say, > > > > > can I change ownership of a device safely while another thread > > > > > that currently owns it modifies its configuration? > > > > > > > > If an entity steals ownership to another one, either it is agreed > > > > earlier, or it is done by a central authority. > > > > When it is acked that ownership can be moved, there should not be > > > > any configuration in progress. > > > > So it is more a communication issue than a race. > > > > > > > But if thats the case (specifically that mutual exclusion between > > > port ownership and configuration is an exercize left to an > > > application developer), then port ownership itself is largely > > > meaningless within the dpdk, because the notion of who owns the port > > > needs to be codified within the application anyway. > > > > > > > Bruce, As I understand it, only the dpdk entity who took ownership of a > port successfully can configure the device by default, if other dpdk entities > want to configure it too they must to be synchronized with the port owner > while it is not recommended after the port ownership integration. > > > Can you clarify what you mean by "it is not recommended after the port > ownership integration"? Sure, The new defining of ethdev synchronization doesn't recommend to manage a port by 2 different dpdk entities, it can be done but not recommended. > I think there is consensus that the port owner must > be the only entitiy to operate on a port (be that configuration/frame rx/tx, > or > some other operation). Your question above caused me to think that you don't understand it, How can someone who is not the port owner to change the port owner? Changing the port owner, like port configuration and port release must be done by the owner itself except the case that there is no owner to the port. See the API rte_eth_dev_owner_remove. > Multithreaded operation on a port always means > some level of synchronization between application threads and the dpdk > library, Yes. >but I'm not sure why that would be different if we introduced a more > concrete notion of port ownership via a new library. > What do you mean by "new library"?, port is an ethdev instance and should be managed by ethdev. > > So, for example, if the dpdk entity is an application, the application > > should >> take ownership of the port and manage the synchronization of this port >> configuration between the application threads and its EAL host thread >> callbacks, no other dpdk entity should configure the same port because they >> should fail when they try to take ownership of the same port too. > Well, failing is one good approach, yes, blocking on port relenquishment > could be another. I'd recommend an API with the following interface: > > rte_port_ownership_claim(int port_id) - blocks execution of the calling > thread until the previous owner releases ownership, then claims it and > returns > > rte_port_ownership_release(int port_id) - releases ownership of port, or > returns error if the port was not owned by this execution context > > rte_port_owernship_try_claim(int port_id) - same as > rte_port_ownership_claim, but fails if the port is already owned. > > That would give the option for both semantics. I think the current APIs are better because of the next reasons: - It defines well who is the owner. - The owner structure includes string to allow better debu
Re: [dpdk-dev] [PATCH v3 1/8] event/opdl: add the opdl ring infrastructure library
> > OPDL ring is the core infrastructure of OPDL PMD. OPDL ring library > provide the core data structure and core helper function set. The Ring > implements a single ring multi-port/stage pipelined packet distribution > mechanism. This mechanism has the following characteristics: > > • No multiple queue cost, therefore, latency is significant reduced. > • Fixed dependencies between queue/ports is more suitable for complex. > fixed pipelines of stateless packet processing (static pipeline). > • Has decentralized distribution (no scheduling core). > • Packets remain in order (no reorder core(s)). > * Update build system to enable compilation. > > Signed-off-by: Liang Ma > Signed-off-by: Peter Mccarthy > --- > config/common_base|6 + > drivers/event/Makefile|1 + > drivers/event/opdl/Makefile | 62 + > drivers/event/opdl/opdl_log.h | 59 + > drivers/event/opdl/opdl_ring.c| 1250 + > drivers/event/opdl/opdl_ring.h| 628 +++ > drivers/event/opdl/rte_pmd_evdev_opdl_version.map |3 + > mk/rte.app.mk |1 + > mk/toolchain/gcc/rte.toolchain-compat.mk |6 + > mk/toolchain/icc/rte.toolchain-compat.mk |6 + > 10 files changed, 2022 insertions(+) > create mode 100644 drivers/event/opdl/Makefile > create mode 100644 drivers/event/opdl/opdl_log.h > create mode 100644 drivers/event/opdl/opdl_ring.c > create mode 100644 drivers/event/opdl/opdl_ring.h > create mode 100644 drivers/event/opdl/rte_pmd_evdev_opdl_version.map > > diff --git a/config/common_base b/config/common_base > index e74febe..67adaba 100644 > --- a/config/common_base > +++ b/config/common_base > @@ -594,6 +594,12 @@ CONFIG_RTE_LIBRTE_PMD_OCTEONTX_SSOVF=y > CONFIG_RTE_LIBRTE_PMD_OCTEONTX_SSOVF_DEBUG=n > > # > +# Compile PMD for OPDL event device > +# > +CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV=y > +CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV_DEBUG=n > + > +# > # Compile librte_ring > # > CONFIG_RTE_LIBRTE_RING=y > diff --git a/drivers/event/Makefile b/drivers/event/Makefile > index 1f9c0ba..d62 100644 > --- a/drivers/event/Makefile > +++ b/drivers/event/Makefile > @@ -35,5 +35,6 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_SKELETON_EVENTDEV) += skeleton > DIRS-$(CONFIG_RTE_LIBRTE_PMD_SW_EVENTDEV) += sw > DIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_SSOVF) += octeontx > DIRS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_EVENTDEV) += dpaa2 > +DIRS-$(CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV) += opdl > > include $(RTE_SDK)/mk/rte.subdir.mk > diff --git a/drivers/event/opdl/Makefile b/drivers/event/opdl/Makefile > new file mode 100644 > index 000..8277e25 > --- /dev/null > +++ b/drivers/event/opdl/Makefile > @@ -0,0 +1,62 @@ > +# BSD LICENSE > +# > +# Copyright(c) 2016-2017 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_opdl_event.a > + > +# build flags > +CFLAGS += -O3 > +CFLAGS += $(WERROR_FLAGS) > +# for older GCC versions, allow us to initialize an event using > +# designated initializers. > +ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y) > +ifeq ($(shell test $(GCC_VERSION) -le 50 && echo 1), 1) > +CFLAGS += -Wno-missing-field-initializers > +endif > +endif > + > +LDLIBS += -lrte_eal -lrte_even
[dpdk-dev] [RFC] tunnel endpoint hw acceleration enablement
This RFC contains a proposal to add a new tunnel endpoint API to DPDK that when
used
in conjunction with rte_flow enables the configuration of inline data path
encapsulation
and decapsulation of tunnel endpoint network overlays on accelerated IO devices.
The proposed new API would provide for the creation, destruction, and
monitoring of a tunnel endpoint in supporting hw, as well as capabilities APIs
to allow the
acceleration features to be discovered by applications.
/** Tunnel Endpoint context, opaque structure */
struct rte_tep;
enum rte_tep_type {
RTE_TEP_TYPE_VXLAN = 1, /**< VXLAN Protocol */
RTE_TEP_TYPE_NVGRE, /**< NVGRE Protocol */
...
};
/** Tunnel Endpoint Attributes */
struct rte_tep_attr {
enum rte_type_type type;
/* other endpoint attributes here */
}
/**
* Create a tunnel end-point context as specified by the flow attribute and
pattern
*
* @param port_id Port identifier of Ethernet device.
* @param attrFlow rule attributes.
* @param pattern Pattern specification by list of rte_flow_items.
* @return
* - On success returns pointer to TEP context
* - On failure returns NULL
*/
struct rte_tep *rte_tep_create(uint16_t port_id,
struct rte_tep_attr *attr, struct rte_flow_item
pattern[])
/**
* Destroy an existing tunnel end-point context. All the end-points context
* will be destroyed, so all active flows using tep should be freed before
* destroying context.
* @param port_idPort identifier of Ethernet device.
* @param tepTunnel endpoint context
* @return
* - On success returns 0
* - On failure returns 1
*/
int rte_tep_destroy(uint16_t port_id, struct rte_tep *tep)
/**
* Get tunnel endpoint statistics
*
* @param port_idPort identifier of Ethernet device.
* @param tepTunnel endpoint context
* @param stats Tunnel endpoint statistics
*
* @return
* - On success returns 0
* - On failure returns 1
*/
Int
rte_tep_stats_get(uint16_t port_id, struct rte_tep *tep,
struct rte_tep_stats *stats)
/**
* Get ports tunnel endpoint capabilities
*
* @param port_idPort identifier of Ethernet device.
* @param capabilitiesTunnel endpoint capabilities
*
* @return
* - On success returns 0
* - On failure returns 1
*/
int
rte_tep_capabilities_get(uint16_t port_id,
struct rte_tep_capabilities *capabilities)
To direct traffic flows to hw terminated tunnel endpoint the rte_flow API is
enhanced to add a new flow item type. This contains a pointer to the
TEP context as well as the overlay flow id to which the traffic flow is
associated.
struct rte_flow_item_tep {
struct rte_tep *tep;
uint32_t flow_id;
}
Also 2 new generic actions types are added encapsulation and decapsulation.
RTE_FLOW_ACTION_TYPE_ENCAP
RTE_FLOW_ACTION_TYPE_DECAP
struct rte_flow_action_encap {
struct rte_flow_item *item;
}
struct rte_flow_action_decap {
struct rte_flow_item *item;
}
The following section outlines the intended usage of the new APIs and then how
they are combined with the existing rte_flow APIs.
Tunnel endpoints are created on logical ports which support the capability
using rte_tep_create() using a combination of TEP attributes and
rte_flow_items. In the example below a new IPv4 VxLAN endpoint is being defined.
The attrs parameter sets the TEP type, and could be used for other possible
attributes.
struct rte_tep_attr attrs = { .type = RTE_TEP_TYPE_VXLAN };
The values for the headers which make up the tunnel endpointr are then
defined using spec parameter in the rte flow items (IPv4, UDP and
VxLAN in this case)
struct rte_flow_item_ipv4 ipv4_item = {
.hdr = { .src_addr = saddr, .dst_addr = daddr }
};
struct rte_flow_item_udp udp_item = {
.hdr = { .src_port = sport, .dst_port = dport }
};
struct rte_flow_item_vxlan vxlan_item = { .flags = vxlan_flags };
struct rte_flow_item pattern[] = {
{ .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item },
{ .type = RTE_FLOW_ITEM_TYPE_UDP, .spec = &udp_item },
{ .type = RTE_FLOW_ITEM_TYPE_VXLAN, .spec = &vxlan_item },
{ .type = RTE_FLOW_ITEM_TYPE_END }
};
The tunnel endpoint can then be create on the port. Whether or not any hw
configuration is required at this point would be hw dependent, but if not
the context for the TEP is available for use in programming flow, so the
application is not forced to redefine the TEP parameters on each flow
addition.
struct rte_tep *tep = rte_tep_create(port_id, &attrs, pattern);
Once the tep context is created flows can then be directed to that endpoint for
processing. The following sections will outline how the author envisage flow
programming will work and also how TEP acceleration can be combined with other
accelerations.
Ingress TEP decapsulati
Re: [dpdk-dev] [PATCH] member: fix memory leak on error
Thank you Anatoly for finding this issue. In the code I tried to reuse the
rte_member_free function to free memory but it may not be executed through.
Because of this, I may not properly release setsum struct neither. I will post
a fix for both soon.
Thanks
>-Original Message-
>From: Burakov, Anatoly
>Sent: Thursday, December 21, 2017 9:51 AM
>To: dev@dpdk.org
>Cc: Wang, Yipeng1 ; Gobriel, Sameh
>
>Subject: [PATCH] member: fix memory leak on error
>
>rte_member may have allocated a tailq entry before failure, so
>free it.
>
>Fixes: 857ed6c68cf2 ("member: implement main API")
>Cc: yipeng1.w...@intel.com
>Signed-off-by: Anatoly Burakov
>---
> lib/librte_member/rte_member.c | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/lib/librte_member/rte_member.c
>b/lib/librte_member/rte_member.c
>index cc9ea84..569fff9 100644
>--- a/lib/librte_member/rte_member.c
>+++ b/lib/librte_member/rte_member.c
>@@ -191,6 +191,7 @@ rte_member_create(const struct
>rte_member_parameters *params)
> return setsum;
>
> error_unlock_exit:
>+ rte_free(te);
> rte_rwlock_write_unlock(RTE_EAL_TAILQ_RWLOCK);
> rte_member_free(setsum);
> return NULL;
>--
>2.7.4
Re: [dpdk-dev] [PATCH] member: fix memory leak on error
Btw, Pablo, since I remember I refer to the EFD library on my membership
implementation, does EFD have similar memory leakage issue that not releasing
te when failure?
Thanks
>-Original Message-
>From: Wang, Yipeng1
>Sent: Thursday, December 21, 2017 4:01 PM
>To: Burakov, Anatoly ; dev@dpdk.org
>Cc: Gobriel, Sameh
>Subject: RE: [PATCH] member: fix memory leak on error
>
>Thank you Anatoly for finding this issue. In the code I tried to reuse the
>rte_member_free function to free memory but it may not be executed
>through.
>
>Because of this, I may not properly release setsum struct neither. I will post
>a
>fix for both soon.
>
>Thanks
>
>>-Original Message-
>>From: Burakov, Anatoly
>>Sent: Thursday, December 21, 2017 9:51 AM
>>To: dev@dpdk.org
>>Cc: Wang, Yipeng1 ; Gobriel, Sameh
>>
>>Subject: [PATCH] member: fix memory leak on error
>>
>>rte_member may have allocated a tailq entry before failure, so
>>free it.
>>
>>Fixes: 857ed6c68cf2 ("member: implement main API")
>>Cc: yipeng1.w...@intel.com
>>Signed-off-by: Anatoly Burakov
>>---
>> lib/librte_member/rte_member.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>>diff --git a/lib/librte_member/rte_member.c
>>b/lib/librte_member/rte_member.c
>>index cc9ea84..569fff9 100644
>>--- a/lib/librte_member/rte_member.c
>>+++ b/lib/librte_member/rte_member.c
>>@@ -191,6 +191,7 @@ rte_member_create(const struct
>>rte_member_parameters *params)
>> return setsum;
>>
>> error_unlock_exit:
>>+ rte_free(te);
>> rte_rwlock_write_unlock(RTE_EAL_TAILQ_RWLOCK);
>> rte_member_free(setsum);
>> return NULL;
>>--
>>2.7.4
Re: [dpdk-dev] [PATCH v6 0/2] add uevent monitor for hot plug
Moti, Hello and sorry for be reply late until now, definitely as gaetan said that there might be some change after the version, anyway I will create a new version to benefit you all to review and further test. Best regards, Jeff Guo -Original Message- From: Gaëtan Rivet [mailto:gaetan.ri...@6wind.com] Sent: Thursday, December 14, 2017 6:21 PM To: Mordechay Haimovsky Cc: Guo, Jia ; dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v6 0/2] add uevent monitor for hot plug Hello Moti, On Thu, Dec 14, 2017 at 09:48:23AM +, Mordechay Haimovsky wrote: > Hello, > I would like to apply this patch in order to review it. > In absence of answer from Jeff, Those two paths were modified during the 17.08 release: both pci and vdev buses have been moved to drivers/bus. > Trying to apply it on 17.11 (and latest) fails due to missing > lib/librte_eal/common/eal_common_vdev.c > Trying to apply it on 17.08.1 fails on missing > drivers/bus/pci/bsd/pci.c file > Only the pci bus move was integrated by Jeff to this version of the udev monitor. The vdev bus move however came later and should be rebased upon. > So, on what DPDK version should I apply it ? > Or maybe there is a bunch of other patches I have to apply in order to use > this patch ? > You should apply it on 17.11 IMO. Either you take upon yourself to make it work with the new tree, or wait for Jeff to send a new version. -- Gaëtan Rivet 6WIND
Re: [dpdk-dev] [PATCH] net/i40e: fix FDIR rule confiliction issue
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Beilei Xing
> Sent: Thursday, November 30, 2017 2:36 PM
> To: Wu, Jingjing
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH] net/i40e: fix FDIR rule confiliction issue
>
> Failed to create two FDIR rules with different vlan id for the same PCTYPE.
> Root cause is that wrong hash key length is used.
>
> Fixes: 4149825bbdb9 ("net/i40e: finish integration FDIR with generic flow
> API")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Beilei Xing
> ---
> drivers/net/i40e/i40e_ethdev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 811cc9f..583f100 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -1006,7 +1006,7 @@ i40e_init_fdir_filter_list(struct rte_eth_dev *dev)
> struct rte_hash_parameters fdir_hash_params = {
> .name = fdir_hash_name,
> .entries = I40E_MAX_FDIR_FILTER_NUM,
> - .key_len = sizeof(struct rte_eth_fdir_input),
> + .key_len = sizeof(struct i40e_fdir_input),
> .hash_func = rte_hash_crc,
> .hash_func_init_val = 0,
> .socket_id = rte_socket_id(),
> --
> 2.5.5
Acked-by: Qi Zhang
Re: [dpdk-dev] [PATCH] doc: add queue region feature info to release notes
Ok, this will be updating in release notes for v18.02, and have a mention that this feature has been implemented in v17.11? > -Original Message- > From: Yigit, Ferruh > Sent: Friday, December 22, 2017 2:10 AM > To: Zhao1, Wei ; dev@dpdk.org > Cc: Mcnamara, John > Subject: Re: [dpdk-dev] [PATCH] doc: add queue region feature info to > release notes > > On 12/20/2017 7:52 PM, Wei Zhao wrote: > > This patch add inforation about i40e queue region realted to release > > notes, it has been missed before. > > > > Signed-off-by: Wei Zhao > > --- > > doc/guides/rel_notes/release_17_11.rst | 17 + > > I think we shouldn't update release notes once it has been released. > > Perhaps it can be an option to mention from this in latest release notes with > a note that says actual support added in v17.11?
Re: [dpdk-dev] [PATCH] net/i40e: add fdir nvgre parameters check
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Zhao
> Sent: Friday, December 1, 2017 4:47 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo ; Xing, Beilei
> ; Zhao1, Wei
> Subject: [dpdk-dev] [PATCH] net/i40e: add fdir nvgre parameters check
>
> Add mask parameters check in nvgre parser for flow API.
>
> Fixes: 30965ca341278 ("net/i40e: add NVGRE flow parsing")
>
> Signed-off-by: Wei Zhao
> ---
> drivers/net/i40e/i40e_flow.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/net/i40e/i40e_flow.c b/drivers/net/i40e/i40e_flow.c index
> 7e4936e..05e54f1 100644
> --- a/drivers/net/i40e/i40e_flow.c
> +++ b/drivers/net/i40e/i40e_flow.c
> @@ -3610,6 +3610,41 @@ i40e_flow_parse_nvgre_pattern(__rte_unused
> struct rte_eth_dev *dev,
> "Invalid TNI mask");
> return -rte_errno;
> }
> + if (nvgre_mask->protocol &&
> + nvgre_mask->protocol != 0x) {
> + rte_flow_error_set(error, EINVAL,
> + RTE_FLOW_ERROR_TYPE_ITEM,
> + item,
> + "Invalid NVGRE item");
> + return -rte_errno;
> + }
> + if (nvgre_mask->c_k_s_rsvd0_ver &&
> + nvgre_mask->c_k_s_rsvd0_ver !=
> + rte_cpu_to_be_16(0x3000)) {
If " c_k_s_rsvd0_ver must have value 0x2000 according to RFC 7637" , I think
here we
should have mask 0x to make sure each bit of c_k_s_rsvd0_ver be set
correctly.
Regards
Qi
> + rte_flow_error_set(error, EINVAL,
> +RTE_FLOW_ERROR_TYPE_ITEM,
> +item,
> +"Invalid NVGRE item");
> + return -rte_errno;
> + }
> + if (nvgre_spec->c_k_s_rsvd0_ver !=
> + rte_cpu_to_be_16(0x2000) &&
> + nvgre_mask->c_k_s_rsvd0_ver) {
> + rte_flow_error_set(error, EINVAL,
> +RTE_FLOW_ERROR_TYPE_ITEM,
> +item,
> +"Invalid NVGRE item");
> + return -rte_errno;
> + }
> + if (nvgre_mask->protocol &&
> + nvgre_spec->protocol !=
> + rte_cpu_to_be_16(0x6558)) {
> + rte_flow_error_set(error, EINVAL,
> +RTE_FLOW_ERROR_TYPE_ITEM,
> +item,
> +"Invalid NVGRE item");
> + return -rte_errno;
> + }
> rte_memcpy(((uint8_t *)&tenant_id_be + 1),
> nvgre_spec->tni, 3);
> filter->tenant_id =
> --
> 2.9.3
Re: [dpdk-dev] [PATCH] debug: update assertion macro
On 12/15/2017 11:56 AM, Ferruh Yigit wrote:
> On 11/19/2017 6:41 AM, Ilya Matveychikov wrote:
>>
>>
>>> On Nov 19, 2017, at 12:18 PM, Ilya Matveychikov
>>> wrote:
>>>
>>> Update RTE_VERIFY macro to make it possible to use complex expressions
>>> in RTE_ASSERT.
>>>
>>> Signed-off-by: Ilya V. Matveychikov
>>>
>>> Fixes: 148f963fb532 ("xen: core library changes")
>>> Cc: bruce.richard...@intel.com
>>>
>>> ---
>>> Now it's incorrect to use complex expressions for assertion
>>> like RTE_ASSERT((1 + 2) == 3). This patch makes it possible.
>>
>> Update.
>>
>> Now it’s possible to have % char inside the expression, for example:
>>
>> RTE_ASSERT((sizeof(some_struct) % 64) == 0)
>>
>> Before the patch, “%" sign acts like a conversion specification beginning
>> character.
>
> previous sample is not correct, complex expressions "RTE_ASSERT((1 + 2) == 3)"
> are working fine.
> But you are right "%" causing problem, and this patch is fixing it.
>
> Reviewed-by: Ferruh Yigit
Applied to dpdk/master, thanks.
Note added into commit log.
Re: [dpdk-dev] [PATCH] net/i40e: remove forward declaraion of i40e_xmit_pkts_simple
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Rami Rosen > Sent: Monday, November 27, 2017 3:26 AM > To: dev@dpdk.org > Cc: Wu, Jingjing; Xing, Beilei; Rosen, Rami > Subject: [dpdk-dev] [PATCH] net/i40e: remove forward declaraion of > i40e_xmit_pkts_simple > > This trivial patch removes unnecessary forward decalartion of > i40e_xmit_pkts_simple() in i40e_rxtx.c. > > Signed-off-by: Rami Rosen Acked-by: Helin Zhang
[dpdk-dev] [PATCH] bus/dpaa/base: fix build when assert enabled
Enabling CONFIG_RTE_ENABLE_ASSERT cause build error because some fields
protected by RTE_LIBRTE_DPAA_HWDEBUG macro accessed within DPAA_ASSERT.
All DPAA_ASSERT macro usage causing the build error wrapped with
RTE_LIBRTE_DPAA_HWDEBUG macro.
Fixes: f38f61e982f8 ("bus/dpaa: add BMAN hardware interfaces")
Fixes: c47ff048b99a ("bus/dpaa: add QMAN driver core routines")
Cc: shreyansh.j...@nxp.com
Cc: sta...@dpdk.org
Signed-off-by: Ferruh Yigit
---
This was to quickly fix the build, please feel free to re-make the
patch if necessary.
---
drivers/bus/dpaa/base/qbman/bman.h | 32 ---
drivers/bus/dpaa/base/qbman/qman.c | 5 +++
drivers/bus/dpaa/base/qbman/qman.h | 64 --
3 files changed, 94 insertions(+), 7 deletions(-)
diff --git a/drivers/bus/dpaa/base/qbman/bman.h
b/drivers/bus/dpaa/base/qbman/bman.h
index 4b088da93..ef0a896ec 100644
--- a/drivers/bus/dpaa/base/qbman/bman.h
+++ b/drivers/bus/dpaa/base/qbman/bman.h
@@ -228,7 +228,9 @@ static inline void bm_rcr_finish(struct bm_portal *portal)
u8 pi = bm_in(RCR_PI_CINH) & (BM_RCR_SIZE - 1);
u8 ci = bm_in(RCR_CI_CINH) & (BM_RCR_SIZE - 1);
+#ifdef RTE_LIBRTE_DPAA_HWDEBUG
DPAA_ASSERT(!rcr->busy);
+#endif
if (pi != RCR_PTR2IDX(rcr->cursor))
pr_crit("losing uncommitted RCR entries\n");
if (ci != rcr->ci)
@@ -241,7 +243,9 @@ static inline struct bm_rcr_entry *bm_rcr_start(struct
bm_portal *portal)
{
register struct bm_rcr *rcr = &portal->rcr;
+#ifdef RTE_LIBRTE_DPAA_HWDEBUG
DPAA_ASSERT(!rcr->busy);
+#endif
if (!rcr->available)
return NULL;
#ifdef RTE_LIBRTE_DPAA_HWDEBUG
@@ -255,8 +259,8 @@ static inline void bm_rcr_abort(struct bm_portal *portal)
{
__maybe_unused register struct bm_rcr *rcr = &portal->rcr;
- DPAA_ASSERT(rcr->busy);
#ifdef RTE_LIBRTE_DPAA_HWDEBUG
+ DPAA_ASSERT(rcr->busy);
rcr->busy = 0;
#endif
}
@@ -266,8 +270,10 @@ static inline struct bm_rcr_entry *bm_rcr_pend_and_next(
{
register struct bm_rcr *rcr = &portal->rcr;
+#ifdef RTE_LIBRTE_DPAA_HWDEBUG
DPAA_ASSERT(rcr->busy);
DPAA_ASSERT(rcr->pmode != bm_rcr_pvb);
+#endif
if (rcr->available == 1)
return NULL;
rcr->cursor->__dont_write_directly__verb = myverb | rcr->vbit;
@@ -282,8 +288,10 @@ static inline void bm_rcr_pci_commit(struct bm_portal
*portal, u8 myverb)
{
register struct bm_rcr *rcr = &portal->rcr;
+#ifdef RTE_LIBRTE_DPAA_HWDEBUG
DPAA_ASSERT(rcr->busy);
DPAA_ASSERT(rcr->pmode == bm_rcr_pci);
+#endif
rcr->cursor->__dont_write_directly__verb = myverb | rcr->vbit;
RCR_INC(rcr);
rcr->available--;
@@ -298,7 +306,9 @@ static inline void bm_rcr_pce_prefetch(struct bm_portal
*portal)
{
__maybe_unused register struct bm_rcr *rcr = &portal->rcr;
+#ifdef RTE_LIBRTE_DPAA_HWDEBUG
DPAA_ASSERT(rcr->pmode == bm_rcr_pce);
+#endif
bm_cl_invalidate(RCR_PI);
bm_cl_touch_rw(RCR_PI);
}
@@ -307,8 +317,10 @@ static inline void bm_rcr_pce_commit(struct bm_portal
*portal, u8 myverb)
{
register struct bm_rcr *rcr = &portal->rcr;
+#ifdef RTE_LIBRTE_DPAA_HWDEBUG
DPAA_ASSERT(rcr->busy);
DPAA_ASSERT(rcr->pmode == bm_rcr_pce);
+#endif
rcr->cursor->__dont_write_directly__verb = myverb | rcr->vbit;
RCR_INC(rcr);
rcr->available--;
@@ -324,8 +336,10 @@ static inline void bm_rcr_pvb_commit(struct bm_portal
*portal, u8 myverb)
register struct bm_rcr *rcr = &portal->rcr;
struct bm_rcr_entry *rcursor;
+#ifdef RTE_LIBRTE_DPAA_HWDEBUG
DPAA_ASSERT(rcr->busy);
DPAA_ASSERT(rcr->pmode == bm_rcr_pvb);
+#endif
lwsync();
rcursor = rcr->cursor;
rcursor->__dont_write_directly__verb = myverb | rcr->vbit;
@@ -342,7 +356,9 @@ static inline u8 bm_rcr_cci_update(struct bm_portal *portal)
register struct bm_rcr *rcr = &portal->rcr;
u8 diff, old_ci = rcr->ci;
+#ifdef RTE_LIBRTE_DPAA_HWDEBUG
DPAA_ASSERT(rcr->cmode == bm_rcr_cci);
+#endif
rcr->ci = bm_in(RCR_CI_CINH) & (BM_RCR_SIZE - 1);
diff = bm_cyc_diff(BM_RCR_SIZE, old_ci, rcr->ci);
rcr->available += diff;
@@ -353,7 +369,9 @@ static inline void bm_rcr_cce_prefetch(struct bm_portal
*portal)
{
__maybe_unused register struct bm_rcr *rcr = &portal->rcr;
+#ifdef RTE_LIBRTE_DPAA_HWDEBUG
DPAA_ASSERT(rcr->cmode == bm_rcr_cce);
+#endif
bm_cl_touch_ro(RCR_CI);
}
@@ -362,7 +380,9 @@ static inline u8 bm_rcr_cce_update(struct bm_portal *portal)
register struct bm_rcr *rcr = &portal->rcr;
u8 diff, old_ci = rcr->ci;
+#ifdef RTE_LIBRTE_DPAA_HWDEBUG
DPAA_ASSERT(rcr->cmode == bm_rcr_cce);
+#endif
rcr->ci = bm_cl_in(RCR_CI) & (BM_RCR_SIZE - 1);
bm_cl_invalidate(RCR_CI);
diff = bm_cyc_diff(BM_RCR_SIZE, old_ci, rcr->ci);
@@ -420,8 +440,8 @@ static
Re: [dpdk-dev] [PATCH] net/i40e: add fdir nvgre parameters check
Hi，zhangqi
> -Original Message-
> From: Zhang, Qi Z
> Sent: Friday, December 22, 2017 10:11 AM
> To: Zhao1, Wei ; dev@dpdk.org
> Cc: Lu, Wenzhuo ; Xing, Beilei
> ; Zhao1, Wei
> Subject: RE: [dpdk-dev] [PATCH] net/i40e: add fdir nvgre parameters check
>
>
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Zhao
> > Sent: Friday, December 1, 2017 4:47 PM
> > To: dev@dpdk.org
> > Cc: Lu, Wenzhuo ; Xing, Beilei
> > ; Zhao1, Wei
> > Subject: [dpdk-dev] [PATCH] net/i40e: add fdir nvgre parameters check
> >
> > Add mask parameters check in nvgre parser for flow API.
> >
> > Fixes: 30965ca341278 ("net/i40e: add NVGRE flow parsing")
> >
> > Signed-off-by: Wei Zhao
> > ---
> > drivers/net/i40e/i40e_flow.c | 35
> +++
> > 1 file changed, 35 insertions(+)
> >
> > diff --git a/drivers/net/i40e/i40e_flow.c
> > b/drivers/net/i40e/i40e_flow.c index
> > 7e4936e..05e54f1 100644
> > --- a/drivers/net/i40e/i40e_flow.c
> > +++ b/drivers/net/i40e/i40e_flow.c
> > @@ -3610,6 +3610,41 @@ i40e_flow_parse_nvgre_pattern(__rte_unused
> > struct rte_eth_dev *dev,
> >"Invalid TNI mask");
> > return -rte_errno;
> > }
> > + if (nvgre_mask->protocol &&
> > + nvgre_mask->protocol != 0x) {
> > + rte_flow_error_set(error, EINVAL,
> > +
> RTE_FLOW_ERROR_TYPE_ITEM,
> > + item,
> > + "Invalid NVGRE item");
> > + return -rte_errno;
> > + }
> > + if (nvgre_mask->c_k_s_rsvd0_ver &&
> > + nvgre_mask->c_k_s_rsvd0_ver !=
> > + rte_cpu_to_be_16(0x3000)) {
>
> If " c_k_s_rsvd0_ver must have value 0x2000 according to RFC 7637" , I think
> here we should have mask 0x to make sure each bit of c_k_s_rsvd0_ver
> be set correctly.
>
Yes, our old code is as your suggestion, but testpmd can not support config
that parameter
,if that stv can not test this feature.
so, we did a balance.
> Regards
> Qi
> > + rte_flow_error_set(error, EINVAL,
> > +
> RTE_FLOW_ERROR_TYPE_ITEM,
> > + item,
> > + "Invalid NVGRE item");
> > + return -rte_errno;
> > + }
> > + if (nvgre_spec->c_k_s_rsvd0_ver !=
> > + rte_cpu_to_be_16(0x2000) &&
> > + nvgre_mask->c_k_s_rsvd0_ver) {
> > + rte_flow_error_set(error, EINVAL,
> > +
> RTE_FLOW_ERROR_TYPE_ITEM,
> > + item,
> > + "Invalid NVGRE item");
> > + return -rte_errno;
> > + }
> > + if (nvgre_mask->protocol &&
> > + nvgre_spec->protocol !=
> > + rte_cpu_to_be_16(0x6558)) {
> > + rte_flow_error_set(error, EINVAL,
> > +
> RTE_FLOW_ERROR_TYPE_ITEM,
> > + item,
> > + "Invalid NVGRE item");
> > + return -rte_errno;
> > + }
> > rte_memcpy(((uint8_t *)&tenant_id_be + 1),
> >nvgre_spec->tni, 3);
> > filter->tenant_id =
> > --
> > 2.9.3
Re: [dpdk-dev] [RFC PATCH 0/3] configurable max queue number per VF
On 7/31/2017 12:27 PM, Wenzhuo Lu wrote: > Currently, on i40e, the max queue number per VF is set by a macro. > It means the value is decided when compiling. It's not friendly to > the users. Because every time the users want to change the value, > the code need to be re-compiled. > > The reason of using a macro for the max queue number is that the > number is needed at the very early stage. At this stage, we haven't > got the device configuration yet. > There's a simple idea to replace the macro by a global varialbe. > Then the users can set the value without compiling the code again > and again. > > This patch set implements this idea and is an example to show how > to use it. > > Wenzhuo Lu (3): > librte_ether: VF max queue number setting > net/i40e: max VF queue number setting > app/testpmd: a parameter to set max queue per VF RFC seems superseded by https://dpdk.org/dev/patchwork/patch/31996/, updating status of set as superseded.
Re: [dpdk-dev] [PATCH] net/i40e: add fdir nvgre parameters check
Hi，zhangqi
> -Original Message-
> From: Zhang, Qi Z
> Sent: Friday, December 22, 2017 10:11 AM
> To: Zhao1, Wei ; dev@dpdk.org
> Cc: Lu, Wenzhuo ; Xing, Beilei
> ; Zhao1, Wei
> Subject: RE: [dpdk-dev] [PATCH] net/i40e: add fdir nvgre parameters check
>
>
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Zhao
> > Sent: Friday, December 1, 2017 4:47 PM
> > To: dev@dpdk.org
> > Cc: Lu, Wenzhuo ; Xing, Beilei
> > ; Zhao1, Wei
> > Subject: [dpdk-dev] [PATCH] net/i40e: add fdir nvgre parameters check
> >
> > Add mask parameters check in nvgre parser for flow API.
> >
> > Fixes: 30965ca341278 ("net/i40e: add NVGRE flow parsing")
> >
> > Signed-off-by: Wei Zhao
> > ---
> > drivers/net/i40e/i40e_flow.c | 35
> +++
> > 1 file changed, 35 insertions(+)
> >
> > diff --git a/drivers/net/i40e/i40e_flow.c
> > b/drivers/net/i40e/i40e_flow.c index
> > 7e4936e..05e54f1 100644
> > --- a/drivers/net/i40e/i40e_flow.c
> > +++ b/drivers/net/i40e/i40e_flow.c
> > @@ -3610,6 +3610,41 @@ i40e_flow_parse_nvgre_pattern(__rte_unused
> > struct rte_eth_dev *dev,
> >"Invalid TNI mask");
> > return -rte_errno;
> > }
> > + if (nvgre_mask->protocol &&
> > + nvgre_mask->protocol != 0x) {
> > + rte_flow_error_set(error, EINVAL,
> > +
> RTE_FLOW_ERROR_TYPE_ITEM,
> > + item,
> > + "Invalid NVGRE item");
> > + return -rte_errno;
> > + }
> > + if (nvgre_mask->c_k_s_rsvd0_ver &&
> > + nvgre_mask->c_k_s_rsvd0_ver !=
> > + rte_cpu_to_be_16(0x3000)) {
>
> If " c_k_s_rsvd0_ver must have value 0x2000 according to RFC 7637" , I think
> here we should have mask 0x to make sure each bit of c_k_s_rsvd0_ver
> be set correctly.
I will change c_k_s_rsvd0_ver mask check to 0X, may be that is more
reasonable.
>
> Regards
> Qi
> > + rte_flow_error_set(error, EINVAL,
> > +
> RTE_FLOW_ERROR_TYPE_ITEM,
> > + item,
> > + "Invalid NVGRE item");
> > + return -rte_errno;
> > + }
> > + if (nvgre_spec->c_k_s_rsvd0_ver !=
> > + rte_cpu_to_be_16(0x2000) &&
> > + nvgre_mask->c_k_s_rsvd0_ver) {
> > + rte_flow_error_set(error, EINVAL,
> > +
> RTE_FLOW_ERROR_TYPE_ITEM,
> > + item,
> > + "Invalid NVGRE item");
> > + return -rte_errno;
> > + }
> > + if (nvgre_mask->protocol &&
> > + nvgre_spec->protocol !=
> > + rte_cpu_to_be_16(0x6558)) {
> > + rte_flow_error_set(error, EINVAL,
> > +
> RTE_FLOW_ERROR_TYPE_ITEM,
> > + item,
> > + "Invalid NVGRE item");
> > + return -rte_errno;
> > + }
> > rte_memcpy(((uint8_t *)&tenant_id_be + 1),
> >nvgre_spec->tni, 3);
> > filter->tenant_id =
> > --
> > 2.9.3
Re: [dpdk-dev] [PATCH] ethdev: remove useless parameter in callback process
On 11/28/2017 2:09 PM, Thomas Monjalon wrote:
> The pointer to the user parameter of the callback registration is
> automatically pass to the callback function.
> There is no point to allow changing this user parameter by a caller.
> That's why this parameter is always set to NULL by PMDs and set only
> in ethdev layer before calling the callback function.
It can be helpful to mention a little from history:
user cb_arg overwrite introduced by [1], to enable driver pass a pointer to user
callback function and carry some information back from app to driver.
Later to prevent usage of cb_arg as both input and output, an explicit output
(ret_param) added [2] to _rte_eth_dev_callback_process() but previous cb_arg
overwriting kept without any user.
[1]: c1ceaf3ad056 ("ethdev: add an argument to internal callback function")
[2]: d6af1a13d7a1 ("ethdev: add return values to callback process API")
>
> The NULL parameter in the internal callback processing function
> is now removed. It makes clear that the callback parameter is user
> managed and opaque from a DPDK point of view.
>
> Signed-off-by: Thomas Monjalon
Reviewed-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH] ethdev: add notifications for probing and removal
On 11/28/2017 2:13 PM, Thomas Monjalon wrote: > When a PMD finishes probing, it creates the new port by calling > the function rte_eth_dev_allocate(). > A notification of the new port is sent there to the upper layer. > > When a PMD finishes removal of a port, it calls the function > rte_eth_dev_release_port(). > A notification of the destroyed port is sent there to the upper layer. > > Signed-off-by: Thomas Monjalon Reviewed-by: Ferruh Yigit > --- > > This patch depends on: > - ethdev: remove useless parameter in callback process > - ethdev: free a port by a dedicated API What do you think pulling that patch from port ownership patchset, which is still under discussion, to this one? Is it required for port ownership one?
Re: [dpdk-dev] [PATCH] doc: add queue region feature info to release notes
On 12/21/2017 5:36 PM, Zhao1, Wei wrote: > Ok, this will be updating in release notes for v18.02, > and have a mention that this feature has been implemented in v17.11? I think mentioning from first implemented release helps to reduce confusion, in case users interested in implementation details etc... But no strong opinion. > > > >> -Original Message- >> From: Yigit, Ferruh >> Sent: Friday, December 22, 2017 2:10 AM >> To: Zhao1, Wei ; dev@dpdk.org >> Cc: Mcnamara, John >> Subject: Re: [dpdk-dev] [PATCH] doc: add queue region feature info to >> release notes >> >> On 12/20/2017 7:52 PM, Wei Zhao wrote: >>> This patch add inforation about i40e queue region realted to release >>> notes, it has been missed before. >>> >>> Signed-off-by: Wei Zhao >>> --- >>> doc/guides/rel_notes/release_17_11.rst | 17 + >> >> I think we shouldn't update release notes once it has been released. >> >> Perhaps it can be an option to mention from this in latest release notes with >> a note that says actual support added in v17.11?
