* [PATCH v6 1/8] mbuf: add function to dump ol flag list
From: Olivier Matz @ 2016-10-12 15:39 UTC (permalink / raw)
To: dev, pablo.de.lara.guarch; +Cc: thomas.monjalon
In-Reply-To: <1476286790-26271-1-git-send-email-olivier.matz@6wind.com>
The functions rte_get_rx_ol_flag_name() and rte_get_tx_ol_flag_name()
can dump one flag, or set of flag that are part of the same mask (ex:
PKT_TX_UDP_CKSUM, part of PKT_TX_L4_MASK). But they are not designed to
dump the list of flags contained in mbuf->ol_flags.
This commit introduce new functions to do that. Similarly to the packet
type dump functions, the goal is to factorize the code that could be
used in several applications and reduce the risk of desynchronization
between the flags and the dump functions.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
doc/guides/rel_notes/release_16_11.rst | 5 ++
lib/librte_mbuf/rte_mbuf.c | 101 +++++++++++++++++++++++++++++++++
lib/librte_mbuf/rte_mbuf.h | 28 +++++++++
lib/librte_mbuf/rte_mbuf_version.map | 2 +
4 files changed, 136 insertions(+)
diff --git a/doc/guides/rel_notes/release_16_11.rst b/doc/guides/rel_notes/release_16_11.rst
index 25c447d..0f04a39 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -99,6 +99,11 @@ New Features
* AES GCM/CTR mode
+* **Added functions to dump the offload flags as a string.**
+
+ Added two new functions ``rte_get_rx_ol_flag_list()`` and
+ ``rte_get_tx_ol_flag_list()`` to dump offload flags as a string.
+
Resolved Issues
---------------
diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index 04f9ed3..4e1fdd1 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -319,6 +319,54 @@ const char *rte_get_rx_ol_flag_name(uint64_t mask)
}
}
+struct flag_mask {
+ uint64_t flag;
+ uint64_t mask;
+ const char *default_name;
+};
+
+/* write the list of rx ol flags in buffer buf */
+int
+rte_get_rx_ol_flag_list(uint64_t mask, char *buf, size_t buflen)
+{
+ const struct flag_mask rx_flags[] = {
+ { PKT_RX_VLAN_PKT, PKT_RX_VLAN_PKT, NULL },
+ { PKT_RX_RSS_HASH, PKT_RX_RSS_HASH, NULL },
+ { PKT_RX_FDIR, PKT_RX_FDIR, NULL },
+ { PKT_RX_L4_CKSUM_BAD, PKT_RX_L4_CKSUM_BAD, NULL },
+ { PKT_RX_IP_CKSUM_BAD, PKT_RX_IP_CKSUM_BAD, NULL },
+ { PKT_RX_EIP_CKSUM_BAD, PKT_RX_EIP_CKSUM_BAD, NULL },
+ { PKT_RX_VLAN_STRIPPED, PKT_RX_VLAN_STRIPPED, NULL },
+ { PKT_RX_IEEE1588_PTP, PKT_RX_IEEE1588_PTP, NULL },
+ { PKT_RX_IEEE1588_TMST, PKT_RX_IEEE1588_TMST, NULL },
+ { PKT_RX_QINQ_STRIPPED, PKT_RX_QINQ_STRIPPED, NULL },
+ };
+ const char *name;
+ unsigned int i;
+ int ret;
+
+ if (buflen == 0)
+ return -1;
+
+ buf[0] = '\0';
+ for (i = 0; i < RTE_DIM(rx_flags); i++) {
+ if ((mask & rx_flags[i].mask) != rx_flags[i].flag)
+ continue;
+ name = rte_get_rx_ol_flag_name(rx_flags[i].flag);
+ if (name == NULL)
+ name = rx_flags[i].default_name;
+ ret = snprintf(buf, buflen, "%s ", name);
+ if (ret < 0)
+ return -1;
+ if ((size_t)ret >= buflen)
+ return -1;
+ buf += ret;
+ buflen -= ret;
+ }
+
+ return 0;
+}
+
/*
* Get the name of a TX offload flag. Must be kept synchronized with flag
* definitions in rte_mbuf.h.
@@ -345,3 +393,56 @@ const char *rte_get_tx_ol_flag_name(uint64_t mask)
default: return NULL;
}
}
+
+/* write the list of tx ol flags in buffer buf */
+int
+rte_get_tx_ol_flag_list(uint64_t mask, char *buf, size_t buflen)
+{
+ const struct flag_mask tx_flags[] = {
+ { PKT_TX_VLAN_PKT, PKT_TX_VLAN_PKT, NULL },
+ { PKT_TX_IP_CKSUM, PKT_TX_IP_CKSUM, NULL },
+ { PKT_TX_TCP_CKSUM, PKT_TX_L4_MASK, NULL },
+ { PKT_TX_SCTP_CKSUM, PKT_TX_L4_MASK, NULL },
+ { PKT_TX_UDP_CKSUM, PKT_TX_L4_MASK, NULL },
+ { PKT_TX_L4_NO_CKSUM, PKT_TX_L4_MASK, "PKT_TX_L4_NO_CKSUM" },
+ { PKT_TX_IEEE1588_TMST, PKT_TX_IEEE1588_TMST, NULL },
+ { PKT_TX_TCP_SEG, PKT_TX_TCP_SEG, NULL },
+ { PKT_TX_IPV4, PKT_TX_IPV4, NULL },
+ { PKT_TX_IPV6, PKT_TX_IPV6, NULL },
+ { PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IP_CKSUM, NULL },
+ { PKT_TX_OUTER_IPV4, PKT_TX_OUTER_IPV4, NULL },
+ { PKT_TX_OUTER_IPV6, PKT_TX_OUTER_IPV6, NULL },
+ { PKT_TX_TUNNEL_VXLAN, PKT_TX_TUNNEL_MASK,
+ "PKT_TX_TUNNEL_NONE" },
+ { PKT_TX_TUNNEL_GRE, PKT_TX_TUNNEL_MASK,
+ "PKT_TX_TUNNEL_NONE" },
+ { PKT_TX_TUNNEL_IPIP, PKT_TX_TUNNEL_MASK,
+ "PKT_TX_TUNNEL_NONE" },
+ { PKT_TX_TUNNEL_GENEVE, PKT_TX_TUNNEL_MASK,
+ "PKT_TX_TUNNEL_NONE" },
+ };
+ const char *name;
+ unsigned int i;
+ int ret;
+
+ if (buflen == 0)
+ return -1;
+
+ buf[0] = '\0';
+ for (i = 0; i < RTE_DIM(tx_flags); i++) {
+ if ((mask & tx_flags[i].mask) != tx_flags[i].flag)
+ continue;
+ name = rte_get_tx_ol_flag_name(tx_flags[i].flag);
+ if (name == NULL)
+ name = tx_flags[i].default_name;
+ ret = snprintf(buf, buflen, "%s ", name);
+ if (ret < 0)
+ return -1;
+ if ((size_t)ret >= buflen)
+ return -1;
+ buf += ret;
+ buflen -= ret;
+ }
+
+ return 0;
+}
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 55bc389..7541070 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -252,6 +252,20 @@ extern "C" {
const char *rte_get_rx_ol_flag_name(uint64_t mask);
/**
+ * Dump the list of RX offload flags in a buffer
+ *
+ * @param mask
+ * The mask describing the RX flags.
+ * @param buf
+ * The output buffer.
+ * @param buflen
+ * The length of the buffer.
+ * @return
+ * 0 on success, (-1) on error.
+ */
+int rte_get_rx_ol_flag_list(uint64_t mask, char *buf, size_t buflen);
+
+/**
* Get the name of a TX offload flag
*
* @param mask
@@ -264,6 +278,20 @@ const char *rte_get_rx_ol_flag_name(uint64_t mask);
const char *rte_get_tx_ol_flag_name(uint64_t mask);
/**
+ * Dump the list of TX offload flags in a buffer
+ *
+ * @param mask
+ * The mask describing the TX flags.
+ * @param buf
+ * The output buffer.
+ * @param buflen
+ * The length of the buffer.
+ * @return
+ * 0 on success, (-1) on error.
+ */
+int rte_get_tx_ol_flag_list(uint64_t mask, char *buf, size_t buflen);
+
+/**
* Some NICs need at least 2KB buffer to RX standard Ethernet frame without
* splitting it into multiple segments.
* So, for mbufs that planned to be involved into RX/TX, the recommended
diff --git a/lib/librte_mbuf/rte_mbuf_version.map b/lib/librte_mbuf/rte_mbuf_version.map
index 5455ba6..6e2ea84 100644
--- a/lib/librte_mbuf/rte_mbuf_version.map
+++ b/lib/librte_mbuf/rte_mbuf_version.map
@@ -31,5 +31,7 @@ DPDK_16.11 {
rte_get_ptype_l4_name;
rte_get_ptype_name;
rte_get_ptype_tunnel_name;
+ rte_get_rx_ol_flag_list;
+ rte_get_tx_ol_flag_list;
} DPDK_2.1;
--
2.8.1
^ permalink raw reply related
* [PATCH v6 3/8] app/testpmd: dump Rx flags in csum engine
From: Olivier Matz @ 2016-10-12 15:39 UTC (permalink / raw)
To: dev, pablo.de.lara.guarch; +Cc: thomas.monjalon
In-Reply-To: <1476286790-26271-1-git-send-email-olivier.matz@6wind.com>
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
app/test-pmd/csumonly.c | 31 +++++++++++++++++--------------
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 2ecd6b8..42974d5 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -652,7 +652,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
uint16_t nb_rx;
uint16_t nb_tx;
uint16_t i;
- uint64_t ol_flags;
+ uint64_t rx_ol_flags, tx_ol_flags;
uint16_t testpmd_ol_flags;
uint32_t retry;
uint32_t rx_bad_ip_csum;
@@ -693,13 +693,14 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
rte_prefetch0(rte_pktmbuf_mtod(pkts_burst[i + 1],
void *));
- ol_flags = 0;
- info.is_tunnel = 0;
m = pkts_burst[i];
+ info.is_tunnel = 0;
+ tx_ol_flags = 0;
+ rx_ol_flags = m->ol_flags;
/* Update the L3/L4 checksum error packet statistics */
- rx_bad_ip_csum += ((m->ol_flags & PKT_RX_IP_CKSUM_BAD) != 0);
- rx_bad_l4_csum += ((m->ol_flags & PKT_RX_L4_CKSUM_BAD) != 0);
+ rx_bad_ip_csum += ((rx_ol_flags & PKT_RX_IP_CKSUM_BAD) != 0);
+ rx_bad_l4_csum += ((rx_ol_flags & PKT_RX_L4_CKSUM_BAD) != 0);
/* step 1: dissect packet, parsing optional vlan, ip4/ip6, vxlan
* and inner headers */
@@ -721,7 +722,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
info.l3_len);
parse_vxlan(udp_hdr, &info, m->packet_type);
if (info.is_tunnel)
- ol_flags |= PKT_TX_TUNNEL_VXLAN;
+ tx_ol_flags |= PKT_TX_TUNNEL_VXLAN;
} else if (info.l4_proto == IPPROTO_GRE) {
struct simple_gre_hdr *gre_hdr;
@@ -729,14 +730,14 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
((char *)l3_hdr + info.l3_len);
parse_gre(gre_hdr, &info);
if (info.is_tunnel)
- ol_flags |= PKT_TX_TUNNEL_GRE;
+ tx_ol_flags |= PKT_TX_TUNNEL_GRE;
} else if (info.l4_proto == IPPROTO_IPIP) {
void *encap_ip_hdr;
encap_ip_hdr = (char *)l3_hdr + info.l3_len;
parse_encap_ip(encap_ip_hdr, &info);
if (info.is_tunnel)
- ol_flags |= PKT_TX_TUNNEL_IPIP;
+ tx_ol_flags |= PKT_TX_TUNNEL_IPIP;
}
}
@@ -759,15 +760,16 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
* is configured, prepare the mbuf for TCP segmentation. */
/* process checksums of inner headers first */
- ol_flags |= process_inner_cksums(l3_hdr, &info, testpmd_ol_flags);
+ tx_ol_flags |= process_inner_cksums(l3_hdr, &info,
+ testpmd_ol_flags);
/* Then process outer headers if any. Note that the software
* checksum will be wrong if one of the inner checksums is
* processed in hardware. */
if (info.is_tunnel == 1) {
- ol_flags |= process_outer_cksums(outer_l3_hdr, &info,
+ tx_ol_flags |= process_outer_cksums(outer_l3_hdr, &info,
testpmd_ol_flags,
- !!(ol_flags & PKT_TX_TCP_SEG));
+ !!(tx_ol_flags & PKT_TX_TCP_SEG));
}
/* step 4: fill the mbuf meta data (flags and header lengths) */
@@ -802,7 +804,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
m->l4_len = info.l4_len;
m->tso_segsz = info.tso_segsz;
}
- m->ol_flags = ol_flags;
+ m->ol_flags = tx_ol_flags;
/* Do split & copy for the packet. */
if (tx_pkt_split != TX_PKT_SPLIT_OFF) {
@@ -822,10 +824,11 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
printf("mbuf=%p, pkt_len=%u, nb_segs=%hhu:\n",
m, m->pkt_len, m->nb_segs);
/* dump rx parsed packet info */
+ rte_get_rx_ol_flag_list(rx_ol_flags, buf, sizeof(buf));
printf("rx: l2_len=%d ethertype=%x l3_len=%d "
- "l4_proto=%d l4_len=%d\n",
+ "l4_proto=%d l4_len=%d flags=%s\n",
info.l2_len, rte_be_to_cpu_16(info.ethertype),
- info.l3_len, info.l4_proto, info.l4_len);
+ info.l3_len, info.l4_proto, info.l4_len, buf);
if (info.is_tunnel == 1)
printf("rx: outer_l2_len=%d outer_ethertype=%x "
"outer_l3_len=%d\n", info.outer_l2_len,
--
2.8.1
^ permalink raw reply related
* [PATCH v6 8/8] app/testpmd: hide segsize when unrelevant in csum engine
From: Olivier Matz @ 2016-10-12 15:39 UTC (permalink / raw)
To: dev, pablo.de.lara.guarch; +Cc: thomas.monjalon
In-Reply-To: <1476286790-26271-1-git-send-email-olivier.matz@6wind.com>
When TSO is not asked, hide the segment size.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
app/test-pmd/csumonly.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index d51d85a..f9e65b6 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -843,10 +843,12 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
"m->outer_l3_len=%d\n",
m->outer_l2_len,
m->outer_l3_len);
- if (info.tunnel_tso_segsz != 0)
+ if (info.tunnel_tso_segsz != 0 &&
+ (m->ol_flags & PKT_TX_TCP_SEG))
printf("tx: m->tso_segsz=%d\n",
m->tso_segsz);
- } else if (info.tso_segsz != 0)
+ } else if (info.tso_segsz != 0 &&
+ (m->ol_flags & PKT_TX_TCP_SEG))
printf("tx: m->tso_segsz=%d\n", m->tso_segsz);
rte_get_tx_ol_flag_list(m->ol_flags, buf, sizeof(buf));
printf("tx: flags=%s", buf);
--
2.8.1
^ permalink raw reply related
* [PATCH v6 4/8] app/testpmd: add option to enable lro
From: Olivier Matz @ 2016-10-12 15:39 UTC (permalink / raw)
To: dev, pablo.de.lara.guarch; +Cc: thomas.monjalon
In-Reply-To: <1476286790-26271-1-git-send-email-olivier.matz@6wind.com>
Introduce a new argument '--enable-lro' to ask testpmd to enable the LRO
feature on enabled ports, like it's done for '--enable-rx-cksum' for
instance.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
app/test-pmd/parameters.c | 4 ++++
doc/guides/testpmd_app_ug/run_app.rst | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index 6a6a07e..c45f78a 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -149,6 +149,7 @@ usage(char* progname)
"If the drop-queue doesn't exist, the packet is dropped. "
"By default drop-queue=127.\n");
printf(" --crc-strip: enable CRC stripping by hardware.\n");
+ printf(" --enable-lro: enable large receive offload.\n");
printf(" --enable-rx-cksum: enable rx hardware checksum offload.\n");
printf(" --disable-hw-vlan: disable hardware vlan.\n");
printf(" --disable-hw-vlan-filter: disable hardware vlan filter.\n");
@@ -524,6 +525,7 @@ launch_args_parse(int argc, char** argv)
{ "pkt-filter-size", 1, 0, 0 },
{ "pkt-filter-drop-queue", 1, 0, 0 },
{ "crc-strip", 0, 0, 0 },
+ { "enable-lro", 0, 0, 0 },
{ "enable-rx-cksum", 0, 0, 0 },
{ "enable-scatter", 0, 0, 0 },
{ "disable-hw-vlan", 0, 0, 0 },
@@ -764,6 +766,8 @@ launch_args_parse(int argc, char** argv)
}
if (!strcmp(lgopts[opt_idx].name, "crc-strip"))
rx_mode.hw_strip_crc = 1;
+ if (!strcmp(lgopts[opt_idx].name, "enable-lro"))
+ rx_mode.enable_lro = 1;
if (!strcmp(lgopts[opt_idx].name, "enable-scatter"))
rx_mode.enable_scatter = 1;
if (!strcmp(lgopts[opt_idx].name, "enable-rx-cksum"))
diff --git a/doc/guides/testpmd_app_ug/run_app.rst b/doc/guides/testpmd_app_ug/run_app.rst
index 7712bd2..55c7ac0 100644
--- a/doc/guides/testpmd_app_ug/run_app.rst
+++ b/doc/guides/testpmd_app_ug/run_app.rst
@@ -285,6 +285,10 @@ The commandline options are:
Enable hardware CRC stripping.
+* ``--enable-lro``
+
+ Enable large receive offload.
+
* ``--enable-rx-cksum``
Enable hardware RX checksum offload.
--
2.8.1
^ permalink raw reply related
* [PATCH v6 5/8] app/testpmd: do not change ip addrs in csum engine
From: Olivier Matz @ 2016-10-12 15:39 UTC (permalink / raw)
To: dev, pablo.de.lara.guarch; +Cc: thomas.monjalon
In-Reply-To: <1476286790-26271-1-git-send-email-olivier.matz@6wind.com>
The csum forward engine was updated to change the IP addresses in the
packet data in
commit 51f694dd40f5 ("app/testpmd: rework checksum forward engine")
This was done to ensure that the checksum is correctly reprocessed when
using hardware checksum offload. But the functions
process_inner_cksums() and process_outer_cksums() already reset the
checksum field to 0, so this is not necessary.
Moreover, this makes the engine more complex than needed, and prevents
to easily use it to forward traffic (like iperf) as it modifies the
packets.
This patch drops this behavior.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
app/test-pmd/csumonly.c | 27 ++-------------------------
1 file changed, 2 insertions(+), 25 deletions(-)
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 42974d5..34d4b11 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -318,21 +318,6 @@ parse_encap_ip(void *encap_ip, struct testpmd_offload_info *info)
info->l2_len = 0;
}
-/* modify the IPv4 or IPv4 source address of a packet */
-static void
-change_ip_addresses(void *l3_hdr, uint16_t ethertype)
-{
- struct ipv4_hdr *ipv4_hdr = l3_hdr;
- struct ipv6_hdr *ipv6_hdr = l3_hdr;
-
- if (ethertype == _htons(ETHER_TYPE_IPv4)) {
- ipv4_hdr->src_addr =
- rte_cpu_to_be_32(rte_be_to_cpu_32(ipv4_hdr->src_addr) + 1);
- } else if (ethertype == _htons(ETHER_TYPE_IPv6)) {
- ipv6_hdr->src_addr[15] = ipv6_hdr->src_addr[15] + 1;
- }
-}
-
/* if possible, calculate the checksum of a packet in hw or sw,
* depending on the testpmd command line configuration */
static uint64_t
@@ -620,7 +605,6 @@ pkt_copy_split(const struct rte_mbuf *pkt)
* Receive a burst of packets, and for each packet:
* - parse packet, and try to recognize a supported packet type (1)
* - if it's not a supported packet type, don't touch the packet, else:
- * - modify the IPs in inner headers and in outer headers if any
* - reprocess the checksum of all supported layers. This is done in SW
* or HW, depending on testpmd command line configuration
* - if TSO is enabled in testpmd command line, also flag the mbuf for TCP
@@ -747,14 +731,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
l3_hdr = (char *)l3_hdr + info.outer_l3_len + info.l2_len;
}
- /* step 2: change all source IPs (v4 or v6) so we need
- * to recompute the chksums even if they were correct */
-
- change_ip_addresses(l3_hdr, info.ethertype);
- if (info.is_tunnel == 1)
- change_ip_addresses(outer_l3_hdr, info.outer_ethertype);
-
- /* step 3: depending on user command line configuration,
+ /* step 2: depending on user command line configuration,
* recompute checksum either in software or flag the
* mbuf to offload the calculation to the NIC. If TSO
* is configured, prepare the mbuf for TCP segmentation. */
@@ -772,7 +749,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
!!(tx_ol_flags & PKT_TX_TCP_SEG));
}
- /* step 4: fill the mbuf meta data (flags and header lengths) */
+ /* step 3: fill the mbuf meta data (flags and header lengths) */
if (info.is_tunnel == 1) {
if (info.tunnel_tso_segsz ||
--
2.8.1
^ permalink raw reply related
* [PATCH v6 2/8] app/testpmd: use new function to dump offload flags
From: Olivier Matz @ 2016-10-12 15:39 UTC (permalink / raw)
To: dev, pablo.de.lara.guarch; +Cc: thomas.monjalon
In-Reply-To: <1476286790-26271-1-git-send-email-olivier.matz@6wind.com>
Use the functions introduced in the previous commit to dump the offload
flags.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
app/test-pmd/csumonly.c | 31 +++----------------------------
app/test-pmd/rxonly.c | 15 ++-------------
2 files changed, 5 insertions(+), 41 deletions(-)
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 4fe038d..2ecd6b8 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -816,27 +816,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
/* if verbose mode is enabled, dump debug info */
if (verbose_level > 0) {
- struct {
- uint64_t flag;
- uint64_t mask;
- } tx_flags[] = {
- { PKT_TX_IP_CKSUM, PKT_TX_IP_CKSUM },
- { PKT_TX_UDP_CKSUM, PKT_TX_L4_MASK },
- { PKT_TX_TCP_CKSUM, PKT_TX_L4_MASK },
- { PKT_TX_SCTP_CKSUM, PKT_TX_L4_MASK },
- { PKT_TX_IPV4, PKT_TX_IPV4 },
- { PKT_TX_IPV6, PKT_TX_IPV6 },
- { PKT_TX_OUTER_IP_CKSUM, PKT_TX_OUTER_IP_CKSUM },
- { PKT_TX_OUTER_IPV4, PKT_TX_OUTER_IPV4 },
- { PKT_TX_OUTER_IPV6, PKT_TX_OUTER_IPV6 },
- { PKT_TX_TCP_SEG, PKT_TX_TCP_SEG },
- { PKT_TX_TUNNEL_VXLAN, PKT_TX_TUNNEL_MASK },
- { PKT_TX_TUNNEL_GRE, PKT_TX_TUNNEL_MASK },
- { PKT_TX_TUNNEL_IPIP, PKT_TX_TUNNEL_MASK },
- { PKT_TX_TUNNEL_GENEVE, PKT_TX_TUNNEL_MASK },
- };
- unsigned j;
- const char *name;
+ char buf[256];
printf("-----------------\n");
printf("mbuf=%p, pkt_len=%u, nb_segs=%hhu:\n",
@@ -872,13 +852,8 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
m->tso_segsz);
} else if (info.tso_segsz != 0)
printf("tx: m->tso_segsz=%d\n", m->tso_segsz);
- printf("tx: flags=");
- for (j = 0; j < sizeof(tx_flags)/sizeof(*tx_flags); j++) {
- name = rte_get_tx_ol_flag_name(tx_flags[j].flag);
- if ((m->ol_flags & tx_flags[j].mask) ==
- tx_flags[j].flag)
- printf("%s ", name);
- }
+ rte_get_tx_ol_flag_list(m->ol_flags, buf, sizeof(buf));
+ printf("tx: flags=%s", buf);
printf("\n");
}
}
diff --git a/app/test-pmd/rxonly.c b/app/test-pmd/rxonly.c
index 9acc4c6..fff815c 100644
--- a/app/test-pmd/rxonly.c
+++ b/app/test-pmd/rxonly.c
@@ -229,19 +229,8 @@ pkt_burst_receive(struct fwd_stream *fs)
}
printf(" - Receive queue=0x%x", (unsigned) fs->rx_queue);
printf("\n");
- if (ol_flags != 0) {
- unsigned rxf;
- const char *name;
-
- for (rxf = 0; rxf < sizeof(mb->ol_flags) * 8; rxf++) {
- if ((ol_flags & (1ULL << rxf)) == 0)
- continue;
- name = rte_get_rx_ol_flag_name(1ULL << rxf);
- if (name == NULL)
- continue;
- printf(" %s\n", name);
- }
- }
+ rte_get_rx_ol_flag_list(mb->ol_flags, buf, sizeof(buf));
+ printf(" ol_flags: %s\n", buf);
rte_pktmbuf_free(mb);
}
--
2.8.1
^ permalink raw reply related
* [PATCH v6 6/8] app/testpmd: display Rx port in csum engine
From: Olivier Matz @ 2016-10-12 15:39 UTC (permalink / raw)
To: dev, pablo.de.lara.guarch; +Cc: thomas.monjalon
In-Reply-To: <1476286790-26271-1-git-send-email-olivier.matz@6wind.com>
This information is useful when debugging, especially with
bidirectional traffic.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
app/test-pmd/csumonly.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 34d4b11..dbd8dc4 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -798,8 +798,8 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
char buf[256];
printf("-----------------\n");
- printf("mbuf=%p, pkt_len=%u, nb_segs=%hhu:\n",
- m, m->pkt_len, m->nb_segs);
+ printf("port=%u, mbuf=%p, pkt_len=%u, nb_segs=%hhu:\n",
+ fs->rx_port, m, m->pkt_len, m->nb_segs);
/* dump rx parsed packet info */
rte_get_rx_ol_flag_list(rx_ol_flags, buf, sizeof(buf));
printf("rx: l2_len=%d ethertype=%x l3_len=%d "
--
2.8.1
^ permalink raw reply related
* [PATCH v6 7/8] app/testpmd: don't use tso if packet is too small
From: Olivier Matz @ 2016-10-12 15:39 UTC (permalink / raw)
To: dev, pablo.de.lara.guarch; +Cc: thomas.monjalon
In-Reply-To: <1476286790-26271-1-git-send-email-olivier.matz@6wind.com>
Asking for TSO (TCP Segmentation Offload) on packets that are already
smaller than (headers + MSS) does not work, for instance on ixgbe.
Fix the csumonly engine to only set the TSO flag when a segmentation
offload is really required, i.e. when packet is large enough.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
app/test-pmd/csumonly.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index dbd8dc4..d51d85a 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -102,6 +102,7 @@ struct testpmd_offload_info {
uint8_t outer_l4_proto;
uint16_t tso_segsz;
uint16_t tunnel_tso_segsz;
+ uint32_t pkt_len;
};
/* simplified GRE header */
@@ -329,6 +330,21 @@ process_inner_cksums(void *l3_hdr, const struct testpmd_offload_info *info,
struct tcp_hdr *tcp_hdr;
struct sctp_hdr *sctp_hdr;
uint64_t ol_flags = 0;
+ uint32_t max_pkt_len, tso_segsz = 0;
+
+ /* ensure packet is large enough to require tso */
+ if (!info->is_tunnel) {
+ max_pkt_len = info->l2_len + info->l3_len + info->l4_len +
+ info->tso_segsz;
+ if (info->tunnel_tso_segsz != 0 && info->pkt_len > max_pkt_len)
+ tso_segsz = info->tso_segsz;
+ } else {
+ max_pkt_len = info->outer_l2_len + info->outer_l3_len +
+ info->l2_len + info->l3_len + info->l4_len +
+ info->tunnel_tso_segsz;
+ if (info->tunnel_tso_segsz != 0 && info->pkt_len > max_pkt_len)
+ tso_segsz = info->tunnel_tso_segsz;
+ }
if (info->ethertype == _htons(ETHER_TYPE_IPv4)) {
ipv4_hdr = l3_hdr;
@@ -369,8 +385,7 @@ process_inner_cksums(void *l3_hdr, const struct testpmd_offload_info *info,
} else if (info->l4_proto == IPPROTO_TCP) {
tcp_hdr = (struct tcp_hdr *)((char *)l3_hdr + info->l3_len);
tcp_hdr->cksum = 0;
- if ((info->is_tunnel && info->tunnel_tso_segsz != 0) ||
- (!info->is_tunnel && info->tso_segsz != 0)) {
+ if (tso_segsz) {
ol_flags |= PKT_TX_TCP_SEG;
tcp_hdr->cksum = get_psd_sum(l3_hdr, info->ethertype,
ol_flags);
@@ -679,6 +694,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
m = pkts_burst[i];
info.is_tunnel = 0;
+ info.pkt_len = rte_pktmbuf_pkt_len(m);
tx_ol_flags = 0;
rx_ol_flags = m->ol_flags;
--
2.8.1
^ permalink raw reply related
* Re: [PATCH v8 2/2] app/test_pmd: add tests for new API's
From: Iremonger, Bernard @ 2016-10-12 15:48 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev@dpdk.org, Shah, Rahul R, Lu, Wenzhuo, az5157@att.com,
De Lara Guarch, Pablo
In-Reply-To: <2791430.Y8ncTCNxt5@xps13>
Hi Thomas,
<snip>
> Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for new
> API's
>
> 2016-10-12 15:27, Iremonger, Bernard:
> > Hi Thomas,
> >
> > <snip>
> >
> > > Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for
> > > new API's
> > >
> > > 2016-10-12 16:03, Bernard Iremonger:
> > > > --- a/app/test-pmd/Makefile
> > > > +++ b/app/test-pmd/Makefile
> > > > @@ -58,6 +58,17 @@ SRCS-y += csumonly.c SRCS-y += icmpecho.c
> > > > SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
> > > >
> > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
> > > > +LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> endif
> > > > +
> > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> > > > +ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
> > > > +LDLIBS += -lrte_pmd_ixgbe
> > > > +endif
> > > > +endif
> > >
> > > Sorry if I miss something, but I thought it was enough to do:
> > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> >
> > No unfortunately not, the above line does not work for all scenarios .
> >
> > There are 4 scenarios as follows:
> >
> > CONFIG_RTE_LIBRTE_IXGBE_PMD=y with
> CONFIG_RTE_BUILD_SHARED_LIB=n
> >
> > CONFIG_RTE_LIBRTE_IXGBE_PMD=y with
> CONFIG_RTE_BUILD_SHARED_LIB=y
> >
> > CONFIG_RTE_LIBRTE_IXGBE_PMD=n with
> CONFIG_RTE_BUILD_SHARED_LIB=y
> >
> > CONFIG_RTE_LIBRTE_IXGBE_PMD=n with
> CONFIG_RTE_BUILD_SHARED_LIB=n
> >
> > I have been doing quite a bit of building today to get it to work in all 4
> scenarios.
>
> I have a doubt about the tests because LDLIBS-y does not exist.
> There is _LDLIBS-y and LDLIBS.
> But in the static case, you wrote:
> LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> endif Please could you check?
LDLIBS-y exists in some of the scenarios but not all.
Do you want me to check the four scenarios with just the line below.
LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
Regards,
Bernard.
^ permalink raw reply
* Re: [PATCH v4 1/2] i40e: Add packet_type metadata in the i40e vPMD
From: Bruce Richardson @ 2016-10-12 15:51 UTC (permalink / raw)
To: Chen, Jing D
Cc: Shaw, Jeffrey B, dev@dpdk.org, Zhang, Helin, Wu, Jingjing,
damarion@cisco.com, Zhang, Qi Z
In-Reply-To: <4341B239C0EFF9468EE453F9E9F4604D3A387F65@shsmsx102.ccr.corp.intel.com>
On Thu, Oct 06, 2016 at 03:28:39PM +0000, Chen, Jing D wrote:
>
> > -----Original Message-----
> > From: Shaw, Jeffrey B
> > Sent: Wednesday, October 5, 2016 11:38 PM
> > To: dev@dpdk.org
> > Cc: Zhang, Helin <helin.zhang@intel.com>; Wu, Jingjing
> > <jingjing.wu@intel.com>; damarion@cisco.com; Zhang, Qi Z
> > <qi.z.zhang@intel.com>; Chen, Jing D <jing.d.chen@intel.com>
> > Subject: [PATCH v4 1/2] i40e: Add packet_type metadata in the i40e vPMD
> >
> > From: Damjan Marion <damarion@cisco.com>
> >
> > The ptype is decoded from the rx descriptor and stored in the packet type
> > field in the mbuf using the same function as the non-vector driver.
> >
> > Signed-off-by: Damjan Marion <damarion@cisco.com>
> > Signed-off-by: Jeff Shaw <jeffrey.b.shaw@intel.com>
> > Acked-by: Qi Zhang <qi.z.zhang@intel.com>
> > ---
> >
> > Changes in v2:
> > - Add missing reference to i40e_recv_scattered_pkts_vec() when
> > querying supported packet types.
> >
> > Changes in v3:
> > - None. (Please ignore this version).
> >
> > Changes in v4:
> > - Fix rss/fdir status mask and shift to get accurate Flow Director Filter
> > Match (FLM) indication.
> >
> > drivers/net/i40e/i40e_rxtx.c | 567 +--------------------------------------
> > drivers/net/i40e/i40e_rxtx.h | 563
> > ++++++++++++++++++++++++++++++++++++++
> > drivers/net/i40e/i40e_rxtx_vec.c | 16 ++
> > 3 files changed, 582 insertions(+), 564 deletions(-)
> Acked-by : Jing Chen <jing.d.chen@intel.com>
>
Series applied to dpdk-next-net/rel_16_11
/Bruce
^ permalink raw reply
* Re: [PATCH v2 09/12] virtio: add Rx checksum offload support
From: Olivier MATZ @ 2016-10-12 15:55 UTC (permalink / raw)
To: Yuanhan Liu, Maxime Coquelin
Cc: dev, konstantin.ananyev, sugesh.chandran, bruce.richardson,
jianfeng.tan, helin.zhang, adrien.mazarguil, stephen, dprovan,
xiao.w.wang
In-Reply-To: <20161012130237.GM16751@yliu-dev.sh.intel.com>
On 10/12/2016 03:02 PM, Yuanhan Liu wrote:
> On Wed, Oct 05, 2016 at 03:27:47PM +0200, Maxime Coquelin wrote:
>>> /* Update offload features */
>>> - if (virtio_rx_offload(rxm, hdr) < 0) {
>>> + if ((features & VIRTIO_NET_F_GUEST_CSUM) &&
>> s/VIRTIO_NET_F_GUEST_CSUM/(1u << VIRTIO_NET_F_GUEST_CSUM)/
>
> There is a helper function for that: vtpci_with_feature.
Ok, will use it.
Thanks,
Olivier
^ permalink raw reply
* Re: [PATCH v2 00/15] Add support for secondary queue set in nicvf thunderx driver
From: Bruce Richardson @ 2016-10-12 15:59 UTC (permalink / raw)
To: Kamil Rytarowski
Cc: dev, maciej.czekaj, zyta.szpak, slawomir.rosek, rad, jerin.jacob,
ferruh.yigit, john.mcnamara
In-Reply-To: <1475237154-25388-1-git-send-email-krytarowski@caviumnetworks.com>
On Fri, Sep 30, 2016 at 02:05:39PM +0200, Kamil Rytarowski wrote:
> This series of patches adds support for secondary queue set in nicvf thunderx
> driver
>
> There are two types of VFs:
> - Primary VF
> - Secondary VF
>
> Each port consist of a primary VF and n secondary VF(s). Each VF provides 8
> Tx/Rx queues to a port. In case port is configured to use more than 8 queues,
> then it requires one (or more) secondary VF. Each secondary VF adds additional
> 8 queues to the queue set.
>
> During PMD driver initialization, the primary VF's are enumerated by checking the
> specific flag (see READY message). They are at the beginning of VF list (the remain
> ones are secondary VF's).
>
> The primary VFs are used as master queue sets. Secondary VFs provide
> additional queue sets for primary ones. If a port is configured for more then
> 8 queues then it will request for additional queues from secondary VFs.
>
> Secondary VFs cannot be shared between primary VFs.
>
> Primary VFs are present on the tail of the 'Network devices using kernel
> driver' list, secondary VFs are on the remaining tail of the list.
>
> The VNIC driver in the multiqueue setup works differently than other drivers
> like `ixgbe`. We need to bind separately each specific queue set device with
> the ``tools/dpdk-devbind.py`` utility.
>
> Depending on the hardware used, the kernel driver sets a threshold ``vf_id``.
> VFs that try to attach with an id below or equal to this boundary are
> considered primary VFs. VFs that try to attach with an id above this boundary
> are considered secondary VFs.
>
> This patchset also contains other cleanups and improvements like fixing
> erroneous checksum calculation and preparing the thunderx driver for the multi
> queue set feature support.
>
>
> These changes base on the following pending patches:
>
> [dpdk-dev,1/3] net/thunderx: remove generic passx references from the driver
> http://dpdk.org/dev/patchwork/patch/14963/
>
> [dpdk-dev,2/3] net/thunderx: introduce cqe_rx2 HW capability flag
> http://dpdk.org/dev/patchwork/patch/14964/
>
> [dpdk-dev,3/3] net/thunderx: add 81xx SoC support
> http://dpdk.org/dev/patchwork/patch/14965/
>
> Kamil Rytarowski (15):
> net/thunderx: cleanup the driver before adding new features
> net/thunderx: correct transmit checksum handling
> net/thunderx/base: add family of functions to store qsets
> net/thunderx/base: add secondary queue set support
> net/thunderx: add family of functions to store DPDK qsets
> net/thunderx: add secondary queue set in interrupt functions
> net/thunderx: remove problematic private_data->eth_dev link
> net/thunderx: add helper utils for secondary qset support
> net/thunderx: add secondary qset support in dev stop/close
> net/thunderx: add secondary qset support in device start
> net/thunderx: add secondary qset support in device configure
> net/thunderx: add final bits for secondary queue support
> net/thunderx: document secondary queue set support
> ethdev: Support VFs on the different PCI domains
> net/thunderx: Bump driver version to 2.0
>
Series applied to dpdk-next-net/rel_16_11, with the exception of patch 14 which
has been resubmitted as a separate ethdev patch:
http://dpdk.org/dev/patchwork/patch/16480/
/Bruce
^ permalink raw reply
* Re: [PATCH v2 03/12] virtio: reinitialize the device in configure callback
From: Olivier MATZ @ 2016-10-12 16:01 UTC (permalink / raw)
To: Yuanhan Liu
Cc: dev, konstantin.ananyev, sugesh.chandran, bruce.richardson,
jianfeng.tan, helin.zhang, adrien.mazarguil, stephen, dprovan,
xiao.w.wang
In-Reply-To: <20161012144108.GN16751@yliu-dev.sh.intel.com>
Hello Yuanhan,
On 10/12/2016 04:41 PM, Yuanhan Liu wrote:
> On Mon, Oct 03, 2016 at 11:00:14AM +0200, Olivier Matz wrote:
>> @@ -1344,6 +1347,7 @@ virtio_dev_configure(struct rte_eth_dev *dev)
>> {
>> const struct rte_eth_rxmode *rxmode = &dev->data->dev_conf.rxmode;
>> struct virtio_hw *hw = dev->data->dev_private;
>> + uint64_t req_features;
>> int ret;
>>
>> PMD_INIT_LOG(DEBUG, "configure");
>> @@ -1353,6 +1357,14 @@ virtio_dev_configure(struct rte_eth_dev *dev)
>> return -EINVAL;
>> }
>>
>> + req_features = VIRTIO_PMD_GUEST_FEATURES;
>> + /* if request features changed, reinit the device */
>> + if (req_features != hw->req_guest_features) {
>> + ret = virtio_init_device(dev, req_features);
>> + if (ret < 0)
>> + return ret;
>> + }
>
> Why do you have to reset virtio here? This doesn't make too much sense
> to me.
>
> IIUC, you want to make sure those TSO related features being unset at
> init time, and enable it (by doing reset) when it's asked to be enabled
> (by rte_eth_dev_configure)?
>
> Why not always setting those features? We could do the actual offloads
> when:
>
> - those features have been negoiated
>
> - they are enabled through rte_eth_dev_configure
>
> With that, I think we could avoid the reset here?
It would work for TX, since you decide to use or not the feature. But I
think this won't work for RX: if you negociate LRO at init, the host may
send you large packets, even if LRO is disabled in dev_configure.
Regards,
Olivier
^ permalink raw reply
* Re: [PATCH v8 2/2] app/test_pmd: add tests for new API's
From: Thomas Monjalon @ 2016-10-12 16:06 UTC (permalink / raw)
To: Iremonger, Bernard
Cc: dev, Shah, Rahul R, Lu, Wenzhuo, az5157@att.com,
De Lara Guarch, Pablo
In-Reply-To: <8CEF83825BEC744B83065625E567D7C21A09209C@IRSMSX108.ger.corp.intel.com>
2016-10-12 15:48, Iremonger, Bernard:
> Hi Thomas,
>
> <snip>
>
> > Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for new
> > API's
> >
> > 2016-10-12 15:27, Iremonger, Bernard:
> > > Hi Thomas,
> > >
> > > <snip>
> > >
> > > > Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests for
> > > > new API's
> > > >
> > > > 2016-10-12 16:03, Bernard Iremonger:
> > > > > --- a/app/test-pmd/Makefile
> > > > > +++ b/app/test-pmd/Makefile
> > > > > @@ -58,6 +58,17 @@ SRCS-y += csumonly.c SRCS-y += icmpecho.c
> > > > > SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
> > > > >
> > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
> > > > > +LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > endif
> > > > > +
> > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> > > > > +ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
> > > > > +LDLIBS += -lrte_pmd_ixgbe
> > > > > +endif
> > > > > +endif
> > > >
> > > > Sorry if I miss something, but I thought it was enough to do:
> > > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > >
> > > No unfortunately not, the above line does not work for all scenarios .
> > >
> > > There are 4 scenarios as follows:
> > >
> > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y with
> > CONFIG_RTE_BUILD_SHARED_LIB=n
> > >
> > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y with
> > CONFIG_RTE_BUILD_SHARED_LIB=y
> > >
> > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n with
> > CONFIG_RTE_BUILD_SHARED_LIB=y
> > >
> > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n with
> > CONFIG_RTE_BUILD_SHARED_LIB=n
> > >
> > > I have been doing quite a bit of building today to get it to work in all 4
> > scenarios.
> >
> > I have a doubt about the tests because LDLIBS-y does not exist.
> > There is _LDLIBS-y and LDLIBS.
> > But in the static case, you wrote:
> > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > endif Please could you check?
>
> LDLIBS-y exists in some of the scenarios but not all.
I think I'm something obvious.
Please could you point the line where LDLIBS-y is used?
> Do you want me to check the four scenarios with just the line below.
>
> LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
Let's check the theory first :)
^ permalink raw reply
* Re: [PATCH] net/mlx: align drivers to latest naming convention
From: Bruce Richardson @ 2016-10-12 16:12 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: David Marchand, thomas.monjalon, dev
In-Reply-To: <20161007132427.GI17252@6wind.com>
On Fri, Oct 07, 2016 at 03:24:27PM +0200, Adrien Mazarguil wrote:
> On Fri, Oct 07, 2016 at 03:04:13PM +0200, David Marchand wrote:
> > Fixes: 2f45703c17ac ("drivers: make driver names consistent")
> >
> > Signed-off-by: David Marchand <david.marchand@6wind.com>
> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
>
Applied to dpdk-next-net/rel_16_11
/Bruce
^ permalink raw reply
* Re: [PATCH] net/enic: update enic guide and add warning for invalid conf
From: Bruce Richardson @ 2016-10-12 16:19 UTC (permalink / raw)
To: Mcnamara, John; +Cc: John Daley, dev@dpdk.org, Nelson Escobar
In-Reply-To: <B27915DBBA3421428155699D51E4CFE20262A85C@IRSMSX103.ger.corp.intel.com>
On Mon, Oct 10, 2016 at 03:16:09PM +0100, Mcnamara, John wrote:
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of John Daley
> > Sent: Thursday, September 29, 2016 9:55 PM
> > To: Richardson, Bruce <bruce.richardson@intel.com>
> > Cc: dev@dpdk.org; Nelson Escobar <neescoba@cisco.com>
> > Subject: [dpdk-dev] [PATCH] net/enic: update enic guide and add warning
> > for invalid conf
> >
> > From: Nelson Escobar <neescoba@cisco.com>
> >
> > Update the enic guide to better explain how to setup vNIC parameters on
> > the Cisco VIC since the introduction of rx scatter and print an error
> > message for the case of having 1 RQ configured in the vNIC.
> >
> > Signed-off-by: Nelson Escobar <neescoba@cisco.com>
>
> Hi,
>
> It would be better in the RST documentation to use ```` backticks to
> designate function and variable names as fixed width. Also, the documentation
> convention is to use Rx/Tx. However, these are minor so the patch is okay as
> it is.
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
>
Applied to dpdk-next-net/rel_16_11 as "document how to configure vNIC parameters"
so as to make it clear that this is one logical change, rather than two - which
would be implied by the use of "and" in the title.
/Bruce
^ permalink raw reply
* Re: [PATCH v8 2/2] app/test_pmd: add tests for new API's
From: Iremonger, Bernard @ 2016-10-12 16:21 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev@dpdk.org, Shah, Rahul R, Lu, Wenzhuo, az5157@att.com,
De Lara Guarch, Pablo
In-Reply-To: <4355552.XQIr0B1y70@xps13>
Hi Thomas,
<snip>
> > > > > Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests
> > > > > for new API's
> > > > >
> > > > > 2016-10-12 16:03, Bernard Iremonger:
> > > > > > --- a/app/test-pmd/Makefile
> > > > > > +++ b/app/test-pmd/Makefile
> > > > > > @@ -58,6 +58,17 @@ SRCS-y += csumonly.c SRCS-y += icmpecho.c
> > > > > > SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
> > > > > >
> > > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
> > > > > > +LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > > endif
> > > > > > +
> > > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> > > > > > +ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
> > > > > > +LDLIBS += -lrte_pmd_ixgbe
> > > > > > +endif
> > > > > > +endif
> > > > >
> > > > > Sorry if I miss something, but I thought it was enough to do:
> > > > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > > >
> > > > No unfortunately not, the above line does not work for all scenarios .
> > > >
> > > > There are 4 scenarios as follows:
> > > >
> > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y with
> > > CONFIG_RTE_BUILD_SHARED_LIB=n
> > > >
> > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y with
> > > CONFIG_RTE_BUILD_SHARED_LIB=y
> > > >
> > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n with
> > > CONFIG_RTE_BUILD_SHARED_LIB=y
> > > >
> > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n with
> > > CONFIG_RTE_BUILD_SHARED_LIB=n
> > > >
> > > > I have been doing quite a bit of building today to get it to work
> > > > in all 4
> > > scenarios.
> > >
> > > I have a doubt about the tests because LDLIBS-y does not exist.
> > > There is _LDLIBS-y and LDLIBS.
> > > But in the static case, you wrote:
> > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> endif
> > > Please could you check?
> >
> > LDLIBS-y exists in some of the scenarios but not all.
>
> I think I'm something obvious.
> Please could you point the line where LDLIBS-y is used?
Line 62 of latest Makefile;
LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
LDLIBS-y does not exist when CONFIG_RTE_BUILD_SHARED_LIB=y
> > Do you want me to check the four scenarios with just the line below.
> >
> > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
>
> Let's check the theory first :)
Ok
Regards,
Bernard.
^ permalink raw reply
* Re: [PATCH 4/4] net/enic: extend fdir support for 1300 series adapters
From: Bruce Richardson @ 2016-10-12 16:24 UTC (permalink / raw)
To: John Daley (johndale); +Cc: Ferruh Yigit, dev@dpdk.org
In-Reply-To: <ac590003ef2e42b6a8d7af452da6b88a@XCH-RCD-007.cisco.com>
On Tue, Oct 11, 2016 at 09:25:45AM +0000, John Daley (johndale) wrote:
>
>
> > -----Original Message-----
> > From: Ferruh Yigit [mailto:ferruh.yigit@intel.com]
> > Sent: Tuesday, October 11, 2016 2:22 AM
> > To: John Daley (johndale) <johndale@cisco.com>;
> > bruce.richardson@intel.com
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 4/4] net/enic: extend fdir support for 1300
> > series adapters
> >
> > Hi John,
> >
> > On 9/29/2016 9:56 PM, John Daley wrote:
> > > 1300 series Cisco adapter firmware version 2.0(13) for UCS C-series
> > > servers and 3.1(2) for blade servers supports more filtering
> > > capabilities. The feature can be enabled via Cisco CIMC or USCM with
> > > the 'advanced filters' radio button. When enabled, the these
> > > additional flow director modes are available:
> > > RTE_ETH_FLOW_NONFRAG_IPV4_OTHER
> > > RTE_ETH_FLOW_NONFRAG_IPV4_SCTP
> > > RTE_ETH_FLOW_NONFRAG_IPV6_UDP
> > > RTE_ETH_FLOW_NONFRAG_IPV6_TCP
> > > RTE_ETH_FLOW_NONFRAG_IPV6_SCTP
> > > RTE_ETH_FLOW_NONFRAG_IPV6_OTHER
> > >
> > > Changes:
> > > - Detect and set an 'advanced filters' flag dependent on the adapter
> > > capability.
> > > - Implement RTE_ETH_FILTER_INFO filter op to return the flow types
> > > available dependent on whether advanced filters are enabled.
> > > - Use a function pointer to select how filters are added to the adapter:
> > > copy_fltr_v1() for older firmware/adapters or copy_fltr_v2() for
> > > adapters which support advanced filters.
> > > - Apply fdir global masks to filters when in advanced filter mode.
> > > - Update documentation.
> > >
> > > Signed-off-by: John Daley <johndale@cisco.com>
> > > Reviewed-by: Nelson Escobar <neescoba@cisco.com>
> > > ---
> >
> > <...>
> >
> > >
> > > +void enic_fdir_info_get(struct enic *enic, struct rte_eth_fdir_info
> > > +*info) {
> > > + info->mode = enic->fdir.modes;
> >
> > This cause a icc build error:
> > .../drivers/net/enic/enic_clsf.c(77):
> > error #188: enumerated type mixed with another type
> > info->mode = enic->fdir.modes;
> > ^
> >
> > Just casting to the enum fixes it:
> > + info->mode = (enum rte_fdir_mode)enic->fdir.modes;
> >
> > Since the modification is trivial, if you agree with the change, we can apply it
> > without needing a new version of the patch?
> >
>
> Looks good, thank you and sorry for the trouble.
> -john
>
Series applied to dpdk-next-net/rel_16_11
/Bruce
^ permalink raw reply
* Re: [dpdk-stable] [PATCH v2 1/4] net/ena: improve safety of string handling in ena_config_host_info
From: Ferruh Yigit @ 2016-10-12 16:24 UTC (permalink / raw)
To: John W. Linville, dev; +Cc: dpdk stable
In-Reply-To: <1475170776-10130-2-git-send-email-linville@tuxdriver.com>
On 9/29/2016 6:39 PM, John W. Linville wrote:
> Use sizeof dest rather than sizeof src for limiting copy length,
> and replace strncpy with snprintf to ensure NULL termination.
>
> Coverity issue: 127795
> Fixes: 372c1af5ed8f ("net/ena: add dedicated memory area for extra device info")
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply
* Re: [PATCH v8 2/2] app/test_pmd: add tests for new API's
From: Thomas Monjalon @ 2016-10-12 16:31 UTC (permalink / raw)
To: Iremonger, Bernard
Cc: dev, Shah, Rahul R, Lu, Wenzhuo, az5157@att.com,
De Lara Guarch, Pablo
In-Reply-To: <8CEF83825BEC744B83065625E567D7C21A092162@IRSMSX108.ger.corp.intel.com>
2016-10-12 16:21, Iremonger, Bernard:
> Hi Thomas,
>
> <snip>
> > > > > > Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/test_pmd: add tests
> > > > > > for new API's
> > > > > >
> > > > > > 2016-10-12 16:03, Bernard Iremonger:
> > > > > > > --- a/app/test-pmd/Makefile
> > > > > > > +++ b/app/test-pmd/Makefile
> > > > > > > @@ -58,6 +58,17 @@ SRCS-y += csumonly.c SRCS-y += icmpecho.c
> > > > > > > SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
> > > > > > >
> > > > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
> > > > > > > +LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > > > endif
> > > > > > > +
> > > > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> > > > > > > +ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
> > > > > > > +LDLIBS += -lrte_pmd_ixgbe
> > > > > > > +endif
> > > > > > > +endif
> > > > > >
> > > > > > Sorry if I miss something, but I thought it was enough to do:
> > > > > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > > > >
> > > > > No unfortunately not, the above line does not work for all scenarios .
> > > > >
> > > > > There are 4 scenarios as follows:
> > > > >
> > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y with
> > > > CONFIG_RTE_BUILD_SHARED_LIB=n
> > > > >
> > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y with
> > > > CONFIG_RTE_BUILD_SHARED_LIB=y
> > > > >
> > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n with
> > > > CONFIG_RTE_BUILD_SHARED_LIB=y
> > > > >
> > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n with
> > > > CONFIG_RTE_BUILD_SHARED_LIB=n
> > > > >
> > > > > I have been doing quite a bit of building today to get it to work
> > > > > in all 4
> > > > scenarios.
> > > >
> > > > I have a doubt about the tests because LDLIBS-y does not exist.
> > > > There is _LDLIBS-y and LDLIBS.
> > > > But in the static case, you wrote:
> > > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > endif
> > > > Please could you check?
> > >
> > > LDLIBS-y exists in some of the scenarios but not all.
> >
> > I think I'm something obvious.
> > Please could you point the line where LDLIBS-y is used?
>
> Line 62 of latest Makefile;
> LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
No, I mean where do you find LDLIBS- (without underscore) before your patch?
git grep '\<LDLIBS-' returns nothing.
^ permalink raw reply
* Re: [PATCH 1/2] bnx2x: fix maximum PF queues
From: Bruce Richardson @ 2016-10-12 16:33 UTC (permalink / raw)
To: Rasesh Mody; +Cc: dev, Dept-EngDPDKDev
In-Reply-To: <1475732197-668-1-git-send-email-rasesh.mody@qlogic.com>
On Wed, Oct 05, 2016 at 10:36:36PM -0700, Rasesh Mody wrote:
> Fix the max number of PF rx/tx queues. Set the value based
> on BNX2X_MAX_RSS_COUNT() rather than hard coding it to 128.
>
> Fixes: 540a211 ("bnx2x: driver core")
>
> Signed-off-by: Rasesh Mody <rasesh.mody@qlogic.com>
> ---
Series applied to dpdk-next-net/rel_16_11
/Bruce
^ permalink raw reply
* Re: [PATCH v6 0/8] Misc enhancements in testpmd
From: Thomas Monjalon @ 2016-10-12 16:41 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev, pablo.de.lara.guarch
In-Reply-To: <1476286790-26271-1-git-send-email-olivier.matz@6wind.com>
2016-10-12 17:39, Olivier Matz:
> This patchset introduces several enhancements or minor fixes
> in testpmd. It is targetted for v16.11, and applies on top of
> software ptype v2 patchset [1].
>
> These patches are useful to validate the virtio offload
> patchset [2] (to be rebased).
Applied, thanks
^ permalink raw reply
* Re: [PATCH v8 2/2] app/test_pmd: add tests for new API's
From: Iremonger, Bernard @ 2016-10-12 16:50 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev@dpdk.org, Shah, Rahul R, Lu, Wenzhuo, az5157@att.com,
De Lara Guarch, Pablo
In-Reply-To: <1477008.RUhcNVuyge@xps13>
Hi Thomas,
<snip>
> > > > > > > Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/test_pmd: add
> > > > > > > tests for new API's
> > > > > > >
> > > > > > > 2016-10-12 16:03, Bernard Iremonger:
> > > > > > > > --- a/app/test-pmd/Makefile
> > > > > > > > +++ b/app/test-pmd/Makefile
> > > > > > > > @@ -58,6 +58,17 @@ SRCS-y += csumonly.c SRCS-y +=
> > > > > > > > icmpecho.c
> > > > > > > > SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
> > > > > > > >
> > > > > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
> > > > > > > > +LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -
> lrte_pmd_ixgbe
> > > > > endif
> > > > > > > > +
> > > > > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> > > > > > > > +ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
> > > > > > > > +LDLIBS += -lrte_pmd_ixgbe endif endif
> > > > > > >
> > > > > > > Sorry if I miss something, but I thought it was enough to do:
> > > > > > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > > > > >
> > > > > > No unfortunately not, the above line does not work for all scenarios
> .
> > > > > >
> > > > > > There are 4 scenarios as follows:
> > > > > >
> > > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y with
> > > > > CONFIG_RTE_BUILD_SHARED_LIB=n
> > > > > >
> > > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y with
> > > > > CONFIG_RTE_BUILD_SHARED_LIB=y
> > > > > >
> > > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n with
> > > > > CONFIG_RTE_BUILD_SHARED_LIB=y
> > > > > >
> > > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n with
> > > > > CONFIG_RTE_BUILD_SHARED_LIB=n
> > > > > >
> > > > > > I have been doing quite a bit of building today to get it to
> > > > > > work in all 4
> > > > > scenarios.
> > > > >
> > > > > I have a doubt about the tests because LDLIBS-y does not exist.
> > > > > There is _LDLIBS-y and LDLIBS.
> > > > > But in the static case, you wrote:
> > > > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> > > endif
> > > > > Please could you check?
> > > >
> > > > LDLIBS-y exists in some of the scenarios but not all.
> > >
> > > I think I'm something obvious.
> > > Please could you point the line where LDLIBS-y is used?
> >
> > Line 62 of latest Makefile;
> > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
>
> No, I mean where do you find LDLIBS- (without underscore) before your
> patch?
> git grep '\<LDLIBS-' returns nothing.
Before my patch LDLIBS was not used in the testpmd Makefile.
The linking was done in rte.app.mk, this uses LDLIBS and _LDLIBS-y.
I don't see LDLIBS-y either.
Regards,
Bernard.
^ permalink raw reply
* Re: [PATCH] ethdev: Support VFs on the different PCI domains
From: Kamil Rytarowski @ 2016-10-12 17:07 UTC (permalink / raw)
To: David Marchand
Cc: dev@dpdk.org, maciej.czekaj, zyta.szpak, slawomir.rosek, rad,
Jerin Jacob, Ferruh Yigit, Kamil Rytarowski
In-Reply-To: <CALwxeUukaBxhsDfhM8hPnYOmc2OJN6BX6vy5MCt5HDcMiWTzdw@mail.gmail.com>
W dniu 11.10.2016 o 18:52, David Marchand pisze:
> On Tue, Oct 11, 2016 at 3:49 PM, Kamil Rytarowski
> <krytarowski@caviumnetworks.com> wrote:
>> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
>> index 382c959..01d5fb0 100644
>> --- a/lib/librte_ether/rte_ethdev.c
>> +++ b/lib/librte_ether/rte_ethdev.c
>> @@ -225,7 +225,7 @@ rte_eth_dev_create_unique_device_name(char *name, size_t size,
>> {
>> int ret;
>>
>> - ret = snprintf(name, size, "%d:%d.%d",
>> + ret = snprintf(name, size, "%d:%d:%d.%d", pci_dev->addr.domain,
>> pci_dev->addr.bus, pci_dev->addr.devid,
>> pci_dev->addr.function);
>> if (ret < 0)
> This patch is obsolete since this part has been moved to eal.
>
> Can you test with current master branch if there is still an issue ?
> Thanks.
>
>
I've tested DPDK master without this PCI domain patch and everything
seems to work.
Thank you.
^ permalink raw reply
* Re: [PATCH v8 2/2] app/test_pmd: add tests for new API's
From: Iremonger, Bernard @ 2016-10-12 17:20 UTC (permalink / raw)
To: Iremonger, Bernard, Thomas Monjalon
Cc: dev@dpdk.org, Shah, Rahul R, Lu, Wenzhuo, az5157@att.com,
De Lara Guarch, Pablo
In-Reply-To: <8CEF83825BEC744B83065625E567D7C21A09219A@IRSMSX108.ger.corp.intel.com>
Hi Thomas,
<snip>
> > > > > > > > Subject: Re: [dpdk-dev] [PATCH v8 2/2] app/test_pmd: add
> > > > > > > > tests for new API's
> > > > > > > >
> > > > > > > > 2016-10-12 16:03, Bernard Iremonger:
> > > > > > > > > --- a/app/test-pmd/Makefile
> > > > > > > > > +++ b/app/test-pmd/Makefile
> > > > > > > > > @@ -58,6 +58,17 @@ SRCS-y += csumonly.c SRCS-y +=
> > > > > > > > > icmpecho.c
> > > > > > > > > SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
> > > > > > > > >
> > > > > > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
> > > > > > > > > +LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -
> > lrte_pmd_ixgbe
> > > > > > endif
> > > > > > > > > +
> > > > > > > > > +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> > > > > > > > > +ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
> > > > > > > > > +LDLIBS += -lrte_pmd_ixgbe endif endif
> > > > > > > >
> > > > > > > > Sorry if I miss something, but I thought it was enough to do:
> > > > > > > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -
> lrte_pmd_ixgbe
> > > > > > >
> > > > > > > No unfortunately not, the above line does not work for all
> > > > > > > scenarios
> > .
> > > > > > >
> > > > > > > There are 4 scenarios as follows:
> > > > > > >
> > > > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y with
> > > > > > CONFIG_RTE_BUILD_SHARED_LIB=n
> > > > > > >
> > > > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=y with
> > > > > > CONFIG_RTE_BUILD_SHARED_LIB=y
> > > > > > >
> > > > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n with
> > > > > > CONFIG_RTE_BUILD_SHARED_LIB=y
> > > > > > >
> > > > > > > CONFIG_RTE_LIBRTE_IXGBE_PMD=n with
> > > > > > CONFIG_RTE_BUILD_SHARED_LIB=n
> > > > > > >
> > > > > > > I have been doing quite a bit of building today to get it to
> > > > > > > work in all 4
> > > > > > scenarios.
> > > > > >
> > > > > > I have a doubt about the tests because LDLIBS-y does not exist.
> > > > > > There is _LDLIBS-y and LDLIBS.
> > > > > > But in the static case, you wrote:
> > > > > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -
> lrte_pmd_ixgbe
> > > > endif
> > > > > > Please could you check?
> > > > >
> > > > > LDLIBS-y exists in some of the scenarios but not all.
> > > >
> > > > I think I'm something obvious.
> > > > Please could you point the line where LDLIBS-y is used?
> > >
> > > Line 62 of latest Makefile;
> > > LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> >
> > No, I mean where do you find LDLIBS- (without underscore) before your
> > patch?
> > git grep '\<LDLIBS-' returns nothing.
>
>
> Before my patch LDLIBS was not used in the testpmd Makefile.
>
> The linking was done in rte.app.mk, this uses LDLIBS and _LDLIBS-y.
> I don't see LDLIBS-y either.
>
> Regards,
>
> Bernard.
>
_LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
Works in the 4 scenarios, I will send a v9
Regards,
Bernard.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox