[dpdk-dev,v2] app/testpmd: make txonly mode generate multiple flows
Checks
Commit Message
Testpmd can generate multiple flows without taking much cost and this could
be a simple traffic generator for developer's quick tests. IP destination
address is varied.
Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
---
v2:
* Add detailed explanation in a comment.
app/test-pmd/txonly.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
Comments
Hi,
> -----Original Message-----
> From: Yongseok Koh [mailto:yskoh@mellanox.com]
> Sent: Thursday, January 18, 2018 2:19 AM
> To: Lu, Wenzhuo <wenzhuo.lu@intel.com>; Wu, Jingjing
> <jingjing.wu@intel.com>
> Cc: dev@dpdk.org; Yongseok Koh <yskoh@mellanox.com>
> Subject: [PATCH v2] app/testpmd: make txonly mode generate multiple flows
>
> Testpmd can generate multiple flows without taking much cost and this
> could be a simple traffic generator for developer's quick tests. IP destination
> address is varied.
>
> Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
Hi,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yongseok Koh
> Sent: Wednesday, January 17, 2018 6:19 PM
> To: Lu, Wenzhuo <wenzhuo.lu@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>
> Cc: dev@dpdk.org; Yongseok Koh <yskoh@mellanox.com>
> Subject: [dpdk-dev] [PATCH v2] app/testpmd: make txonly mode generate multiple flows
>
> Testpmd can generate multiple flows without taking much cost and this could
> be a simple traffic generator for developer's quick tests. IP destination
> address is varied.
Correct me if I am wrong - but that the change of existing behavior.
Without any announcement and without ability to the user to keep
current one (command-line option, new CLI command, etc.).
What if there are people who rely on existing behavior
(some test scripts or so)?
Konstantin
>
> Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
> ---
>
> v2:
> * Add detailed explanation in a comment.
>
> app/test-pmd/txonly.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/app/test-pmd/txonly.c b/app/test-pmd/txonly.c
> index 1f08b6ed3..253cf2385 100644
> --- a/app/test-pmd/txonly.c
> +++ b/app/test-pmd/txonly.c
> @@ -44,7 +44,7 @@
> #define UDP_DST_PORT 1024
>
> #define IP_SRC_ADDR ((192U << 24) | (168 << 16) | (0 << 8) | 1)
> -#define IP_DST_ADDR ((192U << 24) | (168 << 16) | (0 << 8) | 2)
> +#define IP_DST_ADDR ((192U << 24) | (168 << 16))
>
> #define IP_DEFTTL 64 /* from RFC 1340. */
> #define IP_VERSION 0x40
> @@ -52,6 +52,7 @@
> #define IP_VHL_DEF (IP_VERSION | IP_HDRLEN)
>
> static struct ipv4_hdr pkt_ip_hdr; /**< IP header of transmitted packets. */
> +static __thread uint8_t ip_var; /**< IP address variation */
> static struct udp_hdr pkt_udp_hdr; /**< UDP header of transmitted packets. */
>
> static void
> @@ -159,6 +160,7 @@ pkt_burst_transmit(struct fwd_stream *fs)
> struct rte_mbuf *pkt_seg;
> struct rte_mempool *mbp;
> struct ether_hdr eth_hdr;
> + struct ipv4_hdr *ip_hdr;
> uint16_t nb_tx;
> uint16_t nb_pkt;
> uint16_t vlan_tci, vlan_tci_outer;
> @@ -237,6 +239,17 @@ pkt_burst_transmit(struct fwd_stream *fs)
> copy_buf_to_pkt(ð_hdr, sizeof(eth_hdr), pkt, 0);
> copy_buf_to_pkt(&pkt_ip_hdr, sizeof(pkt_ip_hdr), pkt,
> sizeof(struct ether_hdr));
> + ip_hdr = rte_pktmbuf_mtod_offset(pkt, struct ipv4_hdr *,
> + sizeof(struct ether_hdr));
> + /*
> + * Generate multiple flows by varying IP dest addr. This enables
> + * packets are well distributed by RSS in receiver side if any
> + * and txonly mode can be a decent packet generator for
> + * developer's quick performance regression test.
> + */
> + ip_hdr->dst_addr =
> + rte_cpu_to_be_32(IP_DST_ADDR | (ip_var++ << 8) |
> + (rte_lcore_id() + 1));
> copy_buf_to_pkt(&pkt_udp_hdr, sizeof(pkt_udp_hdr), pkt,
> sizeof(struct ether_hdr) +
> sizeof(struct ipv4_hdr));
> --
> 2.11.0
-----Original Message-----
> Date: Wed, 17 Jan 2018 10:18:46 -0800
> From: Yongseok Koh <yskoh@mellanox.com>
> To: wenzhuo.lu@intel.com, jingjing.wu@intel.com
> CC: dev@dpdk.org, Yongseok Koh <yskoh@mellanox.com>
> Subject: [dpdk-dev] [PATCH v2] app/testpmd: make txonly mode generate
> multiple flows
> X-Mailer: git-send-email 2.11.0
>
> Testpmd can generate multiple flows without taking much cost and this could
> be a simple traffic generator for developer's quick tests. IP destination
> address is varied.
Useful feature.
>
> Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
> ---
>
> v2:
> * Add detailed explanation in a comment.
>
> app/test-pmd/txonly.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/app/test-pmd/txonly.c b/app/test-pmd/txonly.c
> index 1f08b6ed3..253cf2385 100644
> --- a/app/test-pmd/txonly.c
> +++ b/app/test-pmd/txonly.c
> @@ -44,7 +44,7 @@
> #define UDP_DST_PORT 1024
>
> #define IP_SRC_ADDR ((192U << 24) | (168 << 16) | (0 << 8) | 1)
> -#define IP_DST_ADDR ((192U << 24) | (168 << 16) | (0 << 8) | 2)
> +#define IP_DST_ADDR ((192U << 24) | (168 << 16))
>
> #define IP_DEFTTL 64 /* from RFC 1340. */
> #define IP_VERSION 0x40
> @@ -52,6 +52,7 @@
> #define IP_VHL_DEF (IP_VERSION | IP_HDRLEN)
>
> static struct ipv4_hdr pkt_ip_hdr; /**< IP header of transmitted packets. */
> +static __thread uint8_t ip_var; /**< IP address variation */
Use RTE_DECLARE_PER_LCORE instead of __thread
> On Jan 18, 2018, at 4:21 AM, Ananyev, Konstantin <konstantin.ananyev@intel.com> wrote:
>
> Hi,
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yongseok Koh
>> Sent: Wednesday, January 17, 2018 6:19 PM
>> To: Lu, Wenzhuo <wenzhuo.lu@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>
>> Cc: dev@dpdk.org; Yongseok Koh <yskoh@mellanox.com>
>> Subject: [dpdk-dev] [PATCH v2] app/testpmd: make txonly mode generate multiple flows
>>
>> Testpmd can generate multiple flows without taking much cost and this could
>> be a simple traffic generator for developer's quick tests. IP destination
>> address is varied.
>
> Correct me if I am wrong - but that the change of existing behavior.
> Without any announcement and without ability to the user to keep
> current one (command-line option, new CLI command, etc.).
> What if there are people who rely on existing behavior
> (some test scripts or so)?
> Konstantin
Good point. But I think it is unlikely. Currently, it generates single fat flow
and if someone uses it for testing, then Rx side likely uses single core. Even
if it gets to generate multiple flows, it would be same to such a case.
However, it is my speculation. If you disagree anyway, I'll stash it for 18.05
and add a new knob to enable it. I'm okay with that because it is just for
convenience, not an urgent issue.
Thanks,
Yongseok
> -----Original Message-----
> From: Yongseok Koh [mailto:yskoh@mellanox.com]
> Sent: Friday, January 19, 2018 7:10 AM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: Lu, Wenzhuo <wenzhuo.lu@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>; dev@dpdk.org; Jerin Jacob
> <jerin.jacob@caviumnetworks.com>
> Subject: Re: [dpdk-dev] [PATCH v2] app/testpmd: make txonly mode generate multiple flows
>
>
> > On Jan 18, 2018, at 4:21 AM, Ananyev, Konstantin <konstantin.ananyev@intel.com> wrote:
> >
> > Hi,
> >
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yongseok Koh
> >> Sent: Wednesday, January 17, 2018 6:19 PM
> >> To: Lu, Wenzhuo <wenzhuo.lu@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>
> >> Cc: dev@dpdk.org; Yongseok Koh <yskoh@mellanox.com>
> >> Subject: [dpdk-dev] [PATCH v2] app/testpmd: make txonly mode generate multiple flows
> >>
> >> Testpmd can generate multiple flows without taking much cost and this could
> >> be a simple traffic generator for developer's quick tests. IP destination
> >> address is varied.
> >
> > Correct me if I am wrong - but that the change of existing behavior.
> > Without any announcement and without ability to the user to keep
> > current one (command-line option, new CLI command, etc.).
> > What if there are people who rely on existing behavior
> > (some test scripts or so)?
> > Konstantin
>
> Good point. But I think it is unlikely. Currently, it generates single fat flow
> and if someone uses it for testing, then Rx side likely uses single core. Even
> if it gets to generate multiple flows, it would be same to such a case.
>
> However, it is my speculation. If you disagree anyway, I'll stash it for 18.05
> and add a new knob to enable it. I'm okay with that because it is just for
> convenience, not an urgent issue.
>
Yes, I think some sort of announcement would be good.
Another alternative - add for user an ability to choose - new CLI command or so.
Konstantin
@@ -44,7 +44,7 @@
#define UDP_DST_PORT 1024
#define IP_SRC_ADDR ((192U << 24) | (168 << 16) | (0 << 8) | 1)
-#define IP_DST_ADDR ((192U << 24) | (168 << 16) | (0 << 8) | 2)
+#define IP_DST_ADDR ((192U << 24) | (168 << 16))
#define IP_DEFTTL 64 /* from RFC 1340. */
#define IP_VERSION 0x40
@@ -52,6 +52,7 @@
#define IP_VHL_DEF (IP_VERSION | IP_HDRLEN)
static struct ipv4_hdr pkt_ip_hdr; /**< IP header of transmitted packets. */
+static __thread uint8_t ip_var; /**< IP address variation */
static struct udp_hdr pkt_udp_hdr; /**< UDP header of transmitted packets. */
static void
@@ -159,6 +160,7 @@ pkt_burst_transmit(struct fwd_stream *fs)
struct rte_mbuf *pkt_seg;
struct rte_mempool *mbp;
struct ether_hdr eth_hdr;
+ struct ipv4_hdr *ip_hdr;
uint16_t nb_tx;
uint16_t nb_pkt;
uint16_t vlan_tci, vlan_tci_outer;
@@ -237,6 +239,17 @@ pkt_burst_transmit(struct fwd_stream *fs)
copy_buf_to_pkt(ð_hdr, sizeof(eth_hdr), pkt, 0);
copy_buf_to_pkt(&pkt_ip_hdr, sizeof(pkt_ip_hdr), pkt,
sizeof(struct ether_hdr));
+ ip_hdr = rte_pktmbuf_mtod_offset(pkt, struct ipv4_hdr *,
+ sizeof(struct ether_hdr));
+ /*
+ * Generate multiple flows by varying IP dest addr. This enables
+ * packets are well distributed by RSS in receiver side if any
+ * and txonly mode can be a decent packet generator for
+ * developer's quick performance regression test.
+ */
+ ip_hdr->dst_addr =
+ rte_cpu_to_be_32(IP_DST_ADDR | (ip_var++ << 8) |
+ (rte_lcore_id() + 1));
copy_buf_to_pkt(&pkt_udp_hdr, sizeof(pkt_udp_hdr), pkt,
sizeof(struct ether_hdr) +
sizeof(struct ipv4_hdr));