Re: [dpdk-dev] using rte_flow via tespmd with Intel X552
Hi, Adrien > -Original Message- > From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com] > Sent: Wednesday, August 2, 2017 9:41 PM > To: Lu, Wenzhuo > Cc: Zhao1, Wei ; TETSURO NAKAMURA > ; Mcnamara, John > ; TAKADA Naoki ; > Satoshi NISHIYAMA ; dev@dpdk.org > Subject: Re: using rte_flow via tespmd with Intel X552 > > Hi Wenzhuo, > > On Wed, Aug 02, 2017 at 01:00:47PM +, Lu, Wenzhuo wrote: > > Hi, > > > > > -Original Message- > > > From: Zhao1, Wei > > > Sent: Wednesday, August 2, 2017 3:28 AM > > > To: TETSURO NAKAMURA > > > Cc: TAKADA Naoki ; Satoshi NISHIYAMA > > > ; Lu, Wenzhuo ; > > > dev@dpdk.org > > > Subject: RE: using rte_flow via tespmd with Intel X552 > > > > > > Hi, NAKAMURA > > > > > > I have upload 2 documents about command format when creating flow > > > for NIC igb and ixgbe in the email attachment. > > > I have decided to commit the context in the doc to > > > doc\guides\nics\ixgbe.rst before, BUT by now it seems the content of > > > the document is too much To store there. So, is there any other doc more > suitable in DPDK to record this. > > > And welcome for any other suggestion. > > > AND, Wenzhuo, what is your opinion for this? > > I also have the same feeling that it may make the ixgbe.rst too big. > > + John and Adrien. Hi John, Adrien, I'm think about creating a specific doc > for rte flow, we can include the examples for every NIC here. Is it good? If > so, > where's the good place to put it? Thanks. > > Depends on the kind of examples. Code samples or testpmd flow command? > Unless you mean a document that describes individual rte_flow features > supported by each NIC? > > Code samples could be added to a new "Programming flow rules" (or > something) section in doc/guide/prog_guide/rte_flow.rst. > > Another section about NICs could be added in that documentation as well > but should only contain a short summary for each of them and a link to the > relevant PMD documentation in nics/$PMD.rst (or elsewhere in the DPDK > tree), if any. > > If you want to describe individual rte_flow features supported by each NIC, I > think there's no other choice but to create a bunch of > doc/guides/nics/features/rte_flow/*.ini files. Your suggestion of create a bunch under > doc/guides/nics/features/rte_flow/*.ini to record these for every type of NIC of igb/ixgbe/i40e, It seems very reasonable, but will DPDK community will agree to such a big change for this a specific feature? Maybe your suggestion of "in doc/guide/prog_guide/rte_flow.rst, add a short summary for each of them and a link to the relevant PMD documentation in nics/$PMD.rst ". and also record to doc\guides\nics\ixgbe.rst will be the only feasible scheme? Although it will be too much to store. Wenzhuo and Adrien, If none of you has no objection to this, I will implement as Adrien's first suggestion. Thank you. > > > > > -Original Message- > > > > From: TETSURO NAKAMURA [mailto:nakamura.tets...@lab.ntt.co.jp] > > > > Sent: Wednesday, August 2, 2017 12:22 PM > > > > To: Zhao1, Wei > > > > Cc: TAKADA Naoki ; Satoshi NISHIYAMA > > > > ; Lu, Wenzhuo ; > > > > dev@dpdk.org > > > > Subject: Re: using rte_flow via tespmd with Intel X552 > > > > > > > > Wei Zhao - san > > > > (Cc'ing Wenzhuo - san) > > > > > > > > According to the e-mail thread [1] in April, you have a document > > > > about command format when creating flows on ixgbe NIC. > > > > > > > > I would appreciate your uploading that document to community or > > > > could you just share it with me via an e-mail ?? > > > > > > > > [1] http://dpdk.org/ml/archives/users/2017-April/001786.html > > > > > > > > Thanks, > > > > > > > > Tetsuro > > > > > > > > # re-sending the e-mail because I failed to submit the e-mail to > > > > us...@dpdk.org. > > > > > > > > -- > > > > Tetsuro Nakamura NTT Network > > > > Service Systems Laboratories > > > > TEL:0422 59 6914(National)/+81 422 59 6914(International) 3-9-11, > > > > Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan > > > > > > > > -- > Adrien Mazarguil > 6WIND
[dpdk-dev] [PATCH] net/af_packet: support Tx scattered mbuf input
Signed-off-by: Wenfeng Liu
---
drivers/net/af_packet/rte_eth_af_packet.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
b/drivers/net/af_packet/rte_eth_af_packet.c
index 9a47852..a6cab9b 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -216,7 +216,7 @@ struct pmd_internals {
mbuf = *bufs++;
/* drop oversized packets */
- if (rte_pktmbuf_data_len(mbuf) > pkt_q->frame_data_size) {
+ if (mbuf->pkt_len > pkt_q->frame_data_size) {
rte_pktmbuf_free(mbuf);
continue;
}
@@ -237,8 +237,16 @@ struct pmd_internals {
/* copy the tx frame data */
pbuf = (uint8_t *) ppd + TPACKET2_HDRLEN -
sizeof(struct sockaddr_ll);
- memcpy(pbuf, rte_pktmbuf_mtod(mbuf, void*),
rte_pktmbuf_data_len(mbuf));
- ppd->tp_len = ppd->tp_snaplen = rte_pktmbuf_data_len(mbuf);
+
+ struct rte_mbuf *tmp_mbuf = mbuf;
+ while(tmp_mbuf) {
+ uint16_t data_len = rte_pktmbuf_data_len(tmp_mbuf);
+ memcpy(pbuf, rte_pktmbuf_mtod(tmp_mbuf, void*),
data_len);
+ pbuf += data_len;
+ tmp_mbuf = tmp_mbuf->next;
+ }
+
+ ppd->tp_len = ppd->tp_snaplen = mbuf->pkt_len;
/* release incoming frame and advance ring buffer */
ppd->tp_status = TP_STATUS_SEND_REQUEST;
--
1.8.3.1
[dpdk-dev] [PATCH v2] net/af_packet: support Tx scattered mbuf input
Signed-off-by: Wenfeng Liu
---
v2:
* Fixed coding style issues reported by checkpatch
drivers/net/af_packet/rte_eth_af_packet.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
b/drivers/net/af_packet/rte_eth_af_packet.c
index 9a47852..fabb915 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -216,7 +216,7 @@ struct pmd_internals {
mbuf = *bufs++;
/* drop oversized packets */
- if (rte_pktmbuf_data_len(mbuf) > pkt_q->frame_data_size) {
+ if (mbuf->pkt_len > pkt_q->frame_data_size) {
rte_pktmbuf_free(mbuf);
continue;
}
@@ -237,8 +237,17 @@ struct pmd_internals {
/* copy the tx frame data */
pbuf = (uint8_t *) ppd + TPACKET2_HDRLEN -
sizeof(struct sockaddr_ll);
- memcpy(pbuf, rte_pktmbuf_mtod(mbuf, void*),
rte_pktmbuf_data_len(mbuf));
- ppd->tp_len = ppd->tp_snaplen = rte_pktmbuf_data_len(mbuf);
+
+ struct rte_mbuf *tmp_mbuf = mbuf;
+ while (tmp_mbuf) {
+ uint16_t data_len = rte_pktmbuf_data_len(tmp_mbuf);
+ memcpy(pbuf, rte_pktmbuf_mtod(tmp_mbuf, void*),
data_len);
+ pbuf += data_len;
+ tmp_mbuf = tmp_mbuf->next;
+ }
+
+ ppd->tp_len = mbuf->pkt_len;
+ ppd->tp_snaplen = mbuf->pkt_len;
/* release incoming frame and advance ring buffer */
ppd->tp_status = TP_STATUS_SEND_REQUEST;
--
1.8.3.1
[dpdk-dev] [PATCH v3] net/af_packet: support Tx scattered mbuf input
Signed-off-by: Wenfeng Liu
---
v3:
* Remove trailing whitespace
v2:
* Fixed coding style issues reported by checkpatch
drivers/net/af_packet/rte_eth_af_packet.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
b/drivers/net/af_packet/rte_eth_af_packet.c
index 9a47852..7aa26e5 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -216,7 +216,7 @@ struct pmd_internals {
mbuf = *bufs++;
/* drop oversized packets */
- if (rte_pktmbuf_data_len(mbuf) > pkt_q->frame_data_size) {
+ if (mbuf->pkt_len > pkt_q->frame_data_size) {
rte_pktmbuf_free(mbuf);
continue;
}
@@ -237,8 +237,17 @@ struct pmd_internals {
/* copy the tx frame data */
pbuf = (uint8_t *) ppd + TPACKET2_HDRLEN -
sizeof(struct sockaddr_ll);
- memcpy(pbuf, rte_pktmbuf_mtod(mbuf, void*),
rte_pktmbuf_data_len(mbuf));
- ppd->tp_len = ppd->tp_snaplen = rte_pktmbuf_data_len(mbuf);
+
+ struct rte_mbuf *tmp_mbuf = mbuf;
+ while (tmp_mbuf) {
+ uint16_t data_len = rte_pktmbuf_data_len(tmp_mbuf);
+ memcpy(pbuf, rte_pktmbuf_mtod(tmp_mbuf, void*),
data_len);
+ pbuf += data_len;
+ tmp_mbuf = tmp_mbuf->next;
+ }
+
+ ppd->tp_len = mbuf->pkt_len;
+ ppd->tp_snaplen = mbuf->pkt_len;
/* release incoming frame and advance ring buffer */
ppd->tp_status = TP_STATUS_SEND_REQUEST;
--
1.8.3.1
[dpdk-dev] [RFC PATCH 1/4] ethdev: rename Rx and Tx configuration structs
Rename the structs rte_eth_txconf and rte_eth_rxconf to
rte_eth_txq_conf and rte_eth_rxq_conf respectively as those
structs represent per queue configuration.
Signed-off-by: Shahaf Shuler
---
lib/librte_ether/rte_ethdev.c | 4 ++--
lib/librte_ether/rte_ethdev.h | 24 +---
2 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index d4ebb1b67..f73307e99 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1006,7 +1006,7 @@ rte_eth_dev_close(uint8_t port_id)
int
rte_eth_rx_queue_setup(uint8_t port_id, uint16_t rx_queue_id,
uint16_t nb_rx_desc, unsigned int socket_id,
- const struct rte_eth_rxconf *rx_conf,
+ const struct rte_eth_rxq_conf *rx_conf,
struct rte_mempool *mp)
{
int ret;
@@ -1097,7 +1097,7 @@ rte_eth_rx_queue_setup(uint8_t port_id, uint16_t
rx_queue_id,
int
rte_eth_tx_queue_setup(uint8_t port_id, uint16_t tx_queue_id,
uint16_t nb_tx_desc, unsigned int socket_id,
- const struct rte_eth_txconf *tx_conf)
+ const struct rte_eth_txq_conf *tx_conf)
{
struct rte_eth_dev *dev;
struct rte_eth_dev_info dev_info;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 0e99090f6..f7a44578c 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -686,7 +686,7 @@ struct rte_eth_txmode {
/**
* A structure used to configure an RX ring of an Ethernet port.
*/
-struct rte_eth_rxconf {
+struct rte_eth_rxq_conf {
struct rte_eth_thresh rx_thresh; /**< RX ring threshold registers. */
uint16_t rx_free_thresh; /**< Drives the freeing of RX descriptors. */
uint8_t rx_drop_en; /**< Drop packets if no descriptors are available.
*/
@@ -709,7 +709,7 @@ struct rte_eth_rxconf {
/**
* A structure used to configure a TX ring of an Ethernet port.
*/
-struct rte_eth_txconf {
+struct rte_eth_txq_conf {
struct rte_eth_thresh tx_thresh; /**< TX ring threshold registers. */
uint16_t tx_rs_thresh; /**< Drives the setting of RS bit on TXDs. */
uint16_t tx_free_thresh; /**< Start freeing TX buffers if there are
@@ -956,8 +956,10 @@ struct rte_eth_dev_info {
uint8_t hash_key_size; /**< Hash key size in bytes */
/** Bit mask of RSS offloads, the bit offset also means flow type */
uint64_t flow_type_rss_offloads;
- struct rte_eth_rxconf default_rxconf; /**< Default RX configuration */
- struct rte_eth_txconf default_txconf; /**< Default TX configuration */
+ struct rte_eth_rxq_conf default_rx_conf;
+ /**< Default RX queue configuration */
+ struct rte_eth_txq_conf default_tx_conf;
+ /**< Default TX queue configuration */
uint16_t vmdq_queue_base; /**< First queue ID for VMDQ pools. */
uint16_t vmdq_queue_num; /**< Queue number for VMDQ pools. */
uint16_t vmdq_pool_base; /**< First ID of VMDQ pools. */
@@ -975,7 +977,7 @@ struct rte_eth_dev_info {
*/
struct rte_eth_rxq_info {
struct rte_mempool *mp; /**< mempool used by that queue. */
- struct rte_eth_rxconf conf; /**< queue config parameters. */
+ struct rte_eth_rxq_conf conf; /**< queue config parameters. */
uint8_t scattered_rx; /**< scattered packets RX supported. */
uint16_t nb_desc; /**< configured number of RXDs. */
} __rte_cache_min_aligned;
@@ -985,7 +987,7 @@ struct rte_eth_rxq_info {
* Used to retieve information about configured queue.
*/
struct rte_eth_txq_info {
- struct rte_eth_txconf conf; /**< queue config parameters. */
+ struct rte_eth_txq_conf conf; /**< queue config parameters. */
uint16_t nb_desc; /**< configured number of TXDs. */
} __rte_cache_min_aligned;
@@ -1185,7 +1187,7 @@ typedef int (*eth_rx_queue_setup_t)(struct rte_eth_dev
*dev,
uint16_t rx_queue_id,
uint16_t nb_rx_desc,
unsigned int socket_id,
- const struct rte_eth_rxconf *rx_conf,
+ const struct rte_eth_rxq_conf *rx_conf,
struct rte_mempool *mb_pool);
/**< @internal Set up a receive queue of an Ethernet device. */
@@ -1193,7 +1195,7 @@ typedef int (*eth_tx_queue_setup_t)(struct rte_eth_dev
*dev,
uint16_t tx_queue_id,
uint16_t nb_tx_desc,
unsigned int socket_id,
- const struct rte_eth_txconf *tx_conf);
+ const struct rte_eth_txq_conf *tx_conf);
/**< @internal Setup a transmit queue of an Ethernet device. */
typedef int (*eth_r
[dpdk-dev] [RFC PATCH 0/4] ethdev new offloads API
Tx offloads configuration is per queue. Tx offloads are enabled by default, and can be disabled using ETH_TXQ_FLAGS_NO* flags. This behaviour is not consistent with the Rx side where the Rx offloads configuration is per port. Rx offloads are disabled by default and enabled according to bit field in rte_eth_rxmode structure. Moreover, considering more Tx and Rx offloads will be added over time, the cost of managing them all inside the PMD will be tremendous, as the PMD will need to check the matching for the entire offload set for each mbuf it handles. In addition, on the current approach each Rx offload added breaks the ABI compatibility as it requires to add entries to existing bit-fields. The RFC address above issues by defining a new offloads API. With the new API, Tx and Rx offloads configuration is per queue. The offloads are disabled by default. Each offload can be enabled or disabled using the existing DEV_TX_OFFLOADS_* or DEV_RX_OFFLOADS_* flags. Such API will enable to easily add or remove offloads, without breaking the ABI compatibility. The new API does not have an equivalent for the below Tx flags: * ETH_TXQ_FLAGS_NOREFCOUNT * ETH_TXQ_FLAGS_NOMULTMEMP The reason is that those flags are not to manage offloads, rather some guarantee from application on the way it uses mbufs, therefore could not be present as part of DEV_TX_OFFLOADS_*. Such flags are useful only for benchmarks, and therefore provide a non-realistic performance for DPDK customers using simple benchmarks for evaluation. Leveraging the work being done in this series to clean up those flags. In order to provide a smooth transition between the APIs the following actions were taken: * The old offloads API is kept for the meanwhile. * New capabilities were added for PMD to advertize it has moved to the new offloads API. * Helper function which copy from old to new API and vice versa were added to ethdev, enabling the PMD to support only one of the APIs, and the application to move to the new API regardless the underlying device and without extra branching. Shahaf Shuler (4): ethdev: rename Rx and Tx configuration structs ethdev: introduce Rx queue offloads API ethdev: introduce Tx queue offloads API ethdev: add helpers to move to the new offloads API lib/librte_ether/rte_ethdev.c | 144 - lib/librte_ether/rte_ethdev.h | 72 +++ 2 files changed, 202 insertions(+), 14 deletions(-) -- 2.12.0
[dpdk-dev] [RFC PATCH 2/4] ethdev: introduce Rx queue offloads API
Introduce a new API to configure Rx offloads.
The new API will re-use existing DEV_RX_OFFLOAD_* flags
to enable the different offloads. This will ease the process
of adding a new Rx offloads, as no ABI breakage is involved.
In addition, the offload configuration can be done per queue,
instead of per port.
The Rx queue offload API can be used only with devices which advertize
the RTE_ETH_DEV_RXQ_OFFLOAD capability.
The old Rx offloads API is kept for the meanwhile, in order to enable a
smooth transition for PMDs and application to the new API.
Signed-off-by: Shahaf Shuler
---
lib/librte_ether/rte_ethdev.h | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index f7a44578c..ce33c61c4 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -357,7 +357,14 @@ struct rte_eth_rxmode {
jumbo_frame : 1, /**< Jumbo Frame Receipt enable. */
hw_strip_crc : 1, /**< Enable CRC stripping by hardware. */
enable_scatter : 1, /**< Enable scatter packets rx handler */
- enable_lro : 1; /**< Enable LRO */
+ enable_lro : 1, /**< Enable LRO */
+ ignore : 1;
+ /**
+* When set the rxmode offloads should be ignored,
+* instead the Rx offloads will be set on rte_eth_rxq_conf.
+* This bit is temporary till rxmode Rx offloads API will
+* be deprecated.
+*/
};
/**
@@ -691,6 +698,12 @@ struct rte_eth_rxq_conf {
uint16_t rx_free_thresh; /**< Drives the freeing of RX descriptors. */
uint8_t rx_drop_en; /**< Drop packets if no descriptors are available.
*/
uint8_t rx_deferred_start; /**< Do not start queue with
rte_eth_dev_start(). */
+ uint64_t offloads;
+ /**
+* Enable Rx offloads using DEV_RX_OFFLOAD_* flags.
+* Supported only for devices which advertize the
+* RTE_ETH_DEV_RXQ_OFFLOAD capability.
+*/
};
#define ETH_TXQ_FLAGS_NOMULTSEGS 0x0001 /**< nb_segs=1 for all mbufs */
@@ -907,6 +920,19 @@ struct rte_eth_conf {
#define DEV_RX_OFFLOAD_QINQ_STRIP 0x0020
#define DEV_RX_OFFLOAD_OUTER_IPV4_CKSUM 0x0040
#define DEV_RX_OFFLOAD_MACSEC_STRIP 0x0080
+#define DEV_RX_OFFLOAD_HEADER_SPLIT0x0100
+#define DEV_RX_OFFLOAD_VLAN_FILTER 0x0200
+#define DEV_RX_OFFLOAD_VLAN_EXTEND 0x0400
+#define DEV_RX_OFFLOAD_JUMBO_FRAME 0x0800
+#define DEV_RX_OFFLOAD_CRC_STRIP 0x1000
+#define DEV_RX_OFFLOAD_SCATTER 0x2000
+#define DEV_RX_OFFLOAD_LRO 0x4000
+#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \
+DEV_RX_OFFLOAD_UDP_CKSUM | \
+DEV_RX_OFFLOAD_TCP_CKSUM)
+#define DEV_RX_OFFLOAD_VLAN (DEV_RX_OFFLOAD_VLAN_STRIP | \
+DEV_RX_OFFLOAD_VLAN_FILTER | \
+DEV_RX_OFFLOAD_VLAN_EXTEND)
/**
* TX offload capabilities of a device.
@@ -1723,6 +1749,8 @@ struct rte_eth_dev_data {
#define RTE_ETH_DEV_BONDED_SLAVE 0x0004
/** Device supports device removal interrupt */
#define RTE_ETH_DEV_INTR_RMV 0x0008
+/** Device supports the rte_eth_rxq_conf offloads API */
+#define RTE_ETH_DEV_RXQ_OFFLOAD 0x0010
/**
* @internal
--
2.12.0
[dpdk-dev] [RFC PATCH 3/4] ethdev: introduce Tx queue offloads API
Introduce a new API to configure Tx offloads.
The new API will re-use existing DEV_TX_OFFLOAD_* flags
to enable the different offloads. This will ease the process
of adding a new Tx offloads, as no ABI breakage is involved.
In addition, the Tx offloads will be disabled by default and be
enabled per application needs. This will much simplify PMD management of
the different offloads.
The new API does not have an equivalent for the below, benchmark
specific, flags:
ETH_TXQ_FLAGS_NOREFCOUNT
ETH_TXQ_FLAGS_NOMULTMEMP
The Tx queue offload API can be used only with devices which advertize
the RTE_ETH_DEV_TXQ_OFFLOAD capability.
The old Tx offloads API is kept for the meanwhile, in order to enable a
smooth transition for PMDs and application to the new API.
Signed-off-by: Shahaf Shuler
---
lib/librte_ether/rte_ethdev.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index ce33c61c4..fd17ee81e 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -719,6 +719,14 @@ struct rte_eth_rxq_conf {
#define ETH_TXQ_FLAGS_NOXSUMS \
(ETH_TXQ_FLAGS_NOXSUMSCTP | ETH_TXQ_FLAGS_NOXSUMUDP | \
ETH_TXQ_FLAGS_NOXSUMTCP)
+#define ETH_TXQ_FLAGS_IGNORE 0x8000
+ /**
+* When set the txq_flags should be ignored,
+* instead the Tx offloads will be set on offloads field
+* located on rte_eth_txq_conf struct.
+* This flag is temporary till the rte_eth_txq_conf.txq_flags
+* API will be deprecated.
+*/
/**
* A structure used to configure a TX ring of an Ethernet port.
*/
@@ -730,6 +738,12 @@ struct rte_eth_txq_conf {
uint32_t txq_flags; /**< Set flags for the Tx queue */
uint8_t tx_deferred_start; /**< Do not start queue with
rte_eth_dev_start(). */
+ uint64_t offloads;
+ /**
+* Enable Tx offloads using DEV_TX_OFFLOAD_* flags.
+* Supported only for devices which advertize the
+* RTE_ETH_DEV_TXQ_OFFLOAD capability.
+*/
};
/**
@@ -955,6 +969,8 @@ struct rte_eth_conf {
/**< Multiple threads can invoke rte_eth_tx_burst() concurrently on the same
* tx queue without SW lock.
*/
+#define DEV_TX_OFFLOAD_MULTI_SEGS 0x8000
+/**< multi segment send is supported. */
struct rte_pci_device;
@@ -1751,6 +1767,8 @@ struct rte_eth_dev_data {
#define RTE_ETH_DEV_INTR_RMV 0x0008
/** Device supports the rte_eth_rxq_conf offloads API */
#define RTE_ETH_DEV_RXQ_OFFLOAD 0x0010
+/** Device supports the rte_eth_txq_conf offloads API */
+#define RTE_ETH_DEV_TXQ_OFFLOAD 0x0020
/**
* @internal
--
2.12.0
[dpdk-dev] [RFC PATCH 4/4] ethdev: add helpers to move to the new offloads API
A new offloads API was introduced by commits:
commit 8b07fcae6061 ("ethdev: introduce Tx queue offloads API")
commit c6504557763e ("ethdev: introduce Rx queue offloads API")
In order to enable PMDs to support only one of the APIs,
and applications to avoid branching according to the underlying device
a copy functions to/from the old/new APIs were added.
Signed-off-by: Shahaf Shuler
---
lib/librte_ether/rte_ethdev.c | 140 +
1 file changed, 140 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index f73307e99..2b4a28c97 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1003,6 +1003,63 @@ rte_eth_dev_close(uint8_t port_id)
dev->data->tx_queues = NULL;
}
+/**
+ * A copy function from rxmode offloads API to rte_eth_rxq_conf
+ * offloads API, to enable PMDs to support only one of the APIs.
+ */
+static void
+rte_eth_copy_rxmode_offloads(struct rte_eth_rxmode *rxmode,
+struct rte_eth_rxq_conf *rxq_conf)
+{
+ if (rxmode->header_split == 1)
+ rxq_conf->offloads |= DEV_RX_OFFLOAD_HEADER_SPLIT;
+ if (rxmode->hw_ip_checksum == 1)
+ rxq_conf->offloads |= DEV_RX_OFFLOAD_CHECKSUM;
+ if (rxmode->hw_vlan_filter == 1)
+ rxq_conf->offloads |= DEV_RX_OFFLOAD_VLAN_FILTER;
+ if (rxmode->hw_vlan_strip == 1)
+ rxq_conf->offloads |= DEV_RX_OFFLOAD_VLAN_STRIP;
+ if (rxmode->hw_vlan_extend == 1)
+ rxq_conf->offloads |= DEV_RX_OFFLOAD_VLAN_EXTEND;
+ if (rxmode->jumbo_frame == 1)
+ rxq_conf->offloads |= DEV_RX_OFFLOAD_JUMBO_FRAME;
+ if (rxmode->hw_strip_crc == 1)
+ rxq_conf->offloads |= DEV_RX_OFFLOAD_CRC_STRIP;
+ if (rxmode->enable_scatter == 1)
+ rxq_conf->offloads |= DEV_RX_OFFLOAD_SCATTER;
+ if (rxmode->enable_lro == 1)
+ rxq_conf->offloads |= DEV_RX_OFFLOAD_LRO;
+}
+
+/**
+ * A copy function between rte_eth_rxq_conf offloads API to rxmode
+ * offloads API, to enable application to be agnostic to the PMD supported
+ * offload API.
+ */
+static void
+rte_eth_copy_rxq_offloads(struct rte_eth_rxmode *rxmode,
+ struct rte_eth_rxq_conf *rxq_conf)
+{
+ if (rxq_conf->offloads & DEV_RX_OFFLOAD_HEADER_SPLIT)
+ rxmode->header_split = 1;
+ if (rxq_conf->offloads & DEV_RX_OFFLOAD_CHECKSUM)
+ rxmode->hw_ip_checksum = 1;
+ if (rxq_conf->offloads & DEV_RX_OFFLOAD_VLAN_FILTER)
+ rxmode->hw_vlan_filter = 1;
+ if (rxq_conf->offloads & DEV_RX_OFFLOAD_VLAN_STRIP)
+ rxmode->hw_vlan_strip = 1;
+ if (rxq_conf->offloads & DEV_RX_OFFLOAD_VLAN_EXTEND)
+ rxmode->hw_vlan_extend = 1;
+ if (rxq_conf->offloads & DEV_RX_OFFLOAD_JUMBO_FRAME)
+ rxmode->jumbo_frame = 1;
+ if (rxq_conf->offloads & DEV_RX_OFFLOAD_CRC_STRIP)
+ rxmode->hw_strip_crc = 1;
+ if (rxq_conf->offloads & DEV_RX_OFFLOAD_SCATTER)
+ rxmode->enable_scatter = 1;
+ if (rxq_conf->offloads & DEV_RX_OFFLOAD_LRO)
+ rxmode->enable_lro = 1;
+}
+
int
rte_eth_rx_queue_setup(uint8_t port_id, uint16_t rx_queue_id,
uint16_t nb_rx_desc, unsigned int socket_id,
@@ -1083,6 +1140,37 @@ rte_eth_rx_queue_setup(uint8_t port_id, uint16_t
rx_queue_id,
if (rx_conf == NULL)
rx_conf = &dev_info.default_rxconf;
+ if ((dev->data->dev_flags & RTE_ETH_DEV_RXQ_OFFLOAD) &&
+ (dev->data->dev_conf.rxmode.ignore == 0)) {
+ rte_eth_copy_rxmode_offloads(&dev->data->dev_conf.rxmode,
+rx_conf);
+ } else if ((!(dev->data->dev_flags & RTE_ETH_DEV_RXQ_OFFLOAD)) &&
+ (dev->data->dev_conf.rxmode.ignore == 1)) {
+ int ret;
+ struct rte_eth_rxmode rxmode;
+
+ rte_eth_copy_rxq_offloads(&rxmode, rx_conf);
+ if (memcmp(&rxmode, &dev->data->dev_conf.rxmode,
+ sizeof(rxmode))) {
+ /*
+* device which work with rxmode offloads API requires
+* a re-configuration in order to apply the new offloads
+* configuration.
+*/
+ dev->data->dev_conf.rxmode = rxmode;
+ ret = rte_eth_dev_configure(port_id,
+ dev->data->nb_rx_queues,
+ dev->data->nb_tx_queues,
+ &dev->data->dev_conf);
+ if (ret < 0) {
+ RTE_PMD_DEBUG_TRACE(
+ "unable to re-configure port %d "
+ "in order to apply rxq offloads "
+
Re: [dpdk-dev] [PATCH v2] doc: announce API and ABI change for ethdev
07/08/2017 05:07, Yang, Zhiyong: > Hi, Thomas: > Need I sent another V3 patch to update commit log according to Remy's > suggestion? Yes it would be better if you can do it please
[dpdk-dev] [PATCH] app/crypto-perf: fix incorrect operation free
In crypto latency test, when some crypto operations cannot be
enqueued, they are returned to its mempool.
However, instead of freeing the operations in the array passed
to the enqueue function, the app was freeing the operations
in the array passed to the dequeue function, leading to incorrect
results.
Fixes: 15b55dd75120 ("app/crypto-perf: return crypto ops to mempool in bulk")
Signed-off-by: Pablo de Lara
---
app/test-crypto-perf/cperf_test_latency.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/app/test-crypto-perf/cperf_test_latency.c
b/app/test-crypto-perf/cperf_test_latency.c
index 7e610d9..58b21ab 100644
--- a/app/test-crypto-perf/cperf_test_latency.c
+++ b/app/test-crypto-perf/cperf_test_latency.c
@@ -433,7 +433,7 @@ cperf_latency_test_runner(void *arg)
/* Free memory for not enqueued operations */
if (ops_enqd != burst_size)
rte_mempool_put_bulk(ctx->crypto_op_pool,
- (void
**)&ops_processed[ops_enqd],
+ (void **)&ops[ops_enqd],
burst_size - ops_enqd);
for (i = 0; i < ops_enqd; i++) {
--
2.9.4
Re: [dpdk-dev] [PATCH v1] doc: update release notes for 17.08
04/08/2017 16:20, John McNamara: > Fix grammar, spelling and formatting of DPDK 17.08 release notes. > > Signed-off-by: John McNamara Applied, thanks Please, would you like to prepare a blank release notes for 17.11?
Re: [dpdk-dev] [PATCH v2] usertools: script to output version string
Hi, 06/07/2017 16:56, Keith Wiles: > +# Locate the rte_version.h file and parse out the version strings. I think this script is not needed because we have already something in mk/rte.sdkconfig.mk. Example: % make showversion 17.08.0-rc4 Do you need more?
[dpdk-dev] [PATCH] eal: change init macro as exec environment specific
baremetal execution environments may have a different
method to enable RTE_INIT instead of using compiler
constructor scheme. Move RTE_INIT* definition under
exec-env to support different execution environments.
Signed-off-by: Jerin Jacob
---
app/test-eventdev/evt_test.h | 2 +-
lib/librte_eal/bsdapp/eal/Makefile | 2 +-
.../bsdapp/eal/include/exec-env/rte_eal.h | 51 ++
lib/librte_eal/common/eal_common_log.c | 2 +
lib/librte_eal/common/include/rte_bus.h| 2 +
lib/librte_eal/common/include/rte_eal.h| 6 ---
lib/librte_eal/common/include/rte_tailq.h | 2 +
lib/librte_eal/linuxapp/eal/Makefile | 2 +-
.../linuxapp/eal/include/exec-env/rte_eal.h| 51 ++
9 files changed, 111 insertions(+), 9 deletions(-)
create mode 100644 lib/librte_eal/bsdapp/eal/include/exec-env/rte_eal.h
create mode 100644 lib/librte_eal/linuxapp/eal/include/exec-env/rte_eal.h
diff --git a/app/test-eventdev/evt_test.h b/app/test-eventdev/evt_test.h
index 17bdd1650..f63f9a814 100644
--- a/app/test-eventdev/evt_test.h
+++ b/app/test-eventdev/evt_test.h
@@ -37,7 +37,7 @@
#include
#include
-#include
+#include
enum evt_test_result {
EVT_TEST_SUCCESS,
diff --git a/lib/librte_eal/bsdapp/eal/Makefile
b/lib/librte_eal/bsdapp/eal/Makefile
index 05517a2dc..2f5574f79 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -107,7 +107,7 @@ CFLAGS_eal_thread.o += -Wno-return-type
CFLAGS_eal_hpet.o += -Wno-return-type
endif
-INC := rte_interrupts.h
+INC := rte_interrupts.h rte_eal.h
SYMLINK-$(CONFIG_RTE_EXEC_ENV_BSDAPP)-include/exec-env := \
$(addprefix include/exec-env/,$(INC))
diff --git a/lib/librte_eal/bsdapp/eal/include/exec-env/rte_eal.h
b/lib/librte_eal/bsdapp/eal/include/exec-env/rte_eal.h
new file mode 100644
index 0..1f3222f01
--- /dev/null
+++ b/lib/librte_eal/bsdapp/eal/include/exec-env/rte_eal.h
@@ -0,0 +1,51 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-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.
+ */
+
+#ifndef _BSDAPP_RTE_EAL_H_
+#define _BSDAPP_RTE_EAL_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#define RTE_INIT(func) \
+static void __attribute__((constructor, used)) func(void)
+
+#define RTE_INIT_PRIO(func, prio) \
+static void __attribute__((constructor(prio), used)) func(void)
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _BSDAPP_RTE_EAL_H_ */
diff --git a/lib/librte_eal/common/eal_common_log.c
b/lib/librte_eal/common/eal_common_log.c
index 0e3b93209..236a662b0 100644
--- a/lib/librte_eal/common/eal_common_log.c
+++ b/lib/librte_eal/common/eal_common_log.c
@@ -43,6 +43,8 @@
#include
#include
+#include
+
#include "eal_private.h"
/* global log structure */
diff --git a/lib/librte_eal/common/include/rte_bus.h
b/lib/librte_eal/common/include/rte_bus.h
index c79368d3c..52e13bd0d 100644
--- a/lib/librte_eal/common/include/rte_bus.h
+++ b/lib/librte_eal/common/include/rte_bus.h
@@ -52,6 +52,8 @@ extern "C" {
#include
#include
+#include
+
/** Double linked list of buses */
TAILQ_HEAD(rte_bus_list, rte_bus);
diff --git a/lib/librte_eal/common/include/rte_eal.h
b/lib/librte_eal/common/include/rte_eal.h
index 0e7363d77..cce5160bd 100644
--- a/lib/librte_eal/common/includ
Re: [dpdk-dev] [PATCH] app/crypto-perf: fix incorrect operation free
07/08/2017 05:16, Pablo de Lara:
> In crypto latency test, when some crypto operations cannot be
> enqueued, they are returned to its mempool.
> However, instead of freeing the operations in the array passed
> to the enqueue function, the app was freeing the operations
> in the array passed to the dequeue function, leading to incorrect
> results.
>
> Fixes: 15b55dd75120 ("app/crypto-perf: return crypto ops to mempool in bulk")
>
> Signed-off-by: Pablo de Lara
Applied, thanks
[dpdk-dev] [PATCH v3] doc: announce API and ABI change for ethdev
This is an API/ABI change notice for DPDK 17.11 announcing the redefinition of port_id. port_id is currently defined as uint8_t, which is limited to the range 0 to 255. A larger range is required for vdev scalability. It is necessary for a redefinition of port_id to extend it from 1 bytes to 2 bytes. All ethdev APIs and usages related to port_id will be changed at the same time. cc: jianfeng@intel.com cc: y...@fridaylinux.org cc: jerin.ja...@caviumnetworks.com cc: tho...@monjalon.net cc: remy.hor...@intel.com Signed-off-by: Zhiyong Yang Acked-by: Jianfeng Tan Acked-by: Yuanhan Liu Acked-by: Jerin Jacob Acked-by: Remy Horton --- Change in V3. update the commit log. Thanks for Remy's comment. Change in V2. 1. remove indent of paragraph in commit log. 2. add more description about API/ABI according to yuanhan's comments. doc/guides/rel_notes/deprecation.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 72aa40495..4edaf92fb 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -49,6 +49,12 @@ Deprecation Notices Target release for removal of the legacy API will be defined once most PMDs have switched to rte_flow. +* ABI/API changes are planned for 17.11 in all structures which include port_id + definition such as "rte_eth_dev_data", "rte_port_ethdev_reader_params", + "rte_port_ethdev_writer_params", and so on. The definition of port_id will be + changed from 8 bits to 16 bits in order to support more than 256 ports in + DPDK. All APIs which have port_id parameter will be changed at the same time. + * librte_table: The ``key_mask`` parameter will be added to all the hash tables that currently do not have it, as well as to the hash compute function prototype. The non-"do-sig" versions of the hash tables will be removed -- 2.13.3
[dpdk-dev] LAST CALL to review deprecation notices for 17.08 release notes
Hi all, It seems some deprecation notices have not been reviewed enough. The 17.08 release should be closed today. Please take time to review them, even if you don't feel very concerned at first sight. It is a community effort to approve the important changes. There are 14 pending notices, all sent during July or August: http://dpdk.org/dev/patchwork Expected comments: Ack or Nack. Thanks for your contribution
[dpdk-dev] [PATCH] ethdev: add return code to rte_eth_stats_reset()
Some devices do not support reset of eth stats. An application
may need to know not to clear shadow stats if the device cannot.
rte_eth_stats_reset is updated to provide a return code to
share whether the device supports reset or not.
Signed-off-by: David Harton
---
lib/librte_ether/rte_ethdev.c | 8 +---
lib/librte_ether/rte_ethdev.h | 4 +++-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 0597641..46ce42d 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1341,17 +1341,19 @@ rte_eth_stats_get(uint8_t port_id, struct rte_eth_stats
*stats)
return 0;
}
-void
+int
rte_eth_stats_reset(uint8_t port_id)
{
struct rte_eth_dev *dev;
- RTE_ETH_VALID_PORTID_OR_RET(port_id);
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id);
dev = &rte_eth_devices[port_id];
- RTE_FUNC_PTR_OR_RET(*dev->dev_ops->stats_reset);
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->stats_reset);
(*dev->dev_ops->stats_reset)(dev);
dev->data->rx_mbuf_alloc_failed = 0;
+
+return 0;
}
static int
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 0adf327..d8ccd60 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -2246,8 +2246,10 @@ int rte_eth_stats_get(uint8_t port_id, struct
rte_eth_stats *stats);
*
* @param port_id
* The port identifier of the Ethernet device.
+ * @return
+ * Zero if successful. Non-zero otherwise.
*/
-void rte_eth_stats_reset(uint8_t port_id);
+int rte_eth_stats_reset(uint8_t port_id);
/**
* Retrieve names of extended statistics of an Ethernet device.
--
2.10.3.dirty
Re: [dpdk-dev] [PATCH v2] usertools: script to output version string
> On Aug 7, 2017, at 6:35 AM, Thomas Monjalon wrote: > > Hi, > > 06/07/2017 16:56, Keith Wiles: >> +# Locate the rte_version.h file and parse out the version strings. > > I think this script is not needed because we have already > something in mk/rte.sdkconfig.mk. > Example: > % make showversion > 17.08.0-rc4 Executing make to find out a version seems to bit of over kill to me and a simple script would be much easier IMO. I do not really see harm in having this script that can output the version into different formats is helpful when running external scripts. Also in the future we are most like going to replace the build system and then we would need to add this support to that build system and having it in a standalone script is easier manage in the long run. > > Do you need more? Regards, Keith
[dpdk-dev] [PATCH v2] ethdev: add return code to rte_eth_stats_reset()
Some devices do not support reset of eth stats. An application
may need to know not to clear shadow stats if the device cannot.
rte_eth_stats_reset is updated to provide a return code to
share whether the device supports reset or not.
Signed-off-by: David Harton
---
v2:
* Fixed soft tab issue inserted while moving changes.
lib/librte_ether/rte_ethdev.c | 8 +---
lib/librte_ether/rte_ethdev.h | 4 +++-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 0597641..3071eea 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1341,17 +1341,19 @@ rte_eth_stats_get(uint8_t port_id, struct rte_eth_stats
*stats)
return 0;
}
-void
+int
rte_eth_stats_reset(uint8_t port_id)
{
struct rte_eth_dev *dev;
- RTE_ETH_VALID_PORTID_OR_RET(port_id);
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id);
dev = &rte_eth_devices[port_id];
- RTE_FUNC_PTR_OR_RET(*dev->dev_ops->stats_reset);
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->stats_reset);
(*dev->dev_ops->stats_reset)(dev);
dev->data->rx_mbuf_alloc_failed = 0;
+
+ return 0;
}
static int
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 0adf327..d8ccd60 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -2246,8 +2246,10 @@ int rte_eth_stats_get(uint8_t port_id, struct
rte_eth_stats *stats);
*
* @param port_id
* The port identifier of the Ethernet device.
+ * @return
+ * Zero if successful. Non-zero otherwise.
*/
-void rte_eth_stats_reset(uint8_t port_id);
+int rte_eth_stats_reset(uint8_t port_id);
/**
* Retrieve names of extended statistics of an Ethernet device.
--
2.10.3.dirty
Re: [dpdk-dev] [PATCH v2] doc: deprecate Xen support
-Original Message- > Date: Fri, 4 Aug 2017 13:44:02 + > From: "Mcnamara, John" > To: "Tan, Jianfeng" , "dev@dpdk.org" > CC: "Tan, Jianfeng" , Thomas Monjalon > > Subject: Re: [dpdk-dev] [PATCH v2] doc: deprecate Xen support > > > > > -Original Message- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jianfeng Tan > > Sent: Thursday, August 3, 2017 9:38 PM > > To: dev@dpdk.org > > Cc: Tan, Jianfeng ; Thomas Monjalon > > > > Subject: [dpdk-dev] [PATCH v2] doc: deprecate Xen support > > > > Following the calls on the mailing list: > > http://dpdk.org/ml/archives/dev/2017-June/068151.html > > The Technical Board decided to drop Xen dom0 support from EAL: > > http://dpdk.org/ml/archives/dev/2017-June/068615.html > > > > Signed-off-by: Thomas Monjalon > > Signed-off-by: Jianfeng Tan > > Acked-by: John McNamara Acked-by: Jerin Jacob > >
[dpdk-dev] [PATCH] vfio: fix sPAPR IOMMU DMA window size
DMA window size needs to be big enough to span all memory segment's
physical addresses. We do not need multiple levels of IOMMU tables
as we already span ~70TB of physical memory with 16MB hugepages.
Signed-off-by: Jonas Pfefferle
---
lib/librte_eal/linuxapp/eal/eal_vfio.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_vfio.c
index 946df7e..8502216 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
@@ -722,6 +722,18 @@ vfio_type1_dma_map(int vfio_container_fd)
return 0;
}
+static uint64_t
+roundup_next_pow2(uint64_t n)
+{
+ uint32_t i;
+
+ n--;
+ for (i = 1; i < sizeof(n) * CHAR_BIT; i += i)
+ n |= n >> i;
+
+ return ++n;
+}
+
static int
vfio_spapr_dma_map(int vfio_container_fd)
{
@@ -759,10 +771,12 @@ vfio_spapr_dma_map(int vfio_container_fd)
return -1;
}
- /* calculate window size based on number of hugepages configured */
- create.window_size = rte_eal_get_physmem_size();
+ /* physicaly pages are sorted descending i.e. ms[0].phys_addr is max */
+ /* create DMA window from 0 to max(phys_addr + len) */
+ /* sPAPR requires window size to be a power of 2 */
+ create.window_size = roundup_next_pow2(ms[0].phys_addr + ms[0].len);
create.page_shift = __builtin_ctzll(ms->hugepage_sz);
- create.levels = 2;
+ create.levels = 1;
ret = ioctl(vfio_container_fd, VFIO_IOMMU_SPAPR_TCE_CREATE, &create);
if (ret) {
@@ -771,6 +785,11 @@ vfio_spapr_dma_map(int vfio_container_fd)
return -1;
}
+ if (create.start_addr != 0) {
+ RTE_LOG(ERR, EAL, " DMA window start address != 0\n");
+ return -1;
+ }
+
/* map all DPDK segments for DMA. use 1:1 PA to IOVA mapping */
for (i = 0; i < RTE_MAX_MEMSEG; i++) {
struct vfio_iommu_type1_dma_map dma_map;
--
2.7.4
Re: [dpdk-dev] [PATCH v2] doc: deprecate Xen support
> > -Original Message- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jianfeng Tan > > Sent: Thursday, August 3, 2017 9:38 PM > > To: dev@dpdk.org > > Cc: Tan, Jianfeng ; Thomas Monjalon > > > > Subject: [dpdk-dev] [PATCH v2] doc: deprecate Xen support > > > > Following the calls on the mailing list: > > > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdpd > k > > .org%2Fml%2Farchives%2Fdev%2F2017- > June%2F068151.html&data=02%7C01%7Csh > > > ahafs%40mellanox.com%7C729c7cd1d758403fa09708d4db3ee222%7Ca65297 > 1c7d2e > > > 4d9ba6a4d149256f461b%7C0%7C0%7C636374510531999709&sdata=YJNGX5G > 5XIUjci > > RlDDaqtTAZh3%2FwsKdfaxfdrAi0N78%3D&reserved=0 > > The Technical Board decided to drop Xen dom0 support from EAL: > > > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdpd > k > > .org%2Fml%2Farchives%2Fdev%2F2017- > June%2F068615.html&data=02%7C01%7Csh > > > ahafs%40mellanox.com%7C729c7cd1d758403fa09708d4db3ee222%7Ca65297 > 1c7d2e > > > 4d9ba6a4d149256f461b%7C0%7C0%7C636374510531999709&sdata=7c31%2Ft > Cfn6cF > > uBJsLyoIBwiWznmr3rMkzUdN5d87UhI%3D&reserved=0 > > > > Signed-off-by: Thomas Monjalon > > Signed-off-by: Jianfeng Tan > > Acked-by: John McNamara > Acked-by: Shahaf Shuler
Re: [dpdk-dev] [PATCH v2] doc: announce API and ABI change for ethdev
Friday, August 4, 2017 9:56 AM, Remy Horton: > On 04/08/2017 06:27, Zhiyong Yang wrote: > > This is an API/ABI change notice for DPDK 17.11 on redefinition of > > port_id. port_id is defined as uint8_t by now, which is just ranged > > from 0 to 255. For more and more scenerioes, more than 256 ports are > > needed to support for vdev scalability. > > > > It is necessary for redefinition of port_id to extend from 1 bytes to > > 2 bytes. All ethdev APIs and use cases related to port_id will be > > changed at the same time. > > I think this reads a little better: > > This is an API/ABI change notice for DPDK 17.11 announcing the redefinition > of port_id. port_id is currently defined as uint8_t, which is limited to the > range 0 to 255. A larger range is required for vdev scalability. > > It is necessary for a redefinition of port_id to extend it from 1 bytes to 2 > bytes. All ethdev APIs and usages related to port_id will be changed at the > same time. > > > doc/guides/rel_notes/deprecation.rst | 6 ++ > > 1 file changed, 6 insertions(+) > > Acked-by: Remy Horton Acked-by: Shahaf Shuler
[dpdk-dev] [PATCH] mbuf: use refcnt = 0 when debugging
After commit 8f094a9ac5d7 is it much harder to detect a "double free".
If the developer makes a copy of an mbuf pointer and frees it twice, this
condition is never detected and the mbuf gets returned to the pool twice.
Since this requires extra work to track, make this behavior conditional
on CONFIG_RTE_LIBRTE_MBUF_DEBUG.
Signed-off-by: Chas Williams
---
lib/librte_mbuf/rte_mbuf.c | 2 +-
lib/librte_mbuf/rte_mbuf.h | 42 +++---
2 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index 26a62b8..b0d222c 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -145,7 +145,7 @@ rte_pktmbuf_init(struct rte_mempool *mp,
m->pool = mp;
m->nb_segs = 1;
m->port = 0xff;
- rte_mbuf_refcnt_set(m, 1);
+ rte_mbuf_refcnt_set(m, RTE_MBUF_UNUSED_CNT);
m->next = NULL;
}
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index eaed7ee..9d87081 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -671,11 +671,15 @@ struct rte_pktmbuf_pool_private {
#ifdef RTE_LIBRTE_MBUF_DEBUG
+#define RTE_MBUF_UNUSED_CNT 0
+
/** check mbuf type in debug mode */
#define __rte_mbuf_sanity_check(m, is_h) rte_mbuf_sanity_check(m, is_h)
#else /* RTE_LIBRTE_MBUF_DEBUG */
+#define RTE_MBUF_UNUSED_CNT 1
+
/** check mbuf type in debug mode */
#define __rte_mbuf_sanity_check(m, is_h) do { } while (0)
@@ -721,6 +725,9 @@ rte_mbuf_refcnt_set(struct rte_mbuf *m, uint16_t new_value)
static inline uint16_t
rte_mbuf_refcnt_update(struct rte_mbuf *m, int16_t value)
{
+#ifdef RTE_LIBRTE_MBUF_DEBUG
+ RTE_ASSERT(rte_mbuf_refcnt_read(m) != 0);
+#endif
/*
* The atomic_add is an expensive operation, so we don't want to
* call it in the case where we know we are the uniq holder of
@@ -791,10 +798,9 @@ void
rte_mbuf_sanity_check(const struct rte_mbuf *m, int is_header);
#define MBUF_RAW_ALLOC_CHECK(m) do { \
- RTE_ASSERT(rte_mbuf_refcnt_read(m) == 1); \
+ RTE_ASSERT(rte_mbuf_refcnt_read(m) == RTE_MBUF_UNUSED_CNT); \
RTE_ASSERT((m)->next == NULL); \
RTE_ASSERT((m)->nb_segs == 1); \
- __rte_mbuf_sanity_check(m, 0); \
} while (0)
/**
@@ -825,6 +831,10 @@ static inline struct rte_mbuf *rte_mbuf_raw_alloc(struct
rte_mempool *mp)
return NULL;
m = (struct rte_mbuf *)mb;
MBUF_RAW_ALLOC_CHECK(m);
+#ifdef RTE_LIBRTE_MBUF_DEBUG
+ rte_mbuf_refcnt_set(m, 1);
+#endif
+ __rte_mbuf_sanity_check(m, 0);
return m;
}
@@ -846,10 +856,9 @@ static __rte_always_inline void
rte_mbuf_raw_free(struct rte_mbuf *m)
{
RTE_ASSERT(RTE_MBUF_DIRECT(m));
- RTE_ASSERT(rte_mbuf_refcnt_read(m) == 1);
+ RTE_ASSERT(rte_mbuf_refcnt_read(m) == RTE_MBUF_UNUSED_CNT);
RTE_ASSERT(m->next == NULL);
RTE_ASSERT(m->nb_segs == 1);
- __rte_mbuf_sanity_check(m, 0);
rte_mempool_put(m->pool, m);
}
@@ -1159,21 +1168,37 @@ static inline int rte_pktmbuf_alloc_bulk(struct
rte_mempool *pool,
case 0:
while (idx != count) {
MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
+#ifdef RTE_LIBRTE_MBUF_DEBUG
+ rte_mbuf_refcnt_set(mbufs[idx], 1);
+#endif
+ __rte_mbuf_sanity_check(mbufs[idx], 0);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
/* fall-through */
case 3:
MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
+#ifdef RTE_LIBRTE_MBUF_DEBUG
+ rte_mbuf_refcnt_set(mbufs[idx], 1);
+#endif
+ __rte_mbuf_sanity_check(mbufs[idx], 0);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
/* fall-through */
case 2:
MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
+#ifdef RTE_LIBRTE_MBUF_DEBUG
+ rte_mbuf_refcnt_set(mbufs[idx], 1);
+#endif
+ __rte_mbuf_sanity_check(mbufs[idx], 0);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
/* fall-through */
case 1:
MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
+#ifdef RTE_LIBRTE_MBUF_DEBUG
+ rte_mbuf_refcnt_set(mbufs[idx], 1);
+#endif
+ __rte_mbuf_sanity_check(mbufs[idx], 0);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
/* fall-through */
@@ -1271,7 +1296,7 @@ static inline void rte_pktmbuf_detach(struct rte_mbuf *m)
if (rte_mbuf_refcnt_update(md, -1) == 0) {
md->next = NULL;
md->nb_segs = 1;
- rte_mbuf_refcnt_set(md, 1);
[dpdk-dev] [PATCH v2] mbuf: use refcnt = 0 when debugging
After commit 8f094a9ac5d7 ("mbuf: set mbuf fields while in pool") is it
much harder to detect a "double free". If the developer makes a copy
of an mbuf pointer and frees it twice, this condition is never detected
and the mbuf gets returned to the pool twice.
Since this requires extra work to track, make this behavior conditional
on CONFIG_RTE_LIBRTE_MBUF_DEBUG.
Signed-off-by: Chas Williams
---
lib/librte_mbuf/rte_mbuf.c | 2 +-
lib/librte_mbuf/rte_mbuf.h | 42 +++---
2 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index 26a62b8..b0d222c 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -145,7 +145,7 @@ rte_pktmbuf_init(struct rte_mempool *mp,
m->pool = mp;
m->nb_segs = 1;
m->port = 0xff;
- rte_mbuf_refcnt_set(m, 1);
+ rte_mbuf_refcnt_set(m, RTE_MBUF_UNUSED_CNT);
m->next = NULL;
}
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index eaed7ee..3e00373 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -671,11 +671,15 @@ struct rte_pktmbuf_pool_private {
#ifdef RTE_LIBRTE_MBUF_DEBUG
+#define RTE_MBUF_UNUSED_CNT 0
+
/** check mbuf type in debug mode */
#define __rte_mbuf_sanity_check(m, is_h) rte_mbuf_sanity_check(m, is_h)
#else /* RTE_LIBRTE_MBUF_DEBUG */
+#define RTE_MBUF_UNUSED_CNT 1
+
/** check mbuf type in debug mode */
#define __rte_mbuf_sanity_check(m, is_h) do { } while (0)
@@ -721,6 +725,9 @@ rte_mbuf_refcnt_set(struct rte_mbuf *m, uint16_t new_value)
static inline uint16_t
rte_mbuf_refcnt_update(struct rte_mbuf *m, int16_t value)
{
+#ifdef RTE_LIBRTE_MBUF_DEBUG
+ RTE_ASSERT(rte_mbuf_refcnt_read(m) != 0);
+#endif
/*
* The atomic_add is an expensive operation, so we don't want to
* call it in the case where we know we are the uniq holder of
@@ -791,10 +798,9 @@ void
rte_mbuf_sanity_check(const struct rte_mbuf *m, int is_header);
#define MBUF_RAW_ALLOC_CHECK(m) do { \
- RTE_ASSERT(rte_mbuf_refcnt_read(m) == 1); \
+ RTE_ASSERT(rte_mbuf_refcnt_read(m) == RTE_MBUF_UNUSED_CNT); \
RTE_ASSERT((m)->next == NULL); \
RTE_ASSERT((m)->nb_segs == 1); \
- __rte_mbuf_sanity_check(m, 0); \
} while (0)
/**
@@ -825,6 +831,10 @@ static inline struct rte_mbuf *rte_mbuf_raw_alloc(struct
rte_mempool *mp)
return NULL;
m = (struct rte_mbuf *)mb;
MBUF_RAW_ALLOC_CHECK(m);
+#ifdef RTE_LIBRTE_MBUF_DEBUG
+ rte_mbuf_refcnt_set(m, 1);
+#endif
+ __rte_mbuf_sanity_check(m, 0);
return m;
}
@@ -846,10 +856,9 @@ static __rte_always_inline void
rte_mbuf_raw_free(struct rte_mbuf *m)
{
RTE_ASSERT(RTE_MBUF_DIRECT(m));
- RTE_ASSERT(rte_mbuf_refcnt_read(m) == 1);
+ RTE_ASSERT(rte_mbuf_refcnt_read(m) == RTE_MBUF_UNUSED_CNT);
RTE_ASSERT(m->next == NULL);
RTE_ASSERT(m->nb_segs == 1);
- __rte_mbuf_sanity_check(m, 0);
rte_mempool_put(m->pool, m);
}
@@ -1159,21 +1168,37 @@ static inline int rte_pktmbuf_alloc_bulk(struct
rte_mempool *pool,
case 0:
while (idx != count) {
MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
+#ifdef RTE_LIBRTE_MBUF_DEBUG
+ rte_mbuf_refcnt_set(mbufs[idx], 1);
+#endif
+ __rte_mbuf_sanity_check(mbufs[idx], 0);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
/* fall-through */
case 3:
MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
+#ifdef RTE_LIBRTE_MBUF_DEBUG
+ rte_mbuf_refcnt_set(mbufs[idx], 1);
+#endif
+ __rte_mbuf_sanity_check(mbufs[idx], 0);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
/* fall-through */
case 2:
MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
+#ifdef RTE_LIBRTE_MBUF_DEBUG
+ rte_mbuf_refcnt_set(mbufs[idx], 1);
+#endif
+ __rte_mbuf_sanity_check(mbufs[idx], 0);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
/* fall-through */
case 1:
MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
+#ifdef RTE_LIBRTE_MBUF_DEBUG
+ rte_mbuf_refcnt_set(mbufs[idx], 1);
+#endif
+ __rte_mbuf_sanity_check(mbufs[idx], 0);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
/* fall-through */
@@ -1271,7 +1296,7 @@ static inline void rte_pktmbuf_detach(struct rte_mbuf *m)
if (rte_mbuf_refcnt_update(md, -1) == 0) {
md->next = NULL;
md->nb_segs = 1;
-
Re: [dpdk-dev] [PATCH v2] usertools: script to output version string
07/08/2017 15:17, Wiles, Keith: > > > On Aug 7, 2017, at 6:35 AM, Thomas Monjalon wrote: > > > > Hi, > > > > 06/07/2017 16:56, Keith Wiles: > >> +# Locate the rte_version.h file and parse out the version strings. > > > > I think this script is not needed because we have already > > something in mk/rte.sdkconfig.mk. > > Example: > > % make showversion > > 17.08.0-rc4 > > Executing make to find out a version seems to bit of over kill to me and a > simple script would be much easier IMO. I do not really see harm in having > this script that can output the version into different formats is helpful > when running external scripts. Also in the future we are most like going to > replace the build system and then we would need to add this support to that > build system and having it in a standalone script is easier manage in the > long run. "make showversion" is here for several years. Usually we do not implement the same thing in several places without a good reason. And some users can use the old command. Especially when talking about versions, it is very convenient to use the same command in every versions. That's why I insist: why implementing it differently? If it is only about the new build system, it should be part of the build system migration plan (long term).
Re: [dpdk-dev] [PATCH v2] usertools: script to output version string
> On Aug 7, 2017, at 11:49 AM, Thomas Monjalon wrote: > > 07/08/2017 15:17, Wiles, Keith: >> >>> On Aug 7, 2017, at 6:35 AM, Thomas Monjalon wrote: >>> >>> Hi, >>> >>> 06/07/2017 16:56, Keith Wiles: +# Locate the rte_version.h file and parse out the version strings. >>> >>> I think this script is not needed because we have already >>> something in mk/rte.sdkconfig.mk. >>> Example: >>> % make showversion >>> 17.08.0-rc4 >> >> Executing make to find out a version seems to bit of over kill to me and a >> simple script would be much easier IMO. I do not really see harm in having >> this script that can output the version into different formats is helpful >> when running external scripts. Also in the future we are most like going to >> replace the build system and then we would need to add this support to that >> build system and having it in a standalone script is easier manage in the >> long run. > > "make showversion" is here for several years. > Usually we do not implement the same thing in several places > without a good reason. > And some users can use the old command. > Especially when talking about versions, it is very convenient > to use the same command in every versions. I grep’d the repo and found couple references to showversion. ./devtools/git-log-fixes.sh:72: make showversion | cut -d'.' -f-2 ./doc/guides/conf.py:67:version = subprocess.check_output(['make', '-sRrC', '../../', 'showversion']) ./mk/rte.sdkconfig.mk:32:.PHONY: showversion ./mk/rte.sdkconfig.mk:33:showversion: ./mk/rte.sdkconfig.mk:45:.PHONY: showversionum ./mk/rte.sdkconfig.mk:46:showversionum: ./mk/rte.sdkdoc.mk:76: $(MAKE) -rRs showversion && \ ./mk/rte.sdkroot.mk:91:.PHONY: config defconfig showconfigs showversion showversionum ./mk/rte.sdkroot.mk:92:config defconfig showconfigs showversion showversionum: Which means to me this was a completely undocumented feature, which is why I created this shell script. This also means the feature was not used widely. Then I suggest we remove the 'make showversion' and use the script in the usertools dir, which is easier to find and does not require the use of Make or Makefile at all. The script allows you to print the version from any directory as long as RTE_SDK is defined or if you are located in a SDK directory. Also allows the developer/user to execute dpdk-version.sh from the installed location or the RTE_SDK/usertools directory. I have the changes already to install dpdk-version.h tool during build like the other tools, but have not submitted it yet. I can also update the documents to help users find the tool. > > That's why I insist: why implementing it differently? > If it is only about the new build system, it should be part > of the build system migration plan (long term). Regards, Keith
[dpdk-dev] [PATCH v3] ethdev: add return code to rte_eth_stats_reset()
Some devices do not support reset of eth stats. An application may
need to know not to clear shadow stats if the device cannot.
rte_eth_stats_reset is updated to provide a return code to share
whether the device supports reset or not.
Signed-off-by: David Harton
---
v3:
* overcame noob errors and figured out patch challenges
* this release should finally be clean :)
v2:
* fixed soft tab issue inserted while moving changes
lib/librte_ether/rte_ethdev.c | 8 +---
lib/librte_ether/rte_ethdev.h | 4 +++-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 0597641..f72cc5a 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1341,17 +1341,19 @@ rte_eth_stats_get(uint8_t port_id, struct rte_eth_stats
*stats)
return 0;
}
-void
+int
rte_eth_stats_reset(uint8_t port_id)
{
struct rte_eth_dev *dev;
- RTE_ETH_VALID_PORTID_OR_RET(port_id);
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
dev = &rte_eth_devices[port_id];
- RTE_FUNC_PTR_OR_RET(*dev->dev_ops->stats_reset);
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->stats_reset, -ENOTSUP);
(*dev->dev_ops->stats_reset)(dev);
dev->data->rx_mbuf_alloc_failed = 0;
+
+ return 0;
}
static int
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 0adf327..d8ccd60 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -2246,8 +2246,10 @@ int rte_eth_stats_get(uint8_t port_id, struct
rte_eth_stats *stats);
*
* @param port_id
* The port identifier of the Ethernet device.
+ * @return
+ * Zero if successful. Non-zero otherwise.
*/
-void rte_eth_stats_reset(uint8_t port_id);
+int rte_eth_stats_reset(uint8_t port_id);
/**
* Retrieve names of extended statistics of an Ethernet device.
--
2.10.3.dirty
Re: [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev and ethdev
04/08/2017 07:26, Hemant Agrawal: > On 8/3/2017 9:02 PM, Akhil Goyal wrote: > > Support for security operations is planned to be added > > in ethdev and cryptodev for the 17.11 release. > > > > For this following changes are required. > > - rte_cryptodev and rte_eth_dev structures need to be added > > new parameter rte_security_ops which extend support for > > security ops to the corresponding driver. > > - rte_cryptodev_info and rte_ethd_dev_info need to be added > > with rte_security_capabilities to identify the capabilities of > > the corresponding driver. It is not explained what is the fundamental difference between rte_security and rte_crypto? It looks to be just a technical workaround. Why the ABI would be changed by rte_security additions? > > Signed-off-by: Akhil Goyal > > > Acked-by: Hemant Agrawal No more opinions outside of NXP? It seems there is not yet a consensus on how to manage IPsec offloading. I heard there were some phone calls about these stuff but nothing clear appears publicly on the mailing list. Looks to be a community failure.
Re: [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev and ethdev
> From: Thomas Monjalon [mailto:tho...@monjalon.net] > 04/08/2017 07:26, Hemant Agrawal: > > On 8/3/2017 9:02 PM, Akhil Goyal wrote: > > > Support for security operations is planned to be added in ethdev and > > > cryptodev for the 17.11 release. > > > > > > For this following changes are required. > > > - rte_cryptodev and rte_eth_dev structures need to be added new > > > parameter rte_security_ops which extend support for security ops to > > > the corresponding driver. > > > - rte_cryptodev_info and rte_ethd_dev_info need to be added with > > > rte_security_capabilities to identify the capabilities of the > > > corresponding driver. > > It is not explained what is the fundamental difference between rte_security > and rte_crypto? > It looks to be just a technical workaround. rte_security is a layer between crypto and NIC. Today crypto sessions are created exclusively against crypto devices, but they don't use network related fields, while the network namespace doesn't use crypto related fields. We expect this API to represent crypto sessions that combine network fields and allow to add/delete them for all devices. For NICs we will use rte_flow with rte_security for inline/full crypto protocol offload such as ESP. > > Why the ABI would be changed by rte_security additions? > > > > Signed-off-by: Akhil Goyal > > > > > Acked-by: Hemant Agrawal > > No more opinions outside of NXP? > It seems there is not yet a consensus on how to manage IPsec offloading. > I heard there were some phone calls about these stuff but nothing clear > appears publicly on the mailing list. > Looks to be a community failure. We agreed to go ahead with this approach on one such phone call. I hope we could use the dpdk github for development. Acked-by: Boris Pismenny
Re: [dpdk-dev] [PATCH] doc: postpone legacy log functions removal
> > > The replacement function rte_log_get_level() has just been implemented in
> > > 17.08. Better to postpone the removal of legacy functions to 17.11.
> > >
> > > Fixes: 4f0981e6ec6c ("eal: deprecate log functions")
> > > Cc: olivier.m...@6wind.com
> > >
> > > Signed-off-by: Thomas Monjalon
> >
> > Acked-by: John McNamara
>
> Acked-by: Olivier Matz
>
> Thanks Thomas
Applied
Re: [dpdk-dev] [PATCH] ethdev: add notice for planned name size change
> On Jul 6, 2017, at 8:07 AM, Stephen Hemminger > wrote: > > VMBUS support will use GUID in eth_dev_data name field which requires > at least 37 characters. Plan for increase in size now. > > Signed-off-by: Stephen Hemminger > --- > doc/guides/rel_notes/deprecation.rst | 4 > 1 file changed, 4 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 2e708dbe0deb..d5b70c50064a 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -95,3 +95,7 @@ Deprecation Notices > The non-"do-sig" versions of the hash tables will be removed > (including the ``signature_offset`` parameter) > and the "do-sig" versions renamed accordingly. > + > +* ethdev: An ABI change is planned for 17.11 for the structure eth_dev_data. Isn't it better to use "``rte_eth_dev_data``"? > + The size of the unique name will increase RTE_ETH_NAME_MAX_LEN from 32 to > + 64 characters to allow using a globally unique identifier (GUID) in this > field. Except for the small comment above, Acked-by: Yongseok Koh Thanks, Yongseok
Re: [dpdk-dev] [PATCH 03/13] devargs: deprecate enum rte_devtype based functions
12/07/2017 01:25, Jan Blunck: > The enum rte_devtype will need to get extended every time we add a bus. > Mark all related functions as deprecated for 17.11. > > Signed-off-by: Jan Blunck > --- > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > +* devargs: An API/ABI change is planed for 17.11 for ``struct rte_devargs`` > to > + remove ``enum rte_devtype`` so that starting from 17.08 the following > + functions are deprecated: > + > + - ``rte_eal_devargs_add`` > + - ``rte_eal_devargs_type_count`` This deprecation notice is superseded by: http://dpdk.org/dev/patchwork/patch/27443/
Re: [dpdk-dev] [PATCH 2/2] eal: deprecate 17.08 devargs API/ABI
09/07/2017 11:28, Jan Blunck: > Add deprecation notice necessary to do devargs refactoring for 17.11. > > Signed-off-by: Jan Blunck > --- > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > +* devargs: An ABI change is planned for 17.11 for the structure > ``rte_devargs``. > + The newly introduced devargs ABI in 17.08 is tightly couple to the bus > + implementations which will get fixed in 17.11. The following function is > + deprecated and will change API in 17.11: > + > + - ``rte_eal_devargs_add`` This deprecation notice is superseded by: http://dpdk.org/dev/patchwork/patch/27443/
Re: [dpdk-dev] [PATCH] doc: remove planned devargs changes for v17.08
> > These changes have been implemented. > > > > Signed-off-by: Gaetan Rivet > > Acked-by: John McNamara Applied and merged with http://dpdk.org/dev/patchwork/patch/27443/
Re: [dpdk-dev] [PATCH] doc: announce rte_devargs changes in 17.11
04/08/2017 15:29, Gaetan Rivet: > Signed-off-by: Gaetan Rivet > --- > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > +* eal: several API and ABI changes are planned for ``rte_devargs`` in v17.11. > + The format of device command line parameters will change. The bus will need > + to be explicitly stated in the device declaration. The enum ``rte_devtype`` > + was used to identify a bus and will disappear. > + The structure ``rte_devargs`` will change. > + The ``rte_devargs_list`` will be made private. > + The following functions are deprecated starting from 17.08 and will either > be > + modified or removed in 17.11: > + > + - ``rte_eal_devargs_add`` > + - ``rte_eal_devargs_type_count`` Acked-by: Thomas Monjalon This kind of change has already been suggested by Jan Blunck: http://dpdk.org/ml/archives/dev/2017-July/070729.html http://dpdk.org/ml/archives/dev/2017-July/071054.html It is very important to continue progressing on device syntax and bus rework during 17.11. Applied
Re: [dpdk-dev] [PATCH v2] doc: deprecate Xen support
> > > Following the calls on the mailing list: > > > http://dpdk.org/ml/archives/dev/2017-June/068151.html > > > The Technical Board decided to drop Xen dom0 support from EAL: > > > http://dpdk.org/ml/archives/dev/2017-June/068615.html > > > > > > Signed-off-by: Thomas Monjalon > > > Signed-off-by: Jianfeng Tan > > > > Acked-by: John McNamara > > Acked-by: Jerin Jacob Applied, thanks
Re: [dpdk-dev] [PATCH] eal: add notice to make DPDK IOVA aware
> > > > When we run DPDK on guest or VFIO mode on host, > > > > the dpdk library or device will not be directly accessing > > > > the physical address. Instead, the device does go through > > > > an IO address translation memory management unit. On x86, > > > > we call it as IOMMU and on ARM as SMMU. > > > > > > > > More details: > > > > http://osidays.com/osidays/wp-content/uploads/2014/12/Final_OSI2014_IOMMU_DetailedView_Sanil_Anurup.pdf > > > > > > > > Based on discussion in the following thread > > > > http://dpdk.org/ml/archives/dev/2017-July/070850.html > > > > > > > > We would like to change reference to physical address to more > > > > appropriate name as with IOMMU/SMMU with > > > > the device won't be dealing directly with the physical address. > > > > > > > > An ABI change is planned for 17.11 to change following > > > > data structure or functions to more appropriate name. > > > > Currently planned to change it iova as instead of phys > > > > > > > > Please note: The change will be only for the name and > > > > functional aspects of the API will remain same. > > > > > > > > Following functions/data structures name may change. > > > > This list is based on v17.05-rc1. It may change based on v17.11 code > > > > base. > > > > > > > > > > > > typedef: > > > > phys_addr_t > > > > > > > > structures: > > > > > > > > struct rte_memseg::phys_addr > > > > struct rte_mbuf::buf_physaddr > > > > > > > > functions: > > > > rte_mempool_populate_phys() > > > > rte_mempool_populate_phys_tab() > > > > rte_eal_using_phys_addrs() > > > > rte_mem_virt2phy() > > > > rte_dump_physmem_layout() > > > > rte_eal_get_physmem_layout() > > > > rte_eal_get_physmem_size() > > > > rte_malloc_virt2phy() > > > > rte_mem_phy2mch() > > > > > > > > Signed-off-by: Jerin Jacob > > > > > > Acked-by: Santosh Shukla > > > > > Acked-by: Hemant Agrawal > > Acked-by: Olivier Matz Acked-by: Thomas Monjalon The name will probably be discussed. Applied, thanks
Re: [dpdk-dev] [PATCH v2] doc: announce API/ABI changes for mempool
> > > An API/ABI change is planned for 17.11 to change following > > > > > > * Remove unused flag param from rte_mempool_generic_get and _put. > > > * Change data type for mempool 'flag' from int to unsigned int. > > > Refer [1]. > > > * Add struct rte_mempool * param into func rte_mempool_xmem_size, > > > rte_mempool_xmem_usage to make it mempool aware. > > > Refer [2]. > > > > > > [1] http://dpdk.org/dev/patchwork/patch/25603/ > > > [2] http://dpdk.org/dev/patchwork/patch/25605/ > > > > > > Signed-off-by: Santosh Shukla > > > > Acked-by: Jerin Jacob > > Acked-by: Olivier Matz Applied, thanks
Re: [dpdk-dev] [PATCH v3] doc: announce API and ABI change for ethdev
> -Original Message- > From: Yang, Zhiyong > Sent: Monday, August 7, 2017 8:43 PM > To: dev@dpdk.org > Cc: Tan, Jianfeng ; y...@fridaylinux.org; > jerin.ja...@caviumnetworks.com; tho...@monjalon.net; Horton, Remy > ; Yang, Zhiyong > Subject: [PATCH v3] doc: announce API and ABI change for ethdev > > This is an API/ABI change notice for DPDK 17.11 announcing the redefinition of > port_id. port_id is currently defined as uint8_t, which is limited to the > range 0 to > 255. A larger range is required for vdev scalability. > > It is necessary for a redefinition of port_id to extend it from 1 bytes to > 2 bytes. All ethdev APIs and usages related to port_id will be changed at the > same time. > > cc: jianfeng@intel.com > cc: y...@fridaylinux.org > cc: jerin.ja...@caviumnetworks.com > cc: tho...@monjalon.net > cc: remy.hor...@intel.com > > Signed-off-by: Zhiyong Yang > Acked-by: Jianfeng Tan > Acked-by: Yuanhan Liu > Acked-by: Jerin Jacob > Acked-by: Remy Horton > --- This ack in v2 is added in v3. Thanks, Shahaf. Acked-by: Shahaf Shuler
Re: [dpdk-dev] [PATCH] ethdev: add notice for planned name size change
Tuesday, August 8, 2017 1:20 AM, Yongseok Koh: > > On Jul 6, 2017, at 8:07 AM, Stephen Hemminger > wrote: > > > > VMBUS support will use GUID in eth_dev_data name field which requires > > at least 37 characters. Plan for increase in size now. > > > > Signed-off-by: Stephen Hemminger > > --- > > doc/guides/rel_notes/deprecation.rst | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index 2e708dbe0deb..d5b70c50064a 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -95,3 +95,7 @@ Deprecation Notices > > The non-"do-sig" versions of the hash tables will be removed > > (including the ``signature_offset`` parameter) > > and the "do-sig" versions renamed accordingly. > > + > > +* ethdev: An ABI change is planned for 17.11 for the structure > eth_dev_data. > Isn't it better to use "``rte_eth_dev_data``"? > > > + The size of the unique name will increase RTE_ETH_NAME_MAX_LEN > from > > + 32 to > > + 64 characters to allow using a globally unique identifier (GUID) in this > field. > > Except for the small comment above, > Acked-by: Yongseok Koh Acked-by: Shahaf Shuler > > Thanks, > Yongseok
Re: [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev and ethdev
Monday, August 7, 2017 9:07 PM, Boris Pismenny: > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > 04/08/2017 07:26, Hemant Agrawal: > > > On 8/3/2017 9:02 PM, Akhil Goyal wrote: > > > > Support for security operations is planned to be added in ethdev > > > > and cryptodev for the 17.11 release. > > > > > > > > For this following changes are required. > > > > - rte_cryptodev and rte_eth_dev structures need to be added new > > > > parameter rte_security_ops which extend support for security ops > > > > to the corresponding driver. > > > > - rte_cryptodev_info and rte_ethd_dev_info need to be added with > > > > rte_security_capabilities to identify the capabilities of the > > > > corresponding driver. > > > > It is not explained what is the fundamental difference between > > rte_security and rte_crypto? > > It looks to be just a technical workaround. > > rte_security is a layer between crypto and NIC. > > Today crypto sessions are created exclusively against crypto devices, but > they don't use network related fields, while the network namespace doesn't > use crypto related fields. We expect this API to represent crypto sessions > that combine network fields and allow to add/delete them for all devices. > > For NICs we will use rte_flow with rte_security for inline/full crypto > protocol > offload such as ESP. > > > > > Why the ABI would be changed by rte_security additions? > > > > > > Signed-off-by: Akhil Goyal > > > > > > > Acked-by: Hemant Agrawal > > > > No more opinions outside of NXP? > > It seems there is not yet a consensus on how to manage IPsec offloading. > > I heard there were some phone calls about these stuff but nothing > > clear appears publicly on the mailing list. > > Looks to be a community failure. > > We agreed to go ahead with this approach on one such phone call. I hope we > could use the dpdk github for development. > > Acked-by: Boris Pismenny Acked-by: Shahaf Shuler
[dpdk-dev] [PATCH] net/ixgbe: fix MAC VLAN filter fail problem
Add a mode type check for MAC VLAN mode, if fdir is
in this mode, it do not need to do Sanity check for x550.
Fixes: dc0c16105d2d2 ("ixgbe: fix X550 flow director check")
Signed-off-by: Wei Zhao
Signed-off-by: root
---
drivers/net/ixgbe/ixgbe_fdir.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ixgbe/ixgbe_fdir.c b/drivers/net/ixgbe/ixgbe_fdir.c
index eb2d558..7c10cab 100644
--- a/drivers/net/ixgbe/ixgbe_fdir.c
+++ b/drivers/net/ixgbe/ixgbe_fdir.c
@@ -1276,7 +1276,8 @@ ixgbe_fdir_filter_program(struct rte_eth_dev *dev,
rule->ixgbe_fdir.formatted.flow_type ==
IXGBE_ATR_FLOW_TYPE_IPV6) &&
(info->mask.src_port_mask != 0 ||
-info->mask.dst_port_mask != 0)) {
+info->mask.dst_port_mask != 0) &&
+rule->mode != RTE_FDIR_MODE_PERFECT_MAC_VLAN) {
PMD_DRV_LOG(ERR, "By this device,"
" IPv4 is not supported without"
" L4 protocol and ports masked!");
--
2.9.3
[dpdk-dev] [PATCH] net/ixgbe: fix MAC VLAN filter fail problem
Add a mode type check for MAC VLAN mode, if fdir is
in this mode, it do not need to do Sanity check for x550.
Fixes: dc0c16105d2d2 ("ixgbe: fix X550 flow director check")
Signed-off-by: Wei Zhao
---
drivers/net/ixgbe/ixgbe_fdir.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ixgbe/ixgbe_fdir.c b/drivers/net/ixgbe/ixgbe_fdir.c
index eb2d558..7c10cab 100644
--- a/drivers/net/ixgbe/ixgbe_fdir.c
+++ b/drivers/net/ixgbe/ixgbe_fdir.c
@@ -1276,7 +1276,8 @@ ixgbe_fdir_filter_program(struct rte_eth_dev *dev,
rule->ixgbe_fdir.formatted.flow_type ==
IXGBE_ATR_FLOW_TYPE_IPV6) &&
(info->mask.src_port_mask != 0 ||
-info->mask.dst_port_mask != 0)) {
+info->mask.dst_port_mask != 0) &&
+rule->mode != RTE_FDIR_MODE_PERFECT_MAC_VLAN) {
PMD_DRV_LOG(ERR, "By this device,"
" IPv4 is not supported without"
" L4 protocol and ports masked!");
--
2.9.3
Re: [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev and ethdev
Hi Pablo/Declan, On 8/4/2017 8:55 PM, De Lara Guarch, Pablo wrote: -Original Message- From: Akhil Goyal [mailto:akhil.go...@nxp.com] Sent: Thursday, August 3, 2017 4:32 PM To: dev@dpdk.org; Doherty, Declan ; tho...@monjalon.net; Nicolau, Radu ; avia...@mellanox.com; bor...@mellanox.com; hemant.agra...@nxp.com; De Lara Guarch, Pablo Cc: Akhil Goyal Subject: [PATCH] doc: announce ABI change for cryptodev and ethdev Support for security operations is planned to be added in ethdev and cryptodev for the 17.11 release. For this following changes are required. - rte_cryptodev and rte_eth_dev structures need to be added new parameter rte_security_ops which extend support for security ops to the corresponding driver. - rte_cryptodev_info and rte_ethd_dev_info need to be added with rte_security_capabilities to identify the capabilities of the corresponding driver. Signed-off-by: Akhil Goyal Not sure if this needed to be split into two patches, as this affects two libraries. At least, from cryptodev side: Acked-by: Pablo de Lara We would be needing one more ABI change, Can I send it now. I discovered it after I sent this patch. In the struct rte_crypto_sym_op, we would need to add a pointer to a security session in the union of session and xform. Also, Do I need to split this patch into two for crypto and eth? Regards, Akhil
