DPDK patches and discussions
 help / color / mirror / Atom feed
From: Matthew Hall <mhall@mhcomputing.net>
To: dev@dpdk.org
Subject: [dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging
Date: Tue, 19 Jan 2016 22:32:39 -0800	[thread overview]
Message-ID: <569F2A07.9000606@mhcomputing.net> (raw)

Hello,

Since the pktgen code is reindented I am finding time to read through it 
and experiment and see if I can get it working.

I have issues with the init process of pktgen. It is difficult to debug 
it because the init code does a lot of very scary stuff to the terminal 
control / TTY device at inconvenient times in an inconvenient order, and 
in the process damages the debug output and damages the screen of your 
GDB without doing weird things to run GDB on a different TTY.

Of course I am willing to contribute patches and not just complain, but 
first I need some help to follow what is going on.

Here is the problematic call-flow with some explanation what went wrong 
trying it on some community machines outside of its original environment:

1) it calls printf("\n%s %s\n", wr_copyright_msg(), wr_powered_by()); 
which dumps tons of weird boilerplate of licenses, copyrights, code 
creator, etc.

It is open source and everybody that matters already knows who coded it, 
so is this stuff really that important? This gets in the way when you 
are trying to work on it and I just have to comment it out.

2) it calls wr_scrn_setw and tinkers with the windows size very early in 
the init which can make your terminal weird

3) it calls rte_eal_init which produces a lot of nice debug output, 
which is fine

4) it calls pktgen_init_screen, which calls wr_scrn_init, which calls 
wr_scrn_erase which destroys the valuable debug output just created in 
(c) which is a bad thing

5) it calls wr_print_copyright and dumps more boilerplate I am not sure 
is needed

6) it logs some helpful messages about the port / descriptor settings 
which is fine

7) it calls the pktgen_config_ports function which can crash in ways you 
need the destroyed debug output to fix.

For example in my case that function crashes here:

         if (pktgen.nb_ports == 0)
                 pktgen_log_panic("*** Did not find any ports to use ***");

8) Later it makes a logo and a splash screen (wr_log, wr_splash_screen). 
Is this stuff really needed? This is a ton of output for just starting 
up some test program.

To fix this debug problem I propose some changes which I am happy to 
help develop:

1) decide what of this output we really need here and greatly simplify 
how much gets printed out

2) move wr_scrn_setw right before pktgen_init_screen and after 
rte_eal_init to prevent damaging that output

3) consider how wr_scrn_init is called in pktgen_init_screen, because it 
calls wr_scrn_erase which damages output

4) I think that pktgen_config_ports should be called before all this 
weird screen init stuff, so that if it fails you can actually see what 
happened there.

One other random topic... on the long lines of code it looks like there 
are some gigantic tab-indents pushing things off to the right still. One 
example, maybe there are others or another setting which is needed to 
fix all of these:

                 info->seq_pkt = (pkt_seq_t *)rte_zmalloc_socket(buff, 
(sizeof(pkt_seq_t) * NUM_TOTAL_PKTS),
 
                                          RTE_CACHE_LINE_SIZE, 
rte_socket_id());

Thoughts?
Matthew Hall

             reply	other threads:[~2016-01-20  6:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-20  6:32 Matthew Hall [this message]
2016-01-20  8:53 ` Panu Matilainen
2016-01-20 15:59 ` Wiles, Keith
2016-01-20 16:26 ` Wiles, Keith
2016-01-20 16:45   ` Wiles, Keith
2016-01-21  3:53   ` Matthew Hall
2016-01-21  8:46   ` Panu Matilainen
2016-01-21 15:03     ` Wiles, Keith
2016-01-21 19:00       ` Stephen Hemminger
2016-01-21 20:03         ` Matthew Hall
2016-01-22  6:45       ` Panu Matilainen
2016-01-23  2:22         ` Wiles, Keith
2016-02-17 10:13           ` Panu Matilainen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=569F2A07.9000606@mhcomputing.net \
    --to=mhall@mhcomputing.net \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).