DPDK usage discussions
 help / color / mirror / Atom feed
* [dpdk-users] librte_cmdline usage
@ 2018-01-22 10:15 longtb5
  2018-01-22 13:38 ` Olivier Matz
  0 siblings, 1 reply; 3+ messages in thread
From: longtb5 @ 2018-01-22 10:15 UTC (permalink / raw)
  To: users; +Cc: olivier.matz

Hi all,

I'm writing an application where there already exists a cmdline. Users can
issue commands by typing from stdin. I want to support another user
interface where commands are read from sources other than stdin, saved into
a string buffer, then executed using the already existed cmd_parse_ctx_t.

So far I have implemented this functionality using the cmdline_interact()
API like so (pseudo code).

/* Initialization */
/* cmds_ctx is the existing command context
 * that I wish to reuse
 */
new_cl = cmdline_new(cmds_ctx, "", cmdbuf_fd, 1); 

/* Polling */
for ( ; ; ) {
	snprintf(cmdbuf, cmdlen + 2, "%s\n", raw_string);
	lseek(cmdbuf_fd, 0 , SEEK_SET);
	cmdline_interact(new_cl);
}

There are a couple of questions:

1. Using cmdline_interact() seems to be quite expensive. How can I reduce
this cost. Is there a leaner/more elegant way to implement this using DPDK
API or do I have to write my own code/change the lib?

2. How can I disable the behavior where every interaction is written to
stdout, i.e., to have no output what so ever. Again this is to improve
performance since writing to stdout is costly.

Thanks and best regards,
--BL

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-users] librte_cmdline usage
  2018-01-22 10:15 [dpdk-users] librte_cmdline usage longtb5
@ 2018-01-22 13:38 ` Olivier Matz
  2018-01-23  2:03   ` longtb5
  0 siblings, 1 reply; 3+ messages in thread
From: Olivier Matz @ 2018-01-22 13:38 UTC (permalink / raw)
  To: longtb5; +Cc: users

Hi,

On Mon, Jan 22, 2018 at 05:15:22PM +0700, longtb5@viettel.com.vn wrote:
> Hi all,
> 
> I'm writing an application where there already exists a cmdline. Users can
> issue commands by typing from stdin. I want to support another user
> interface where commands are read from sources other than stdin, saved into
> a string buffer, then executed using the already existed cmd_parse_ctx_t.
> 
> So far I have implemented this functionality using the cmdline_interact()
> API like so (pseudo code).
> 
> /* Initialization */
> /* cmds_ctx is the existing command context
>  * that I wish to reuse
>  */
> new_cl = cmdline_new(cmds_ctx, "", cmdbuf_fd, 1); 
> 
> /* Polling */
> for ( ; ; ) {
> 	snprintf(cmdbuf, cmdlen + 2, "%s\n", raw_string);
> 	lseek(cmdbuf_fd, 0 , SEEK_SET);
> 	cmdline_interact(new_cl);
> }
> 
> There are a couple of questions:
> 
> 1. Using cmdline_interact() seems to be quite expensive. How can I reduce
> this cost. Is there a leaner/more elegant way to implement this using DPDK
> API or do I have to write my own code/change the lib?
> 
> 2. How can I disable the behavior where every interaction is written to
> stdout, i.e., to have no output what so ever. Again this is to improve
> performance since writing to stdout is costly.

If my understanding is correct, you want to use the command line parser
without the i/o (readline part). For this, you can directly call
cmdline_parse(cl, buffer). It will parse the given buffer and invokes
the callback.

There will be no output on stdout done by the cmdline library. But it
does not prevent a command callback to call printf() or similar.

Olivier

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-users] librte_cmdline usage
  2018-01-22 13:38 ` Olivier Matz
@ 2018-01-23  2:03   ` longtb5
  0 siblings, 0 replies; 3+ messages in thread
From: longtb5 @ 2018-01-23  2:03 UTC (permalink / raw)
  To: users

Hi Oliver,

Yes that was exactly what I needed. Thanks.

--BL

> -----Original Message-----
> From: olivier.matz@6wind.com [mailto:olivier.matz@6wind.com]
> Sent: Monday, January 22, 2018 8:38 PM
> To: longtb5@viettel.com.vn
> Cc: users@dpdk.org
> Subject: Re: librte_cmdline usage
> 
> Hi,
> 
> On Mon, Jan 22, 2018 at 05:15:22PM +0700, longtb5@viettel.com.vn wrote:
> > Hi all,
> >
> > I'm writing an application where there already exists a cmdline. Users
> > can issue commands by typing from stdin. I want to support another
> > user interface where commands are read from sources other than stdin,
> > saved into a string buffer, then executed using the already existed
> cmd_parse_ctx_t.
> >
> > So far I have implemented this functionality using the
> > cmdline_interact() API like so (pseudo code).
> >
> > /* Initialization */
> > /* cmds_ctx is the existing command context
> >  * that I wish to reuse
> >  */
> > new_cl = cmdline_new(cmds_ctx, "", cmdbuf_fd, 1);
> >
> > /* Polling */
> > for ( ; ; ) {
> > 	snprintf(cmdbuf, cmdlen + 2, "%s\n", raw_string);
> > 	lseek(cmdbuf_fd, 0 , SEEK_SET);
> > 	cmdline_interact(new_cl);
> > }
> >
> > There are a couple of questions:
> >
> > 1. Using cmdline_interact() seems to be quite expensive. How can I
> > reduce this cost. Is there a leaner/more elegant way to implement this
> > using DPDK API or do I have to write my own code/change the lib?
> >
> > 2. How can I disable the behavior where every interaction is written
> > to stdout, i.e., to have no output what so ever. Again this is to
> > improve performance since writing to stdout is costly.
> 
> If my understanding is correct, you want to use the command line parser
> without the i/o (readline part). For this, you can directly call
cmdline_parse(cl,
> buffer). It will parse the given buffer and invokes the callback.
> 
> There will be no output on stdout done by the cmdline library. But it does
not
> prevent a command callback to call printf() or similar.
> 
> Olivier

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-01-23  2:03 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-22 10:15 [dpdk-users] librte_cmdline usage longtb5
2018-01-22 13:38 ` Olivier Matz
2018-01-23  2:03   ` longtb5

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).