[dpdk-dev,2/6] testpmd: configurable tx_first burst number
Commit Message
This patch enables configurable tx_first burst number.
Use "start tx_first (burst_num)" to specify how many bursts of packets to
be sent before forwarding start, or "start tx_first" like before for the
default 1 burst send.
Signed-off-by: Zhihong Wang <zhihong.wang@intel.com>
---
app/test-pmd/cmdline.c | 41 +++++++++++++++++++++++++++++++++++++++++
app/test-pmd/testpmd.c | 7 +++++--
2 files changed, 46 insertions(+), 2 deletions(-)
Comments
2016-05-05 18:46, Zhihong Wang:
> This patch enables configurable tx_first burst number.
>
> Use "start tx_first (burst_num)" to specify how many bursts of packets to
> be sent before forwarding start, or "start tx_first" like before for the
> default 1 burst send.
The idea here is to fill the loopback latency gap with bursts.
Would it be possible to make it automatic by detecting the first
received packets to stop Tx generator?
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, May 25, 2016 5:35 PM
> To: Wang, Zhihong <zhihong.wang@intel.com>
> Cc: dev@dpdk.org; Ananyev, Konstantin <konstantin.ananyev@intel.com>;
> Richardson, Bruce <bruce.richardson@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>
> Subject: Re: [PATCH 2/6] testpmd: configurable tx_first burst number
>
> 2016-05-05 18:46, Zhihong Wang:
> > This patch enables configurable tx_first burst number.
> >
> > Use "start tx_first (burst_num)" to specify how many bursts of packets to
> > be sent before forwarding start, or "start tx_first" like before for the
> > default 1 burst send.
>
> The idea here is to fill the loopback latency gap with bursts.
> Would it be possible to make it automatic by detecting the first
> received packets to stop Tx generator?
The idea is great! The implementation might not be graceful though
-- current tx_first mode first calls txonly engine before calling the
actual engine, say iofwd, so iofwd is not established before tx_first
is done, therefore no detection.
It's possible to do this, but we need to implement another forward
engine like "io_retry_fill_first" alone, it complicates testpmd just for
this loop back test.
Looks to me it's better to use combination of existing fwd engines to
do this, it's also more flexible with burst number parameters.
2016-05-26 02:53, Wang, Zhihong:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 2016-05-05 18:46, Zhihong Wang:
> > > This patch enables configurable tx_first burst number.
> > >
> > > Use "start tx_first (burst_num)" to specify how many bursts of packets to
> > > be sent before forwarding start, or "start tx_first" like before for the
> > > default 1 burst send.
> >
> > The idea here is to fill the loopback latency gap with bursts.
> > Would it be possible to make it automatic by detecting the first
> > received packets to stop Tx generator?
>
> The idea is great! The implementation might not be graceful though
> -- current tx_first mode first calls txonly engine before calling the
> actual engine, say iofwd, so iofwd is not established before tx_first
> is done, therefore no detection.
And what about rewriting tx_first?
No strong opinion. I let you and Pablo decide.
> It's possible to do this, but we need to implement another forward
> engine like "io_retry_fill_first" alone, it complicates testpmd just for
> this loop back test.
>
> Looks to me it's better to use combination of existing fwd engines to
> do this, it's also more flexible with burst number parameters.
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Thursday, May 26, 2016 2:32 PM
> To: Wang, Zhihong <zhihong.wang@intel.com>
> Cc: dev@dpdk.org; Ananyev, Konstantin <konstantin.ananyev@intel.com>;
> Richardson, Bruce <bruce.richardson@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>
> Subject: Re: [PATCH 2/6] testpmd: configurable tx_first burst number
>
> 2016-05-26 02:53, Wang, Zhihong:
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > 2016-05-05 18:46, Zhihong Wang:
> > > > This patch enables configurable tx_first burst number.
> > > >
> > > > Use "start tx_first (burst_num)" to specify how many bursts of packets to
> > > > be sent before forwarding start, or "start tx_first" like before for the
> > > > default 1 burst send.
> > >
> > > The idea here is to fill the loopback latency gap with bursts.
> > > Would it be possible to make it automatic by detecting the first
> > > received packets to stop Tx generator?
> >
> > The idea is great! The implementation might not be graceful though
> > -- current tx_first mode first calls txonly engine before calling the
> > actual engine, say iofwd, so iofwd is not established before tx_first
> > is done, therefore no detection.
>
> And what about rewriting tx_first?
> No strong opinion. I let you and Pablo decide.
>
I think the current way is better in terms of simplicity and flexibility.
Also this "fill the ring" criteria doesn't fit other test scenarios, it's
just for this loop back test, but tx_first is for all scenarios.
> > It's possible to do this, but we need to implement another forward
> > engine like "io_retry_fill_first" alone, it complicates testpmd just for
> > this loop back test.
> >
> > Looks to me it's better to use combination of existing fwd engines to
> > do this, it's also more flexible with burst number parameters.
@@ -5240,6 +5240,46 @@ cmdline_parse_inst_t cmd_start_tx_first = {
},
};
+/* *** START FORWARDING WITH N TX BURST FIRST *** */
+struct cmd_start_tx_first_n_result {
+ cmdline_fixed_string_t start;
+ cmdline_fixed_string_t tx_first;
+ uint32_t tx_num;
+};
+
+static void
+cmd_start_tx_first_n_parsed(__attribute__((unused)) void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_start_tx_first_n_result *res = parsed_result;
+
+ start_packet_forwarding(res->tx_num);
+}
+
+cmdline_parse_token_string_t cmd_start_tx_first_n_start =
+ TOKEN_STRING_INITIALIZER(struct cmd_start_tx_first_n_result,
+ start, "start");
+cmdline_parse_token_string_t cmd_start_tx_first_n_tx_first =
+ TOKEN_STRING_INITIALIZER(struct cmd_start_tx_first_n_result,
+ tx_first, "tx_first");
+cmdline_parse_token_num_t cmd_start_tx_first_n_tx_num =
+ TOKEN_NUM_INITIALIZER(struct cmd_start_tx_first_n_result,
+ tx_num, UINT32);
+
+cmdline_parse_inst_t cmd_start_tx_first_n = {
+ .f = cmd_start_tx_first_n_parsed,
+ .data = NULL,
+ .help_str = "start packet forwarding, after sending <num> "
+ "bursts of packets",
+ .tokens = {
+ (void *)&cmd_start_tx_first_n_start,
+ (void *)&cmd_start_tx_first_n_tx_first,
+ (void *)&cmd_start_tx_first_n_tx_num,
+ NULL,
+ },
+};
+
/* *** SET LINK UP *** */
struct cmd_set_link_up_result {
cmdline_fixed_string_t set;
@@ -10399,6 +10439,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)&cmd_showcfg,
(cmdline_parse_inst_t *)&cmd_start,
(cmdline_parse_inst_t *)&cmd_start_tx_first,
+ (cmdline_parse_inst_t *)&cmd_start_tx_first_n,
(cmdline_parse_inst_t *)&cmd_set_link_up,
(cmdline_parse_inst_t *)&cmd_set_link_down,
(cmdline_parse_inst_t *)&cmd_reset,
@@ -1037,8 +1037,11 @@ start_packet_forwarding(int with_tx_first)
for (i = 0; i < cur_fwd_config.nb_fwd_ports; i++)
(*port_fwd_begin)(fwd_ports_ids[i]);
}
- launch_packet_forwarding(run_one_txonly_burst_on_core);
- rte_eal_mp_wait_lcore();
+ while (with_tx_first--) {
+ launch_packet_forwarding(
+ run_one_txonly_burst_on_core);
+ rte_eal_mp_wait_lcore();
+ }
port_fwd_end = tx_only_engine.port_fwd_end;
if (port_fwd_end != NULL) {
for (i = 0; i < cur_fwd_config.nb_fwd_ports; i++)